Linker 알아보기

안녕하세요?

너구리입니다.

 

저번 포스팅에서 Xcode Build System에 대한 글을 썼는데,

링커에 대해 조금만 더 자세히 공부해보려 알아보던중 

WWDC22에 링킹에 대한 영상이 있어 정리해보려 합니다.

가보시죠

 

목적 파일이란 무엇인가?(사전 지식)

먼자 알고가야할 내용이 있는데 바로 목적 파일 입니다.

목적 파일은 컴파일러나 어샘블러에서 소스코드를 컴파일이나 어셈블해서 생성하는 파일이다.

저번 포스팅 Xcode Build System에서 해당 단계에서 Mach-O파일을 생성한다고 했는데

그게 바로 목적 파일 중 하나입니다.

 

Linker란?

 

링커는 목적파일, 라이브러리 등을 합쳐 실행 파일로 만드는 역할을 하고

이 과정을 링킹이라고 합니다.

 

이 과정은 2개의 종류로 나눌 수 있습니다.

 

Static Linking(정적 링킹): 앱이 빌드되는 데 걸리는 시간과 앱의 크기에 영향

Dynamic Linking(동적 링킹): 앱이 실행될 때 발생하여 앱 시작 대기 시간에 영향

 

# What is static linking?

 

예전에는 프로그램들이 간단했고, 소스파일 또한 하나였기 때문에 빌드가 쉬웠습니다.

그래서 하나의 소스 파일을 컴파일 하면 실행 가능한 프로그램을 생성합니다.

그런데 하나의 소스 파일에 많은 코드를 넣고 수정하게 된다면 모든 부분을 다시 컴파일 해야합니다.

그래서 소스 파일을 분리하게 됩니다.

 

 

그런데 여러 소스 파일을 가지면 어떻게 빌드 할까요?

 

컴파일러를 두 부분으로 나누게 됩니다.

 

첫번째 부분에서는 소스 코드를 intermediate "relocatable object" file(.o)로 컴파일 하고

두번째 부분에서는 (.o) 파일을 읽고 실행 가능한 프로그램을 생성합니다.

 

그리고 두번째 부분을 ld(정적 링커)라 부릅니다.

 

 

소프트웨어가 발전하면 사람들은 .o 파일을 공유하기 시작합니다.

하지만 이 작업은 번거로운 작업입니다.

그래서 누군가 이 파일을 라이브러리로 만들면 어떨까? 라는 생각을 가지게 되었고

 

당시 파일을 묶는 표중 방식은 ar이라는 도구였습니다.

그래서 ar을 사용하여 .o파일을 아카이브로 묶은 후 링커가 이 아키이브 파일에서 .o 파일을 읽을 수 있도록 개선되었습니다. 

당시에는 이것을 라이브러리나 아카이브로 불렸지만

현재 우리는 정적 라이브러리(Static Library)라 부릅니다.

 

최근에는 실행 프로그램들이 무거워졌습니다.

실제 일부 코드만 사용하더라도 라이브러리의 수천개 함수가 복사됩니다.

 

그래서 링커는 최적화를 하기 위해

정적 라이브러리에서 모든 .o 파일을 사용하는 것이 아니라,

정의되지 않은 심볼문제(Undefined Symbol)가 해결된 .o 파일만 정적 라이브러리에서 사용하도록 개선됩니다.

예를 들어, C 표준 라이브러리 함수가 모두 포함된 libc.a가 만들어졌습니다.
각 프로그램은 libc.a를 연결하지만, 프로그램이 실제로 필요한 부분만 가져오게 됩니다.

 

참고

정의되지 않은 심볼 문제: 컴파일러가 현재 모듈에서 정의되지 않은 변수나 함수 이름 등의 심볼을 식별할 수 없을 때 발생

 

 

정적 라이브러리의 선택적 로딩을 시나리오를 통해 알아보도록 하겠습니다.

다음과 같은 소스 파일이 있습니다.

이 파일들을 .o 파일들로 컴파일 합니다.

 

그 다음 bar.o와 baz.o가 libbarbaz.a인 정적 라이브러리로 묶인다고 가정합니다.

 

