링커 작동 방식 심층 분석 (2008)

 (lwn.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 흩어져 있던 Ian Lance Taylor의 20부작 링커 에세이를 한 번에 따라갈 수 있도록 LWN 사용자가 목차로 정리함
  • 원문은 gold 링커 작성자인 Ian Lance Taylor의 글이며, 번호 중심의 글들을 섹션 제목 기반으로 다시 찾기 쉽게 묶음
  • 초반부는 링커 개념, 개인 이력, 동적 링킹, 오브젝트 파일 형식, 공유 라이브러리, ELF 심볼, 재배치, TLS 최적화까지 다룸
  • 후반부는 심볼 해석, 정적/동적 링킹 비교, 링크 타임 최적화, COMDAT, C++ 템플릿 인스턴스화, 예외 프레임, 증분 링킹으로 이어짐
  • 목차와 코멘트는 public domain으로 공개되어 복사, 사용, 파생 작업에 제한이 없음

20부작 링커 에세이를 찾기 쉽게 묶은 목차

  • Ian Lance Taylor의 20부작 링커 글을 연속적으로 읽기 쉬운 목차로 정리함
  • Ian의 블로그나 LWN에서 잘 연결된 목차를 찾기 어려워 별도 목차를 만들었음
  • 글 URL은 연속 번호지만, 각 글의 주제를 한눈에 보기 위한 목차가 유용함
  • 각 글은 번호로만 지칭되어, 제목은 주로 Ian의 섹션 제목에서 뽑아 구성함

포함된 글 목록

공개 조건

  • 이 목차와 코멘트는 public domain으로 공개됨
  • 사용, 복사, 공연, 파생 작업 생성에 제한이 없고 추가 허가도 필요 없음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 누군가 Calibre 레시피로 전체를 하나의 전자책으로 묶은 것을 링크했는데, 필요한 사람을 위해 결과물을 올려둠
    https://www.mediafire.com/folder/b8fdqx7eqcpdl/linker
    또는
    https://0x0.st/Xycy.azw3
    https://0x0.st/Xyct.epub
    https://0x0.st/Xycv.mobi
    https://0x0.st/Xycw.pdf

  • lld와 mold 링커를 작업한 개발자가 성능을 극한까지 밀어붙였음
    LLD(LLVM의 일부):
    https://llvm.org/devmtg/2017-10/slides/Ueyama-lld.pdf
    MOLD 링커:
    https://github.com/rui314/mold/blob/main/docs/design.md
    Apple도 mold와 비슷한 수준의 새 링커를 공개했는데, 이전 논의는 여기 있음: https://news.ycombinator.com/item?id=36218330

    • 이걸 볼 때마다 성능 추구는 좀처럼 끝나지 않는다는 영감을 받음
      LLD는 빠르게 만들려고 설계됐고 그 전의 Gold도 그랬지만, Mold가 둘 다 크게 앞질렀음

  • [2008] 글이지만 이 글들은 정말 금 같은 자료라 HN 첫 페이지에 다시 올라오는 건 늘 반가움

    • 링커 버그를 고친 사람이 있다는 얘기를 듣고 “얼마나 어렵겠어”라고 생각했다가, 이 글을 보고 생각이 바뀜
      정말 훌륭한 설명임

  • 이 글 시리즈는 가장 좋아하는 글 중 하나이고, 개인적으로 눈을 뜨게 해준 내용이 많았음
    인터넷이든 다른 곳이든 이 모든 정보를 한곳에 모아둔 자료는 없다고 생각함. Ian이 책으로 냈으면 정말 좋았겠음

    • John R. Levine의 Linkers and Loaders라는 책도 꽤 좋음
    • 20개 장을 전부 PDF로 인쇄해서 이제 개인용 책처럼 가지고 있음
      다만 Ian이 모든 장을 한 페이지에서 볼 수 있는 버전을 제공해줬으면 하는 바람이 있음

  • https://www.airs.com/blog/archives/51
    어셈블리 코드에서 패턴 매칭을 하고, 시퀀스를 재배치하거나 재사용하는 내용임

  • 이전 댓글 모음: https://news.ycombinator.com/item?id=27445981

  • 메모리가 제한적이던 시절에 링커가 왜 생겼는지는 이해됨
    그런데 현대 시스템처럼 메모리가 풍부한 환경에서도 링커가 여전히 필요한지 궁금함. 게다가 공유 라이브러리는 올해 초 막힌 xz 공격처럼 공급망 공격 경로가 되는 것 아닌가 싶음

    • flatpak이나 Docker 같은 걸 쓰는 게 유행인 건 알지만, 그래도 실행하는 GUI 앱마다 Gtk 인스턴스가 30개씩 뜨는 건 원하지 않음
      Raspberry Pi 같은 환경도 여전히 고려해야 함. 공유 라이브러리는 앱 자체보다 더 위험한 공격 경로라고 보긴 어려움. 정적 바이너리를 내려받아도 그 안에 뭐가 들어 있는지 알 수 없고, 다들 내려받아 쓰는 Docker 이미지 절반을 왜 신뢰하는지도 모르겠지만 어쨌든 그렇게 쓰고 있음
    • 컴파일러가 전체 프로그램을 한 번에 봐야 하거나, 아니면 여러 컴파일 단계의 결과물을 합치는 방법이 필요함
      모든 소스 파일을 동시에, 정확히 같은 빌드 옵션으로 처리하지 않는 이상 결과물을 결합해야 함. 현대적인 LTO가 있어도 컴파일러가 보통 프로그램의 모든 파일을 소스 코드 수준에서 보지는 못하고, C 라이브러리와 C++ 라이브러리는 대개 별개임. 여러 언어가 전체 프로그램을 단일 컴파일·어셈블리 단계로 만들지 않는 한 결과물을 합치는 무언가가 필요하고, 그게 링커임. 전부 정적으로 빌드해도 프로그램이 실행될 정확한 주소를 하드코딩하지 않는 한 런타임 링커 필요성이 사라지지 않으며, 그런 방식은 ASLR 같은 보안 기법과 충돌함
    • 정적 링크도 여전히 링크이며, 여러 목적 파일을 하나의 실행 파일로 합치려면 링커가 필요함
      메모리와 CPU가 풍부하다는 사고방식은 하드웨어가 몇 자릿수나 빨라졌는데도 사용자 경험이 눈에 띄게 좋아지지 않는 이유 중 하나라고 봄
    • 현대 시스템의 갑작스러운 메모리 풍요는 샌드박스, 패키저, 라이브러리, 프레임워크가 충분히 따라잡아 다 써버렸음
    • 코드 한 줄만 바꾼 빌드가 30분 안에 끝나길 원한다면, 전체 프로그램보다 작은 단위의 컴파일된 코드를 처리할 링커 비슷한 무언가가 필요함
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.