54 여러 파일 — 분할과 링크

54.1 번역 단위와 헤더

전처리가 끝난 소스 파일 하나 — #include가 전부 펼쳐진 결과 — 를 번역 단위(translation unit)라 부른다. 컴파일러는 언제나 번역 단위 하나만 본다. 여러 파일 프로그램이란 번역 단위 여럿을 각각 목적 파일로 만든 뒤, 링커가 하나로 잇는 것이다.

세 파일짜리 예제로 분업을 본다.

/* 여러 파일 예제 — 이 파일은 greet의 선언만 보고 컴파일된다. */
#include "greet.h"

int main(void)
{
    greet("world");
    printf_count();
    return 0;
}

Hello, world!
greet was called 1 times

greet.h(헤더)에는 선언만 있다 — 계약 서명. greet.c에는 정의가 있고, main.c는 헤더만 포함해 계약을 알고 호출한다. 컴파일은 각각 따로 되고, 링커가 greet 호출과 정의를 이어 준다.

헤더의 #ifndef GREET_H ... #define ... #endif는 포함 보호(include guard)다. 헤더가 여러 경로로 두 번 붙어도 내용이 한 번만 펼쳐지게 하는 관용구로, 두 번 선언되면 오류가 나는 것들(구조체 정의 등)을 막는다. 실무에서는 #pragma once 한 줄로 대신하는 경우도 많다(표준은 아니지만 주요 컴파일러가 전부 지원한다).

54.2 연결 — 이름이 파일 경계를 넘는가

이름에는 스코프(24장) 말고 또 하나의 성질이 있다 — 연결(linkage), 즉 다른 번역 단위에서 그 이름을 볼 수 있는가다.

• 외부 연결: 파일 밖에서도 보인다. 함수와 전역 변수의 기본값이다.
• 내부 연결: 이 번역 단위 안에서만 보인다. 파일 수준 선언에 static을 붙이면 된다 — 예제의 static int calls가 그 예다.

static이라는 낱말이 44장(정적 수명)과 여기(내부 연결)에서 다른 뜻으로 쓰이는 것은 C의 유명한 낱말 재활용이다 — 함수 안의 static은 수명을, 파일 수준의 static은 연결을 뜻한다.

내부 연결은 실무의 기본 무기다. C에는 프로그래머가 새로 파는 이름 공간이 없어서(55장) 외부 이름은 모두 한 마당에서 부딪히는데, 파일 안에서만 쓰는 도우미 함수· 변수에 static을 붙이면 그 이름은 아예 바깥 마당에 나가지 않는다 — 충돌도 없고, 컴파일러가 더 공격적으로 최적화할 수 있다(그 이름이 다른 파일에서 불릴 리 없음을 아니까 — 13장의 편집자에게 주는 정직한 신호다). 이 무기를 포함해 이름 충돌(name collision)을 막는 방법 전체는 56장에서 다룬다.

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

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

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

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

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

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

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

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

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

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

54.5 위치 독립 코드(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)

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

함수 쪽은 PLT 를 거친다.

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

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

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

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

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

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

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

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