그럼 실제로 linking이 어떻게 되는지 알아봅시다.

linker는 명령어 라인 순서대로 파일을 읽어 나갑니다.

 

먼저 main.o를 찾습니다.

main.o를 로드하고 심볼 테이블에서 main에 대한 정의를 찾습니다.

그렇지만 main 안에 정의되지 않은(Undefined) foo가 있다는 것도 찾습니다.

 

그 다음 linker는 명령어 다음 라인의 다음 파일 foo.o를 파싱합니다.

foo에 대한 정의를 추가합니다.(Undefined 해결)

하지만 정의되지 않은 새 심볼 'bar'를 추가합니다.

 

명령어 라인의 모든 .o파일이 로드되었으므로

linker는 정의되지 않은 심볼이 남아 있는지 확인합니다.

'bar'가 남아 있으므로 linker는 명령어 라인의 라이브러리들을 살펴보면서 

해당 심볼을 충족하는 라이브러리를 찾습니다.

linker는 정적 라이브러리 bar.o에서 'bar' 심볼 정의를 찾았고

아카이브로 부터 bar.o를 로드합니다.

정의되지 않은 심볼 문제가 모두 해결되었으므로 라이브러리 탐색을 종료합니다.

 

링커는 다음 단계로 넘어가

프로그램에 포함될 모든 함수와 데이터에 주소를 할당합니다.

 

그런 다음 모든 함수와 데이터를 출력  파일에 복사하고 출력 프로그램을 완성합니다.

bar.o는 링커가 선택적 로드 방식을 사용했기 때문에 정적 라이브러리에 있지만 프로그램에 로드되지 않습니다.

# Recent ld64 improvements

애플의 static linker인 ld64의 개선점에 대해 알아보도록 하겠습니다.

올해의 ld64는 많은 프로젝트에서 2배 빠릅니다.

 

링커 작업을 병렬로 수행하도록 여러개의 코어를 사용할 수 있는 여러 영역을 찾았습니다. 여기에는 입력 파일의 내용을 출력 파일로 복사하고 LINKEDIT의 부분들을 병렬로 구축하고 UUID 계산을 변경하고 코드 서명 해시를 병렬로 수행하는 것이 포함됩니다.

다음으로 여러 알고리즘을 개선했습니다. 각 심볼의 문자열 슬라이스를 나타내는데 C++의 string_view 객체를 사용하게 되면 exports-trie builder가 굉장히 잘 작동하는 것을 볼 수 있습니다. 또한 바이너리의 UUID를 계산할 때 최신 암호화 라이브러리를 사용해 하드웨어의 가속을 활용했습니다 다른 알고리즘 개선도 있었죠

 

# Static Linking best practices

링커의 성능 개선 작업을 연습해봅시다.

링크 시간을 개선하기 위해 5가지 주제에 대해 다루어 보도록 하겠습니다.

- 정적 라이브러리 사용 여부

- 잘 알려지지 않은 링크 시간에 큰 영향을 주는 세가지 옵션

- 몇가지 정적 링크의 속성

 

정적 라이브러리 사용 여부

정적 라이브러리에 빌드되는 소스 파일에 열심히 작업해서 빌드 시간이 느려지는 경우입니다.

파일이 컴파일 되고 나면 목차를 포함한 정적 라이브러리를 다시 빌드해야하기 때문입니다.

단지 추가적인 I/O가 많은겁니다. 

코드가 자주 수정되지 않고 안정적인 코드에는 정적 라이브러리가 가장 적합합니다.

 

-all_load

위와 같은 문제가 발생했을 때는 빌드 시간을 줄이기 위해서는

현재 수정중인 코드를 정적 라이브러리 밖으로 이동하는 것을 고려해야 합니다.

위에서 아카이브의 선택적 로딩을 봤었는데 이 기능의 단점은 링커를 느리게 만든다는 점입니다.

그 이유는 빌드를 재현 가능하도록 하면서 전통적인 정적 라이브러리의 의미를 따르기 위해서는 링커가 라이브러리를

고정된 직렬 순서로 처리해야 하기 때문입니다.

