링킹

7.1컴파일러 드라이버

평소 gcc hello.c -o hello 한 줄로 끝나는 작업이지만, gcc는 사실 드라이버(driver)일 뿐이다. 진짜 일은 네 명의 일꾼이 분담해서 한다. 호기심이 든다면 -v 옵션을 붙여 보자 — 안 보이던 무대 뒤가 보인다.

$ gcc -v -o hello hello.c (출력 일부 발췌)cpp ... hello.c    -> /tmp/hello.i      # 1) 전처리: #include, #define 풀기
cc1 ... hello.i    -> /tmp/hello.s      # 2) 컴파일: C → 어셈블리
as  ... hello.s    -> /tmp/hello.o      # 3) 어셈블: 어셈블리 → 기계어 (재배치 가능 오브젝트)
ld  ... hello.o ... -lc -o hello        # 4) 링크: 라이브러리와 합쳐 실행 파일

네 단계가 모두 따로 호출 가능한 독립 도구라는 점이 중요하다. 평소엔 한 줄에 다 묶이지만, 디버깅이나 리버싱에서는 각 단계의 중간 결과물(.i, .s, .o)을 들여다보는 일이 일상이다.

7.2정적 링킹

링커가 하는 일을 한 줄로 줄이면, 여러 입력 모듈을 받아서 하나의 실행 가능한 모듈을 만드는 것이다. 이때 두 가지 큰 작업이 진행된다.

• 심볼 해석(symbol resolution) — 코드 안의 모든 심볼 참조를 정확히 한 개의 정의(definition)에 묶는다.
• 재배치(relocation) — 컴파일 시 임시로 0번 주소부터 시작했던 코드와 데이터에 실제 메모리 주소를 박아 넣는다.

정적 링킹은 이 두 일을 빌드 타임에 모두 끝내고, 라이브러리 코드까지 실행 파일 안으로 복사해 넣는 방식이다. 실행 파일 하나만 들고 다니면 된다는 단순함이 매력이지만, 같은 라이브러리를 쓰는 100개 프로그램이 라이브러리 코드를 100번 복제해서 디스크와 메모리를 잡아먹는다는 단점이 있다. 나중에 동적 링킹이 등장한 이유가 여기에 있다.

7.3오브젝트 파일 (세 종류)

오브젝트 파일은 시점에 따라 세 모습 중 하나를 띤다. Linux에서는 모두 ELF(Executable and Linkable Format)라는 같은 포맷의 변형이다.

7.4재배치 가능 오브젝트 파일 (ELF)

.o 파일을 열어 보면, 맨 앞에 ELF 헤더가 있고 그 뒤로 여러 섹션(section)이 차곡차곡 쌓여 있다. 헤더는 "이 파일은 ELF다, 64비트다, 리틀 엔디안이다, 섹션 헤더 테이블은 어디다…" 같은 메타 정보를 담는다.

7.5심볼과 심볼 테이블

링커가 보는 세계에서 모든 함수와 전역 변수는 심볼(symbol)이다. 한 모듈의 심볼은 세 부류로 나뉜다.

• 전역 심볼(global) — 이 모듈이 정의하고, 다른 모듈도 가져다 쓸 수 있는 것. static이 안 붙은 함수와 전역 변수.
• 외부 심볼(external) — 다른 모듈이 정의했고, 이 모듈은 빌려 쓰는 것. 코드에서 extern으로 선언했거나, 단순히 함수 호출만 한 경우.
• 지역 심볼(local) — static 키워드가 붙은 함수/변수. 같은 파일 안에서만 보인다. 다른 모듈에서 같은 이름의 static이 있어도 충돌하지 않는다.

심볼 테이블의 각 엔트리는 대략 이런 정보를 갖는다: 이름(.strtab 인덱스), 값(섹션 안에서의 오프셋), 크기, 어떤 섹션에 속하는지, 바인딩(local/global/weak), 타입(함수/객체).

