57 링크와 ABI — 이진 수준의 약속

57.1 링크는 한 단계가 아니다 — 세 이름#

지금까지 “링커가 이어 준다”고 뭉뚱그려 말했다. 실제로는 세 단계이고, 각각 이름이 있다.¹

정적 링크된 프로그램은 앞의 둘로 끝난다. 동적 링크된 프로그램은 셋을 다 거친다. 그래서 같은 「링크」라는 낱말이 빌드 시각과 실행 시각 양쪽에 등장해 사람을 헷갈리게 한다.

★ 여기에 실무에서 알아 둘 사실이 하나 붙는다. 런타임 링커는 main이 불리기 전에 공유 객체를 주소 공간에 들이지만, 함수 심볼은실제로 불릴 때까지잇지 않는다. 이것을 게으른 결합(lazy binding)이라 한다. 그래서 쓰지도 않을 라이브러리를 링크해 두어도 시작 비용이 거의 늘지 않는다.

리눅스에서는 LD_BIND_NOW=1을 주면 이 미룸을 끄고 시작할 때 전부 잇는다. 실행 직후의 지연이 문제 되는 프로그램이나, 링크 오류를 나중이 아니라 지금 알고 싶을 때 쓴다.

57.2 동적 링크의 진짜 목적 — 크기가 아니라 ABI#

동적 링크의 이점으로 흔히 「실행 파일이 작아진다」를 든다. 재어 보면 사실이기는 하다.

★ 그러나 크기는 부산물이다. 진짜 목적은 다른 데 있다. 동적 링크는 프로그램을 특정 라이브러리 판본으로부터 떼어 놓는다. 시스템이 「이런 서비스를 이런 모양으로 내준다」고 약속하고, 프로그램은 그 약속에만 기댄다. 라이브러리가 고쳐져도 프로그램을 다시 빌드하지 않아도 되는 이유가 이것이다.

이 약속을 ABI(Application Binary Interface, 응용 프로그램 이진 인터페이스)라 부른다. API 가 「소스 수준의 약속」이라면 ABI 는 「이진 수준의 약속」이다 — 함수 이름이 무엇인지뿐 아니라, 인자를 어느 레지스터에 싣는지, 구조체를 어떻게 채워 넣는지, 반환값을 어디에 두는지까지 포함한다.

soname이 실무에서 자주 만나는 자리다. libfoo.so.2처럼 이름에 붙은 숫자가 「이 판까지는 이진 호환을 지킨다」는 선언이고, 호환이 깨지는 변경을 하면 그 숫자를 올린다. 그러면 옛 프로그램은 여전히 .so.2를 찾고 새 프로그램은 .so.3을 찾으므로 한 시스템에 둘이 공존할 수 있다.

57.3 ABI 가 약속하는 것 — 조목조목#

표 57.3이 목록이었다면 여기서는 그 하나하나가 실제로 무엇으로 나타나는지 본다. 소스에는 한 글자도 적히지 않지만, 기계어에는 또렷이 박혀 있는 것들이다.

첫째, 호출 규약. 인자를 어디에 싣는가. x86-64 의 System V ABI 에서는 정수·포인터 인자가 rdi, rsi, rdx, rcx, r8, r9 순으로 실리고, 일곱째부터 스택으로 간다. 컴파일러가 낸 기계어를 그대로 보면 의심할 여지가 없다.

f:                          /* long f(long a, long b, long c, …) */
        add     rdi, rsi
        add     rdi, rdx
        add     rdi, rcx
        add     rdi, r8

★ 같은 CPU 라도 판이 다르면 규약이 다르다. Windows x64 는 첫 네 인자를 rcx, rdx, r8, r9 에 싣고, 호출자가 32바이트를 미리 비워 둔다 — 이 자리를 영어로 shadow space 라 한다. 같은 기계어 명령을 쓰면서 약속이 다른 것이다. 리눅스용으로 빌드한 목적 파일을 윈도 프로그램에 이어 붙일 수 없는 이유가 여기에 있다.

둘째, 반환값을 어디에 두는가. 이것도 크기에 따라 갈린다.

큰 구조체를 돌려주는 함수는 사실 인자가 하나 더 있는 셈이다 — 결과를 쓸 자리의 주소다. 소스 어디에도 없는 이 인자가 ABI 의 일부다.

셋째, 기본 타입의 크기. 여기서 가장 자주 데인다.

long에 포인터를 담는 코드가 리눅스에서 멀쩡히 돌다가 윈도에서 무너지는 고전적인 사고가 이 표 한 줄에서 나온다. 폭이 중요하면 <stdint.h>의 int64_t처럼 폭을 이름에 적은 타입을 쓴다(28장).