아까 ld64의 장점은 병렬 처리라 했는데 직렬로 처리해야 하기 때문에 느려지는 것이죠.

하지만 이런 전통적인 동작이 필요하지 않다면 링커 옵션을 통해 개선할 수 있습니다.

바로 -all_load 옵션을 통해서 말이죠.

 

이 옵션은 링커에게 모든 정적 라이브러리의 .o 파일을 무조건 로드하도록 지시합니다.

만약 앱이 대부분의 정적 라이브러리 내용을 선택적으로 로드하는 경우라면 사용하기 적절합니다.

해당 옵션을 사용하면 링커가 모든 정적 라이브러리와 그 내용을 병렬로 처리할 수 있습니다.

그러나 앱이 동일한 Symbol을 구현하는 여러 정적 라이브러리를 사용하고, 정적 라이브러리의

명령어 라인 순서에 따라 어떤 구현을 사용할 지 결정한다면 사용하기에 적절하지 않습니다.

링커가 모든 구현을 로드하며 기존 정적 링크 모드에서 얻을 수 있었던 Symbol  Sementics가 보장되지 않을 수있기 때문입니다.

 

또한 사용하지 않는 코드를 모두 추가하다 보니 프로그램 크기가 커질 수 있다는 단점이 있습니다.(unused 코드가 추가되기 때문)

이를 보완하기 위해 -dead_strip옵션을 사용할 수 있습니다.

이 옵션을 통해 링커가 접근 할 수 없는 코드와 데이터를 링커가 제거합니다.

-dead_strip의 알고리즘은 빠르며, 결과 파일 크기를 줄임으로써 성능에 대한 이점을 제공합니다.

-all_load와 -dead_strip을 함께 사용하고자 한다면 이 옵션들을 사용했을 때와 사용하지 않았을 때의 링크 시간을 측정하여 어느 선택지가 더 빠른지 확인할 필요가 있습니다.

 

-no_exported_symbols

다음 링크 옵션은 -no_exported_symbols입니다. 

먼저 간단한 배경을 확인해 보겠습니다.

링커가 생성하는 LINKEDIT 세그먼트의 일부는 내보낸 심볼 이름, 주소, 플래그를 인코딩하는 접두어 트리인 exports trie입니다. 모든 dylib는 내보낸 심볼을 가져야 하지만, 메인 앱 바이너리는 보통 내보낸 심볼이 필요하지 않습니다.

즉, 일반적으로 메인 실행 파일에서 심볼을 조회하는 일은 없습니다. 이런 경우 앱 타겟이서 -no_exported_symbols 옵션을 사용하여 LINKEDIT에서 trie 데이터 구조 생성을 건너뛸 수 있으며, 이를 통해 링크 시간을 단축할 수 있습니다.

다만 앱이 메인 실행 파일로 다시 링크되는 플러그인을 로드하거나, 앱을 호스트 환경으로 사용하는 xctest 번들을 실행하는 경우, 모든 내보내기를 가져야 하므로 이 옵션을 사용할 수 없습니다.

exports trie를 억제하는 것은 이 구조가 큰 경우에만 유효합니다. dyld_info -exports /path/to/binary | wc -l 명령어를 사용하면 내보낸 심볼의 수를 계산할 수 있습니다. 한 대규모 앱에서는 약 100만개의 내보낸 심볼이 있었고, 링커가 exported trie를 빌드하는데 2~3초가 걸립니다. 이때 이 옵션을 사용하면 2~3초를 단축할 수 있습니다.

 

-no_deduplicate

다음 링크 옵션은 -no_deduplicate입니다. 링크 과정에서 중복된 코드나 데이터의 제거를 하지 않도록 하는 옵션입니다. 최종 실행 파일을 살당히 줄일 수 있어 유용 하지만 링커가 모든 함수의 지침을 재귀적으로 해싱하여 이 알고리즘은 비용이 많이 듭니다. 따라서 빌드 속도가 중요한 디버그 빌드에서 사용하는것이 효율적입니다.

 

# What is dynamic linking?