7.6심볼 해석

심볼 해석(symbol resolution)은 참조를 정확히 하나의 정의에 묶는 작업이다. 지역 심볼이라면 같은 파일 안에서 짝을 찾으면 끝이지만, 전역 심볼은 이름이 같은 후보가 여러 모듈에 있을 수 있어서 규칙이 필요하다.

파일 a.cint x = 100;          // 강한 심볼 (초기화됨)
void foo(void);
int main() { foo(); printf("x=%d\n", x); return 0; }

파일 b.cdouble x;             // 약한 심볼 (초기화 안 됨, 8바이트짜리!)
void foo(void) { x = 1.0; }

# 잘못된 순서: libfoo.a가 main.o의 foo() 참조를 만나기 전에 스캔됨
$ gcc -static -lfoo main.c          # 에러: undefined reference to `foo'

# 올바른 순서: main.o가 U에 foo를 추가한 뒤 libfoo.a에서 찾음
$ gcc -static main.c -lfoo          # OK

7.7재배치 (Relocation)

심볼 해석이 끝나면, 링커는 모든 입력 모듈의 .text·.data 섹션을 모아 큰 덩어리로 합치고, 합친 덩어리에 실제 메모리 주소를 부여한다. 이제 코드 안에서 "여기서 foo를 부른다", "여기서 전역 변수 x를 읽는다" 같은 자리에 진짜 주소를 메워 넣어야 한다. 이 작업이 재배치다.

refaddr = ADDR(s) + r.offset                      // 메울 위치의 최종 주소
*refptr = (ADDR(r.symbol) + r.addend) - refaddr   // PC-상대 변위

*refptr = ADDR(r.symbol) + r.addend

7.8실행 가능 오브젝트 파일

실행 가능 ELF 파일은 재배치 가능 파일과 모양이 비슷하지만 결정적인 차이가 있다. 프로그램 헤더 테이블(program header table)이 추가되고, 이게 로더 관점에서 파일을 메모리에 어떻게 배치할지를 알려 준다. 단위는 섹션이 아니라 세그먼트(segment)다. 여러 섹션이 같은 보호 속성을 공유하면 한 세그먼트로 묶인다.

• 코드 세그먼트(읽기·실행) — .text, .rodata, .init 등.
• 데이터 세그먼트(읽기·쓰기) — .data, .bss 등.

각 세그먼트 헤더는 "이 세그먼트는 파일 오프셋 X부터 Y바이트를, 가상 주소 V에 매핑하라. 메모리에서는 W바이트로 늘려라(.bss 때문에). 권한은 R-X다." 같은 정보를 담는다. 실제 파일 크기 < 메모리 크기인 부분이 바로 BSS다.

7.9실행 파일 로딩 (loader, execve)

실행 파일을 ./hello로 띄우면 셸은 fork 후 자식에서 execve 시스템 콜을 부른다. 커널의 로더(loader)가 등장하는 순간이다.

1. 현재 프로세스의 가상 메모리(주소 공간)를 거의 모두 비운다.
2. 실행 파일의 프로그램 헤더를 보고, 각 세그먼트를 가상 주소 공간에 매핑한다 (실제 디스크 → 페이지 테이블 엔트리. 9장 참고).
3. 스택과 힙 영역도 만들어 둔다. 스택 꼭대기에 argc, argv, envp를 쌓는다.
4. 엔트리 포인트(보통 _start)로 점프한다. _start가 런타임을 초기화하고 결국 main을 호출한다.

매핑은 실제 페이지를 그 자리에 갖다 놓지 않는다. 처음에는 페이지 테이블 엔트리만 만들어 두고, 실제 접근이 일어나는 순간 페이지 폴트로 디스크에서 끌어온다. 이걸 demand paging이라 부른다 (9장 주제). 그래서 GB짜리 실행 파일도 execve 자체는 빠르게 끝난다.