넷째, 이름 규칙. C 는 심볼 이름을 거의 장식하지 않는다 — greet 는 그냥 greet 다. 일부 옛 플랫폼이 밑줄을 앞에 붙였을 뿐이다. C++ 는 정반대로 타입까지 이름에 녹여 넣는데(이름 장식, name mangling), 그래서 C++ 에서 C 함수를 부르려면 extern "C" 로 「이 이름은 장식하지 말라」고 일러 주어야 한다. 헤더에서 자주 보는 그 관용구의 정체가 이것이다.

57.4 무엇이 ABI 를 깨뜨리는가#

여기서 한 가지 원리만 붙들면 나머지는 따라온다.

헤더는 호출자 안으로 복사된다. 그래서 헤더에 적힌 구조체의 모양, 매크로의 값, 인라인 함수의 몸통은 라이브러리가 아니라 호출자의 기계어에 굳어 박힌다.

라이브러리만 새로 빌드하고 호출자를 그대로 두면, 굳어 박힌 옛 모양과 새 라이브러리가 만난다. 컴파일러는 번역 단위를 하나씩만 보고, 링커는 이름을 맞출 뿐 배치를 비교하지 않는다. 그래서 이 사고는 조용하다.

/* 헤더와 라이브러리가 어긋나면 --- 링커는 아무 말도 하지 않는다.

   두 번역 단위가 같은 이름의 구조체를 서로 다른 모양으로 알고 있다.
   호출자는 옛 헤더로 빌드된 채 남아 있고, 라이브러리만 새로 빌드된 상황이다.
   여기서는 구조체를 실제로 주고받지 않는다 --- 각자 무엇을 믿는지만 찍는다. */
#include <stddef.h>
#include <stdio.h>
#include "conf_v1.h"

void lib_report(void);

int main(void)
{
    puts("the same name, two different shapes:");
    printf("  caller (not rebuilt, v1.0) believes:\n");
    printf("    sizeof(struct conf)          = %zu\n", sizeof(struct conf));
    printf("    offsetof(struct conf, width) = %zu\n", offsetof(struct conf, width));
    printf("    offsetof(struct conf, height)= %zu\n", offsetof(struct conf, height));
    lib_report();

    puts("\nnothing in the build complained:");
    puts("  the compiler saw one translation unit at a time,");
    puts("  and the linker matches names, not layouts.");
    printf("\nhad a struct crossed the boundary, the caller would write height at"
           " offset %zu\n", offsetof(struct conf, height));
    puts("  and the library would read it from offset 8 --- a silent wrong answer.");
    return 0;
}

the same name, two different shapes:
  caller (not rebuilt, v1.0) believes:
    sizeof(struct conf)          = 8
    offsetof(struct conf, width) = 0
    offsetof(struct conf, height)= 4
  library (rebuilt, v1.1) believes:
    sizeof(struct conf)          = 12
    offsetof(struct conf, width) = 0
    offsetof(struct conf, height)= 8

nothing in the build complained:
  the compiler saw one translation unit at a time,
  and the linker matches names, not layouts.

had a struct crossed the boundary, the caller would write height at offset 4
  and the library would read it from offset 8 --- a silent wrong answer.

같은 이름의 구조체를 두 번역 단위가 서로 다른 모양으로 알고 있는데, 빌드 어디에서도 경고가 나오지 않았다. 만약 이 구조체가 경계를 넘나들었다면 호출자는 height 를 4번지에 쓰고 라이브러리는 8번지에서 읽었을 것이다 — 아무도 죽지 않고, 답만 틀린다.

57.5 깨뜨리지 않고 고치는 법#

그러면 라이브러리는 영원히 못 고치는가. 그렇지 않다. 오래 사는 라이브러리들은 처음부터 고칠 여지를 남겨 두고 설계한다.

• 불투명 포인터. 구조체의 모양을 헤더에 적지 않고 이름만 알린다 (typedef struct conf conf;). 호출자는 크기도 배치도 모르므로 박힐 것이 없다. 대신 만들고 읽고 고치는 일을 전부 함수로 내놓는다. 배치를 마음껏 바꿀 수 있는 대신 호출 한 번이 더 든다.
• 크기를 함께 넘긴다. 구조체 첫 멤버에 size_t size 를 두고 호출자가 자기가 아는 크기를 채우게 한다. 라이브러리는 그 수를 보고 「이 호출자는 옛 판이구나」를 안다. 운영체제 API 들이 즐겨 쓰는 방법이다.
• 자리를 미리 비워 둔다. void *reserved[4] 같은 여유를 두고, 나중에 그 자리를 쓴다. 크기가 바뀌지 않으니 배치도 그대로다.
• 고치지 말고 더한다. render() 를 바꾸는 대신 render_ex() 를 새로 내놓는다. 투박하지만 확실하다.
• 심볼 버전. 한 라이브러리 안에 같은 이름의 옛 판과 새 판을 함께 두고, 옛 프로그램은 옛 판으로 잇는다. glibc 가 이 방법으로 수십 년째 호환을 지키고 있다. 그마저 감당이 안 되면 soname 을 올린다 — libfoo.so.2 와 libfoo.so.3 은 서로 다른 라이브러리이므로 한 시스템에 공존한다.