시간이 지나면서 라이브러리는 커지고 많아졌으며 그 결과 자연스럽게 실핼 프로그램은 커지게 되었습니다.

시간에 따라 해당 프로그램 빌드에 드는 정적 링크 시간도 증가하죠

 

시간에 따라 아래와 같이 ar이 ld로 바뀌는 과정이 생깁니다.

그럼 출력 라이브러리는 이제 실행 가능한 바이너리가 되는것이죠. 그럼 자연스럽게 실행 프로그램은 사이즈가 줄어들게 되고 이것이 바로 동작 라이브러리의 출발입니다.

동적 라이브러를 통칭 dylib 라고 합니다.

 

여기서는 어떤 일이 일어나고 확장성에 어떤 도움이 될까요?

라이브러리에서 최종 프로그램으로 코드를 복사하는 것 대신 링커가 promise를 기록합니다.

즉, 동적 라이브러리에서 사용하는 심볼 이름과 런타임에 라이브러리의 경로를 기록합니다. 이것이 어떻게 이점이 될까요? 프로그램 파일 크기를 제어할 수 있다는 뜻입니다. 프로그램에는 자신의 코드와 런타임에 필요한 동적 라이브러리 목록만 포함됩니다. 이제 라이브러리 코드가 프로그램에 복사되지 않습니다. 프로그램의 정적 링크 시간은 코드 크기에 비례하며, 링크된 dylib 수와는 독립적입니다.

 

또한 가상 메모리 시스템(Virtual Memory system)이 빛을 발할 수 있습니다. 동일한 동적 라이브러리를 여러 프로세스에서 사용할 경우, 가상 메모리 시스템은 모든 프로세스에서 동일한 dylib에 대해 동일한 물리적 RAM 페이지를 재사용합니다.

 

동적 라이브러리의 시작과 해결하려는 문제를 살펴보았습니다. 그렇다면 이러한 "혜택"에는 어떤 "비용"이 따를까요?
첫 번째 혜택은 빌드 시간이 단축된다는 점입니다. 그러나 비용은 앱 실행 속도가 느려진다는 것입니다. 실행은 더 이상 하나의 프로그램 파일만 로드하는 것이 아닙니다. 이제 모든 dylibs도 로드되고 연결되어야 합니다. 즉, 빌드 시간의 일부 링크 비용이 실행 시간으로 연기된 것입니다.

두 번째로, 동적 라이브러리 기반 프로그램은 더 많은 더티 페이지를 가집니다. 정적 라이브러리의 경우, 링커는 모든 정적 라이브러리의 전역 변수(globals)를 주 실행 파일의 동일한 DATA 페이지에 배치합니다. 그러나 dylib의 경우, 각 라이브러리가 자체 DATA 페이지를 가집니다.

마지막으로, 동적 링크의 비용은 새로운 요소, 즉 동적 링커가 필요하다는 것입니다! 빌드 시간에 실행 파일에 기록된 약속을 기억하시나요? 이제 런타임에 해당 약속을 이행하여 라이브러리를 로드할 것이 필요합니다. 이것이 바로 동적 링커(dyld)의 역할입니다. 이제 동적 링크가 런타임에 어떻게 작동하는지 살펴보겠습니다.

 

실행 가능한 바이너리는 TEXT, DATA, LINKEDIT와 같은 세그먼트로 나뉩니다. 세그먼트는 항상 OS 페이지 크기의 배수이며, 각 세그먼트는 다른 권한을 가집니다. 예를 들어, TEXT 세그먼트는 "실행" 권한을 가집니다. 즉, CPU가 해당 페이지의 바이트를 기계어 명령으로 처리할 수 있습니다. 런타임 시, dyld는 mmap()을 사용하여 각 세그먼트를 메모리에 적재하고 권한을 설정합니다.

 

 

그러나 단순히 매핑하는 것만으로는 충분하지 않습니다. 프로그램이 dylib에 "연결"되거나 결합되어야 합니다. 이를 위해 "수정(fix-ups)"이라는 개념이 도입됩니다.

 