7.10공유 라이브러리와 동적 링킹

정적 링킹의 단점은 분명하다. libc가 1MB라면, 그걸 쓰는 100개 프로그램이 100MB를 잡아먹는다. 보안 패치라도 나오면 100개 모두 다시 빌드·재배포해야 한다. 해법은 라이브러리 코드를 실행 시점에 합치는 것 — 동적 링킹이다.

Linux의 공유 라이브러리는 .so 확장자를 갖는다 (Windows는 .dll). 빌드 시점에는 .so가 어떤 심볼들을 제공하는지만 기록해 두고, 실제 코드 복사는 하지 않는다. 실행 시점에 동적 링커(dynamic linker) — Linux에선 ld-linux.so — 가 필요한 .so들을 메모리에 올리고 마지막 재배치를 마무리한다.

7.11애플리케이션에서 공유 라이브러리 로드/링크

보통은 동적 링커가 시작 시 모든 .so를 자동으로 처리하지만, 실행 도중에 라이브러리를 능동적으로 골라 부르고 싶을 때가 있다. 플러그인 시스템, 핫 리로딩, 게임 모드 시스템 같은 경우. 이때 <dlfcn.h> API를 쓴다.

#include <dlfcn.h>

void *handle = dlopen("./libplugin.so", RTLD_LAZY);
if (!handle) { fputs(dlerror(), stderr); exit(1); }

// 함수 포인터 형으로 심볼을 찾아 받는다
double (*cosine)(double) = dlsym(handle, "cos");
char *err = dlerror();
if (err) { fputs(err, stderr); exit(1); }

printf("cos(0) = %f\n", cosine(0.0));
dlclose(handle);

dlopen의 RTLD_LAZY는 실제로 심볼이 호출될 때까지 결합을 미루라는 뜻, RTLD_NOW는 즉시 모두 연결하라는 뜻이다. 링크할 땐 -ldl을 잊지 말 것.

7.12위치 독립 코드 (PIC)

같은 .so가 프로세스 A에서는 0x7f00... 주소에, 프로세스 B에서는 0x7f88... 주소에 매핑될 수 있다. 그렇다면 .so 안의 코드는 어디에 적재되든 그대로 동작해야 한다. 이를 위해 코드 안에 절대 주소를 박지 않는 위치 독립 코드(Position-Independent Code, PIC)로 컴파일한다 (-fPIC).

전략은 두 단계다.

GOT (Global Offset Table) — 데이터 간접

전역 변수에 직접 접근하는 대신, 데이터 세그먼트에 들어 있는 GOT 엔트리를 통해 한 번 우회한다. GOT는 데이터 영역에 있어서 코드와의 거리가 컴파일 타임에 알려진 상수다. 따라서 PC-상대로 GOT 엔트리에 접근할 수 있고, GOT 엔트리에는 동적 링커가 적재 시점에 진짜 주소를 채워 넣는다.

// "전역 변수 g 읽기" 의 PIC 버전 어셈블리 (개념)
movq    g@GOTPCREL(%rip), %rax   ; rax = &g  (GOT에서 주소 가져오기)
movq    (%rax), %rax             ; rax = g

PLT (Procedure Linkage Table) — 함수 간접 + 지연 바인딩

외부 함수 호출은 PLT 스텁(stub)을 거쳐 간다. PLT는 코드 영역에 있고, 각 외부 함수마다 몇 줄짜리 스텁이 있다. 처음 호출 때 스텁이 동적 링커에 일을 시키고, 동적 링커가 GOT 엔트리에 진짜 함수 주소를 적어 둔다. 다음 호출부터는 스텁이 GOT만 읽고 곧장 점프한다. 이게 지연 바인딩(lazy binding)이다.

7.13라이브러리 인터포지셔닝 (Library Interpositioning)

