リンカの動作原理を徹底分析 (2008)
(lwn.net)- 散在していた Ian Lance Taylor の 20回連載リンカエッセイをまとめて追えるよう、LWN のユーザーが目次として整理
- 原文は
goldリンカの作者である Ian Lance Taylor の文章で、番号中心だった記事群をセクション見出しベースで再構成し、探しやすくまとめている - 前半ではリンカの概念、個人の経歴、動的リンク、オブジェクトファイル形式、共有ライブラリ、ELF シンボル、再配置、TLS 最適化までを扱う
- 後半ではシンボル解決、静的/動的リンクの比較、リンク時最適化、COMDAT、C++ テンプレートのインスタンス化、例外フレーム、インクリメンタルリンクへと続く
- 目次とコメントは public domain として公開されており、複製・利用・派生作業に制限はない
20回連載リンカエッセイを探しやすくまとめた目次
- Ian Lance Taylor による 20回連載のリンカ記事を、続けて読みやすい目次として整理
- Ian のブログや LWN では、うまくまとまった目次を見つけにくかったため、別途目次を作成
- 記事 URL は連番になっているが、各記事のテーマをひと目で把握するには、この目次が便利
- 各記事は番号だけで呼ばれているため、見出しは主に Ian の セクション見出しから取って構成
含まれている記事一覧
- Introduction, personal history, first half of what's-a-linker: 紹介、個人の経歴、リンカとは何かの前半
- What's-a-linker: Dynamic linking, linker data types, linker operation: 動的リンク、リンカのデータ型、リンカの動作
- Address spaces, Object file formats: アドレス空間とオブジェクトファイル形式
- Shared Libraries: 共有ライブラリ
- More Shared Libraries -- specifically, linker implementation; ELF Symbols: 共有ライブラリの補足、リンカ実装、ELF シンボル
- Relocations, Position Dependent Shared Libraries: 再配置と位置依存共有ライブラリ
- Thread Local Storage (TLS) optimization: TLS 最適化
- ELF Segments and Sections: ELF セグメントとセクション
- Symbol Versions, Relaxation optimization,: シンボルバージョンと relaxation 最適化
- Parallel linking: 並列リンク
- Archive format: アーカイブ形式
- Symbol resolution: シンボル解決
- Symbol resolution from the user's point of view; Static Linking vs. Dynamic Linking: ユーザー視点でのシンボル解決、静的リンクと動的リンクの比較
- Link time optimization, aka Whole Program optimization; Initialization Code: リンク時最適化、全体プログラム最適化、初期化コード
- COMDAT sections: COMDAT セクション
- C++ Template Instantiation, Exception Frames: C++ テンプレートのインスタンス化と例外フレーム
- Warning Symbols,: 警告シンボル
- Incremental Linking: インクリメンタルリンク
- __start and __stop Symbols, Byte Swapping:
__start、__stopシンボルとバイトスワップ - Last post; Update on gold's status: 最終回と
goldの状況アップデート
公開条件
- この目次とコメントは public domain として公開されている
- 利用、複製、上演、派生作業の作成に制限はなく、追加の許可も不要
1件のコメント
Hacker News のコメント
誰かが Calibre レシピで全体を1冊の電子書籍にまとめたものをリンクしていたので、必要な人向けに成果物を置いておく
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 が本にしてくれていたら本当に良かった
ただ、Ian が全章を1ページで見られる版を提供してくれたら、という思いはある
https://www.airs.com/blog/archives/51
アセンブリコードでパターンマッチングを行い、シーケンスを再配置したり再利用したりする内容
以前のコメント集: https://news.ycombinator.com/item?id=27445981
メモリが限られていた時代にリンカがなぜ生まれたのかは理解できる
ただ、現代のシステムのようにメモリが豊富な環境でも、リンカがまだ必要なのか気になる。さらに共有ライブラリは、今年初めに阻止された xz 攻撃のようにサプライチェーン攻撃の経路になるのではないかとも思う
Raspberry Pi のような環境も依然として考慮すべきだ。共有ライブラリがアプリ自体より危険な攻撃経路だとは考えにくい。静的バイナリをダウンロードしても、その中に何が入っているかは分からないし、皆がダウンロードして使っている Docker イメージの半分をなぜ信用しているのかも分からないが、とにかくそうやって使っている
すべてのソースファイルを同時に、まったく同じビルドオプションで処理しない限り、成果物を結合しなければならない。現代的な LTO があっても、コンパイラが通常、プログラムの全ファイルをソースコードレベルで見ることはできず、C ライブラリと C++ ライブラリはたいてい別物だ。複数の言語がプログラム全体を単一のコンパイル・アセンブル段階で作らない限り、成果物を結合する何かが必要で、それがリンカだ。すべてを静的にビルドしても、プログラムが実行される正確なアドレスをハードコードしない限り、ランタイムリンカの必要性は消えないし、その方式は ASLR のようなセキュリティ手法と衝突する
メモリと CPU が豊富だという考え方は、ハードウェアが何桁も速くなったにもかかわらず、ユーザー体験が目に見えて良くならない理由の一つだと思う