다이어그램에서 프로그램이 사용하는 dylib의 일부를 가리키는 포인터들이 설정된 것을 볼 수 있습니다. 이제 수정 작업(fix-ups)에 대해 알아보겠습니다. 여기 우리가 익숙한 Mach-O 파일이 있습니다.

TEXT 세그먼트는 변경할 수 없는(immutable) 속성을 가지고 있으며, 이는 코드 서명이 기반이 되는 시스템에서 반드시 그래야 합니다. 그렇다면 malloc()을 호출하는 함수가 있다고 가정해봅시다. 이런 경우는 어떻게 작동할까요? 프로그램이 빌드될 때 _malloc의 상대 주소는 알 수 없습니다.

그렇다면 어떻게 동작하는 걸까요? 정적 링커(static linker)는 malloc이 dylib에 있다는 것을 인지하고 호출 위치를 변환합니다. 호출 위치는 동일한 TEXT 세그먼트에 링크에 의해 생성된 스텁(stub)을 호출하도록 변환됩니다. 이를 통해 상대 주소를 빌드 시점에 알 수 있게 되며, BL(Branch with Link) 명령어를 올바르게 형성할 수 있습니다.

이 과정이 유용한 이유는 스텁이 DATA에서 포인터를 불러와 해당 위치로 점프하기 때문입니다. 이렇게 하면 실행 시 TEXT 세그먼트를 변경할 필요가 없고, 단지 dyld가 DATA만 변경하면 됩니다.

사실 dyld를 이해하는 핵심은 dyld가 수행하는 모든 수정 작업이 단지 DATA 내의 포인터를 설정하는 작업이라는 점입니다.

 

이제 dyld가 수행하는 수정(fixup)에 대해 더 자세히 알아보겠습니다. LINKEDIT에는 dyld가 어떤 수정 작업을 수행할지 결정하는 데 필요한 정보가 있습니다. 수정은 두 가지 유형으로 나뉩니다.

첫 번째는 리베이스(rebase)라고 불리는 것으로, 이는 dylib(동적 라이브러리)나 앱 내부의 포인터가 자신을 가리킬 때 발생합니다. ASLR(Address Space Layout Randomization)이라는 보안 기능이 있어 dyld는 dylib를 무작위 주소에 로드합니다. 따라서 이러한 내부 포인터는 빌드 시점에 미리 설정할 수 없습니다. 대신 dyld는 실행 시점에 이러한 포인터를 조정하거나 "리베이스"해야 합니다. 디스크에 저장된 상태에서 이러한 포인터는 dylib가 주소 0에 로드된다고 가정할 때의 대상 주소를 포함합니다. 이렇게 하면 LINKEDIT에는 각 리베이스 위치의 위치만 기록하면 됩니다. 그런 다음 dyld는 dylib의 실제 로드 주소를 각 리베이스 위치에 추가하여 이를 올바르게 수정할 수 있습니다.

 

 

 

두 번째 유형은 바인드(bind)입니다. 바인드는 심볼릭 참조입니다. 즉, 그 대상이 숫자가 아니라 심볼 이름입니다. 예를 들어, "malloc" 함수에 대한 포인터가 있다고 가정합시다. "_malloc" 문자열은 실제로 LINKEDIT에 저장되며, dyld는 이 문자열을 사용해 libSystem.dylib의 exports trie에서 malloc의 실제 주소를 찾습니다. 그런 다음 dyld는 바인드로 지정된 위치에 해당 값을 저장합니다. 올해 우리는 수정 정보를 인코딩하는 새로운 방법인 "체인드 수정(chained fixups)"을 발표했습니다.

 

 