인터포지셔닝은 어떤 함수의 호출을 가로채서 내가 만든 다른 버전으로 바꿔치기하는 기술이다. 디버깅, 프로파일링, 메모리 누수 추적, 보안 후킹 — 쓸모는 끝이 없다. 시점에 따라 세 방식이 있다.

malloc.h — 우리 헤더로 가로채기#define malloc(size) my_malloc(size)
#define free(ptr)    my_free(ptr)

void *my_malloc(size_t size);
void  my_free(void *ptr);

// 사용자 코드는 변함 없이 malloc(100); 호출하면
//  -> 전처리기가 my_malloc(100); 으로 바꿔서 우리 wrapper로 들어옴

mymalloc.c — 링커가 wrapper로 붙여 줄 함수#include <stdio.h>
#include <stdlib.h>

void *__real_malloc(size_t size);              // 진짜 malloc

void *__wrap_malloc(size_t size) {             // 링커가 호출자를 여기로 돌림
    void *p = __real_malloc(size);
    fprintf(stderr, "malloc(%zu) = %p\n", size, p);
    return p;
}

$ gcc -c main.c mymalloc.c
$ gcc -o app main.o mymalloc.o -Wl,--wrap=malloc

mymalloc_preload.c — malloc 가로채기#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

void *malloc(size_t size) {
    static void *(*real_malloc)(size_t) = NULL;
    if (!real_malloc)
        real_malloc = dlsym(RTLD_NEXT, "malloc");      // 진짜 malloc 찾기

    void *p = real_malloc(size);
    fprintf(stderr, "[trace] malloc(%zu) = %p\n", size, p);
    return p;
}

$ gcc -fPIC -shared -o mymalloc.so mymalloc_preload.c -ldl
$ LD_PRELOAD=./mymalloc.so ls
[trace] malloc(120) = 0x55f...
[trace] malloc(72)  = 0x55f...
... (ls 출력)

7.14오브젝트 파일 도구

리눅스 시스템에 이미 깔려 있는 도구들. 한 번씩 만져 보면 ELF가 더 이상 검은 상자가 아니게 된다.

7.15요약

링커가 하는 일을 한 호흡에 정리해 보자. 컴파일러 드라이버는 전처리·컴파일·어셈블·링크의 4단계를 묶어 호출한다. 앞 세 단계가 만들어 낸 재배치 가능 오브젝트 파일들을 받아, 링커는 모든 심볼 참조를 정의에 묶고(심볼 해석), 섹션을 모아 합친 뒤 코드 안의 모든 주소 자리를 채워 넣는다(재배치). 강한·약한 심볼 규칙은 무서운 미묘한 버그를 만들 수 있으니 전역 변수는 한 곳에서만 정의하는 습관을 들이는 게 좋다. 정적 라이브러리는 명령줄 순서가 중요하고, 라이브러리는 보통 끝에 둔다.

실행 시점이 되면 로더가 ELF 프로그램 헤더를 보고 가상 주소 공간에 세그먼트를 매핑하고, 동적 링커가 공유 라이브러리들을 채워 넣는다. 공유 라이브러리는 어디에 적재되든 동작하도록 PIC로 빌드되며, GOT와 PLT를 통해 데이터·함수 접근을 한 단계 우회한다. 이 우회 지점은 인터포지셔닝의 핵심 통로가 되어, 컴파일·링크·런타임 어느 시점에서든 함수 호출을 가로챌 수 있게 해 준다.

링커를 알면 빌드 에러의 절반은 메시지만 봐도 풀린다. undefined reference는 심볼 해석 실패, multiple definition은 강한 심볼 충돌, 의문의 메모리 깨짐은 약한 심볼 의심, 동적 의존성 누락은 ldd 한 방. 도구가 손에 익으면 자신감이 따라온다. 다음 장에선 흐름이 갑자기 다른 곳으로 점프하는 모든 상황 — 인터럽트, 시스템 콜, 시그널, 프로세스 — 을 다룬다.