57.6 위치 독립 코드(PIC) — 왜 라이브러리는 이렇게 지어야 하는가#

공유 라이브러리에는 풀어야 할 문제가 하나 있다. 같은 라이브러리가 프로세스마다 다른 주소에 들어간다. 그런데 기계어 안의 주소는 어딘가에 박혀 있어야 한다.

가장 소박한 답은 「적재할 때 코드 안의 주소들을 고쳐 쓰는 것」이다. 이 방법에는 치명적인 대가가 있다. ★ 코드 페이지를 고치는 순간 그 페이지는 더 이상 공유될 수 없다. 여덟 개의 프로세스가 같은 라이브러리를 쓰면 코드가 물리 메모리에 한 벌만 있어야 하는데, 각자 다르게 고쳐 쓰면 여덟 벌이 된다. 공유 라이브러리의 존재 이유가 무너지는 것이다.

그래서 나온 것이 위치 독립 코드(position-independent code, PIC)다. 발상은 간단하다 — 코드는 절대 고치지 않고, 고쳐야 할 주소는 전부 「표」에 모아 둔다. 표는 데이터이므로 프로세스마다 따로 가져도 아깝지 않다.

실물로 보면 분명하다. int counter; int bump(void){ return ++counter; }를 -fPIC -shared로 빌드해 objdump로 뜯어본 결과다(x86-64).

bump:
  mov 0x2ec9(%rip),%rdx     ← GOT 에서 counter 의 주소를 읽는다
  mov (%rdx),%eax           ← 그 주소의 값을 읽는다
  add $0x1,%eax
  mov %eax,(%rdx)

★ 읽기가 두 번이다. 41장에서 배열과 포인터를 가른 바로 그 구조 — 「주소를 먼저 읽고, 그다음 값을 읽는다」 — 가 여기서 다시 나온다. PIC 의 비용이란 결국 이 한 걸음이다.

함수 쪽은 PLT 를 거친다.

bump@plt:
  jmp *0x2fc2(%rip)         ← GOT 항목으로 뛴다
  push $0x1                 ← 아직 안 이어졌으면 여기로 떨어진다
  jmp  <동적 링커>           ← 링커가 주소를 채우고 다시 뛴다

이 두 줄이 게으른 결합의 기계장치다. 처음 부를 때는 동적 링커가 불려 와 GOT 항목을 채우고, 그 뒤로는 첫 jmp 한 번으로 곧장 간다.

57.7 이름이 겹치면 갈아치워진다 — interpositioning#

앞 절에서 「기본이 외부 연결」이라는 성질을 보았다. 그 성질이 동적 링크와 만나면 놀라운 일이 생긴다. 내가 만든 함수가 라이브러리 함수를 조용히 대신할 수 있다.

이것을 가로채기(interpositioning)라 한다. 동적 링커는 심볼을 찾을 때 정해진 순서로 뒤지고, 먼저 찾은 것을 쓴다. 그래서 내 프로그램에 malloc이라는 이름의 전역 함수가 있으면, 라이브러리 안쪽에서 일어나는 malloc 호출까지 내 것으로 간다.

★ 여기서 두 가지가 겹쳐야 사고가 된다. 하나는 함수가 기본으로 전역이라는 것, 다른 하나는 컴파일러가 이 재정의를 오류로 보지 않는다는 것이다. 후자는 C 의 오랜 태도 때문이다 — 프로그래머가 의도했다고 가정한다.

/* 내 파일 안, static 없이 */
char *mktemp(char *tpl) { ... }      /* 표준 라이브러리에도 있는 이름 */
int   index(int i)      { ... }      /* 오래된 유닉스 함수 이름 */

이진 수준의 약속을 배웠다. 그런데 앞 장에서 #include와 #ifndef가 또 나왔다 — 17장에서 “전처리기는 C를 모르는 텍스트 도구”라 하고 지나친 그 층이다. 곧 그 층을 정면으로 열고, 소스 코드가 프로그램이 되기까지의 정식 단계까지 본다.