첫 번째 장점은 LINKEDIT의 크기가 작아진다는 것입니다. LINKEDIT의 크기가 줄어드는 이유는 모든 수정 위치를 저장하는 대신, 새로운 포맷에서는 각 DATA 페이지에서 첫 번째 수정 위치와 가져온 심볼 목록만 저장하기 때문입니다. 나머지 정보는 DATA 세그먼트 자체에 인코딩되어 최종적으로 수정 작업이 설정될 위치에 저장됩니다. 이 새로운 포맷은 수정 위치가 서로 "체인"으로 연결된다는 점에서 체인드 수정이라는 이름을 얻었습니다. LINKEDIT는 첫 번째 수정 위치만 기록하며, DATA의 64비트 포인터 위치에 일부 비트는 다음 수정 위치의 오프셋을 포함합니다. 또한 해당 비트는 수정이 바인드인지 리베이스인지 나타냅니다. 만약 바인드라면 나머지 비트는 심볼의 인덱스를 나타냅니다. 리베이스라면 나머지 비트는 이미지 내의 대상 오프셋을 나타냅니다. 마지막으로 체인드 수정에 대한 런타임 지원은 iOS 13.4 이상에서 이미 존재하므로, 배포 대상이 iOS 13.4 이상이라면 오늘부터 이 새로운 포맷을 사용할 수 있습니다. 체인드 수정 포맷은 올해 발표된 새로운 OS 기능도 가능하게 합니다. 이를 이해하려면 dyld의 작동 방식을 알아야 합니다.

 

 

dyld는 메인 실행 파일(예: 앱)로부터 시작합니다. mach-o를 파싱해 필요한 의존 dylib(약속된 동적 라이브러리)를 찾습니다. 그런 다음 이러한 dylib를 mmap()하여 로드합니다. 각각에 대해 추가적으로 필요한 dylib를 로드하도록 mach-o 구조를 재귀적으로 파싱합니다. 모든 것이 로드되면 dyld는 필요한 바인드 심볼을 찾아 수정 작업을 수행합니다. 마지막으로 dyld는 초기화 작업을 하향식(bottom-up)으로 실행합니다. 5년 전, 우리는 이 과정에서 초록색으로 표시된 단계들이 앱이 실행될 때마다 동일하다는 점을 발견했습니다. 따라서 프로그램과 dylib가 변경되지 않는 한, 초록색 단계들을 첫 실행 시 캐싱하여 이후 실행 시 재사용할 수 있습니다. 

 

 

# Recent dyld improvements

올해 우리는 추가적인 dyld 성능 향상을 발표했습니다. "페이지-인 링크(page-in linking)"라는 새로운 dyld 기능입니다. 이는 dyld가 실행 시 모든 dylib에 대해 수정 작업을 수행하는 대신, 커널이 필요한 DATA 페이지를 페이지-인(page-in) 시점에서 수정 작업을 수행할 수 있게 합니다.

기존에도 mmap()된 영역의 페이지 중 일부 주소가 처음 사용되면 커널이 해당 페이지를 읽어오는 방식이었습니다. 이제 DATA 페이지의 경우, 커널이 해당 페이지에 필요한 수정 작업도 수행할 수 있습니다. 이 메커니즘은 지난 10년간 dyld 공유 캐시에 있는 OS dylib에 대해 특별한 경우로 존재했지만, 올해 우리는 이를 일반화하여 모든 사용자에게 제공했습니다. 이 메커니즘은 메모리의 더티 상태를 줄이고 실행 시간을 단축합니다. 또한 DATA_CONST 페이지가 깨끗(clean)해지므로 TEXT 페이지처럼 퇴출되고 다시 생성될 수 있어 메모리 압박이 줄어듭니다. 페이지-인 링크 기능은 향후 iOS, macOS, watchOS 릴리스에 포함될 예정입니다. 그러나 페이지-인 링크는 체인드 수정으로 빌드된 바이너리에서만 작동합니다. 체인드 수정을 통해 대부분의 수정 정보가 디스크의 DATA 세그먼트에 인코딩되므로, 페이지-인 시점에서 커널이 이를 사용할 수 있습니다. 단, dyld는 실행 중에만 이 메커니즘을 사용합니다. 이후에 dlopen()으로 로드된 dylib의 경우 페이지-인 링크는 적용되지 않습니다. 이 경우 dyld는 전통적인 경로를 따라 dlopen 호출 중 수정 작업을 수행합니다.

 

지난 5년간 dyld는 초록색으로 표시된 단계를 최적화하여 첫 실행 시 작업을 캐싱하고 이후 실행에서 이를 재사용했습니다. 이제 dyld는 "apply fixup" 단계도 최적화하여 실제 수정 작업을 수행하지 않고, 커널이 이를 페이지-인 시점에서 지연 수행하게 합니다.

 

# Dynamic linking best practices

dyld는 이미 동적 링크 단계 대부분을 가속화했으므로, 여러분이 제어할 수 있는 것은 dylib의 수입니다. dylib가 많을수록 dyld가 로드 작업을 수행하는 데 더 많은 시간이 걸립니다. 반대로 dylib가 적으면 작업량이 줄어듭니다. 또 하나 확인해야 할 것은 정적 초기화자(static initializer)입니다. 이는 메인 함수 실행 전 항상 실행되는 코드입니다. 예를 들어, 정적 초기화자에서 I/O 작업이나 네트워크 작업을 수행하지 마십시오. 몇 밀리초 이상 걸릴 수 있는 작업은 절대 초기화자에서 실행하지 않아야 합니다. 여러분의 설치 기반에 적합하다면 더 높은 배포 대상(iOS 13.4 이상)으로 업데이트하여 체인드 수정을 활성화하고 바이너리를 더 작게 만들고 실행 시간을 단축시킬 수 있습니다.

 

# New Tools

첫 번째 도구는 dyld_usage입니다. 이 도구를 사용하면 dyld가 수행하는 작업을 추적할 수 있습니다.
이 도구는 macOS에서만 사용할 수 있지만, 시뮬레이터에서 앱을 실행하거나 Mac Catalyst로 빌드된 앱에 대해 추적하는 데 활용할 수 있습니다.

다음은 macOS에서 TextEdit을 대상으로 실행한 예입니다.

위의 상단 몇 줄에서 알 수 있듯이, 전체 실행 시간은 15ms가 걸렸으며, 그중 fixup 작업에는 1ms만 소요되었습니다.
이는 page-in linking 덕분입니다. 현재 실행 시간의 대부분은 정적 초기화 코드(static initializers) 실행에 사용되고 있습니다.

 

 

다음 도구는 dyld_info입니다. 이 도구를 사용하면 디스크에 있는 바이너리 파일이나 현재 dyld 캐시에 있는 바이너리를 분석할 수 있습니다.
이 도구에는 다양한 옵션이 있지만, 여기서는 exports와 fixups를 확인하는 방법을 보여드립니다.

 

-fixup 옵션을 사용하면 dyld가 처리할 모든 fixup 위치와 그 대상(target)을 표시합니다. 출력 형식은 해당 파일이 기존 방식의 fixups인지, 아니면 새로운 chained fixups인지에 상관없이 동일합니다.

 

-exports 옵션을 사용하면 해당 dylib에서 내보내진 모든 심볼(exported symbols)과, 각 심볼이 dylib 시작 지점에서 얼마나 떨어져 있는지를 확인할 수 있습니다.
이 경우, Foundation.framework라는 dyld 캐시에 있는 dylib 정보를 보여줍니다. 디스크에 파일이 존재하지 않더라도, dyld_info 도구는 dyld와 동일한 코드를 사용하기 때문에 이를 찾아낼 수 있습니다.

 

 

# 정리

이제 정적 라이브러리와 동적 라이브러리의 역사와 그 장단점을 이해하셨으니, 여러분의 앱이 어떻게 동작하는지 검토하고 적절한 sweet spot을 찾으세요.
다음으로, 만약 앱이 크고 링크 작업이 오래 걸린다면, Xcode 14의 faster linker를 사용해 보세요.
링크 속도를 더 개선하고 싶다면 제가 설명한 세 가지 링커 옵션을 검토하여 여러분의 빌드에 적합한지 확인하고, 이를 통해 링크 시간을 단축하세요.
마지막으로, 앱과 포함된 프레임워크를 iOS 13.4 이상으로 빌드하여 chained fixups를 활성화한 후, 앱이 iOS 16에서 더 작아지고 실행 속도가 더 빨라지는지 확인해 보세요.

 

 

 

참조

https://developer.apple.com/videos/play/wwdc2022/110362

Link fast: Improve build and launch times - WWDC22 - Videos - Apple Developer