リンカー（コンピューティング）

コンピューティングにおいて、リンカーまたはリンク エディターは、1 つ以上のオブジェクト ファイル (コンパイラまたはアセンブラによって生成される) を受け取り、それらを1つの実行可能ファイル、ライブラリファイル、または別の「オブジェクト」ファイルに結合するコンピュータ システム プログラムです。

出力を直接メモリに書き込むより単純なバージョンはローダーと呼ばれますが、ロードは通常別のプロセスと見なされます。^{[1] [2]}

コンピュータ プログラムは通常、複数の部分またはモジュールで構成されます。これらの部分/モジュールは、単一のオブジェクト ファイル内に含まれている必要はなく、そのような場合には、他のモジュールへのアドレスとしてシンボルを使用して相互に参照し、実行のためにリンクされるとメモリ アドレスにマップされます。

リンクのプロセスは、最終的にこれらの独立した部分を結合することを目的としていますが、ソースレベルでそれらを個別に開発する理由はたくさんあります。これらの理由の中には、モノリシックな全体に対していくつかの小さな部分を整理することが容易であることや、ソフトウェア アーキテクチャの複雑さを管理し、長期的な保守性を向上させるために不可欠な、個々の部分の目的と責任をより適切に定義できることなどがあります。

通常、オブジェクト ファイルには次の 3 種類のシンボルが含まれます。

• 定義された「外部」シンボル（「パブリック」または「エントリ」シンボルと呼ばれることもある）により、他のモジュールから呼び出すことができる。
• 定義されていない「外部」シンボル。これらのシンボルが定義されている他のモジュールを参照します。
• 再配置を容易にするためにオブジェクト ファイル内で内部的に使用されるローカル シンボル。

ほとんどのコンパイラでは、各オブジェクト ファイルは 1 つの入力ソース コード ファイルをコンパイルした結果です。プログラムが複数のオブジェクト ファイルで構成されている場合、リンカーはこれらのファイルを統合された実行可能プログラムに結合し、処理の進行に合わせてシンボルを解決します。

リンカーは、ライブラリまたはランタイム ライブラリと呼ばれるコレクションからオブジェクトを取得できます。ほとんどのリンカーは、出力実行ファイルに静的ライブラリ内のすべてのオブジェクト ファイルを含めるのではなく、他のオブジェクト ファイルまたはライブラリによって直接的または間接的に参照されるライブラリのオブジェクト ファイルのみを含めます。ただし、共有ライブラリの場合は、実行時にどの関数またはメソッドが呼び出されるかわからないため、実行時にライブラリ全体をロードする必要があります。したがって、ライブラリのリンクは反復的なプロセスになる可能性があり、参照されるモジュールによっては、追加のモジュールをリンクする必要があるなどです。ライブラリはさまざまな目的で存在し、通常は 1 つ以上のシステム ライブラリがデフォルトでリンクされます。

リンカーは、プログラムのアドレス空間内のオブジェクトの配置も行います。これには、特定のベース アドレスを前提とするコードを別のベースに再配置することが含まれる場合があります。コンパイラは、オブジェクトがどこに配置されるかはほとんどわからないため、固定のベース位置 (たとえば、ゼロ) を前提とすることがよくあります。マシン コードの再配置には、絶対ジャンプ、ロード、およびストアの再ターゲットが含まれる場合があります。

リンカーによる実行可能出力は、最終的にメモリにロードされるとき (実行直前) に、別の再配置パスが必要になる場合があります。このパスは、通常、仮想メモリを提供するハードウェアでは省略されます。すべてのプログラムは独自のアドレス空間に配置されるため、すべてのプログラムが同じベース アドレスにロードされても競合は発生しません。実行可能ファイルが位置独立実行可能ファイルである場合も、このパスは省略できます。

SINTRAN IIIなどの一部のUnix系OSでは、リンカーによって実行されるプロセス（オブジェクトファイルをプログラムに組み立てる）はロード（実行可能コードをファイルにロードする）と呼ばれていました。^[3]さらに、一部のオペレーティングシステムでは、同じプログラムがプログラムのリンクとロードの両方のジョブを処理します（動的リンク）。

多くのオペレーティング システム環境では、動的リンクが許可されており、一部の未定義シンボルの解決はプログラムの実行まで延期されます。つまり、実行可能コードには、未定義シンボルと、それらの定義を提供するオブジェクトまたはライブラリのリストがまだ含まれています。プログラムをロードすると、これらのオブジェクト/ライブラリもロードされ、最終的なリンクが実行されます。

このアプローチには 2 つの利点があります。

• 頻繁に使用されるライブラリ (標準システム ライブラリなど) は、実行可能ファイルごとに重複して保存するのではなく、 1 つの場所にのみ保存する必要があります。これにより、限られたメモリとディスク領域を節約できます。
• ライブラリ関数のバグがライブラリの置き換えによって修正されたり、パフォーマンスが向上したりした場合は、その関数を動的に使用しているすべてのプログラムが再起動後に修正の恩恵を受けます。静的リンクによってこの関数が組み込まれているプログラムは、最初に再リンクする必要があります。

欠点もあります:

• Windowsプラットフォームでは「DLL 地獄」として知られていますが、新しいバージョンが正しく下位互換性を保っていない場合、互換性のない更新されたライブラリは、以前のバージョンのライブラリの動作に依存していた実行可能ファイルを壊してしまいます。
• プログラムは、それが使用するライブラリとともに、パッケージとして認定される可能性があります (たとえば、正確性、ドキュメント要件、パフォーマンスなどについて)。ただし、コンポーネントを置き換えることができる場合は認定されません (これは、重要なシステムでの自動 OS 更新に反対する主張でもあります。どちらの場合も、OS とライブラリは認定された環境の一部を形成します)。

封じ込められた環境や仮想環境により、システム管理者はこれらの個々の長所と短所をさらに軽減したり、トレードオフしたりできるようになります。

静的リンクは、リンカーがプログラムで使用されるすべてのライブラリ ルーチンを実行可能イメージにコピーした結果です。動的リンクよりも多くのディスク領域とメモリが必要になる場合がありますが、実行するシステム上にライブラリが存在する必要がないため、移植性が高くなります。また、静的リンクでは、各プログラムに必要なライブラリ ルーチンのバージョンが正確に含まれ、他のプログラムと競合しないため、「DLL 地獄」も回避できます。ライブラリからいくつかのルーチンだけを使用するプログラムでは、ライブラリ全体をインストールする必要はありません。

コンパイラは最終出力におけるオブジェクトのレイアウトに関する情報を持たないため、別のオブジェクトのアドレスに要件を課す、より短い命令やより効率的な命令を利用することはできません。たとえば、ジャンプ命令は絶対アドレスまたは現在の位置からのオフセットを参照することができ、オフセットはターゲットまでの距離に応じて異なる長さで表現できます。最初に最も保守的な命令 (通常はプラットフォームに応じて最大の相対または絶対バリアント) を生成し、緩和ヒントを追加することで、最終リンク中に短い命令やより効率的な命令に置き換えることができます。ジャンプ最適化に関しては、これは自動ジャンプサイジングとも呼ばれます。^[4]このステップは、すべての入力オブジェクトが読み取られ、一時的なアドレスが割り当てられた後にのみ実行できます。その後、リンカー緩和パスによってアドレスが再割り当てされ、これにより、より多くの潜在的な緩和が発生する可能性があります。一般に、置換されたシーケンスは短くなるため、このプロセスは常に、オブジェクトの固定順序が与えられた場合に最良のソリューションに収束します。そうでない場合、緩和が競合する可能性があり、リンカーはいずれかのオプションの利点を比較検討する必要があります。

命令の緩和は通常はリンク時に行われますが、内部モジュールの緩和はコンパイル時の最適化プロセスの一部としてすでに行われている場合があります。場合によっては、緩和は再配置プロセスの一部としてロード時に行われることもあれば、動的なデッドコード除去技術と組み合わせて行われることもあります。

IBM System/360 メインフレーム環境 ( OS/360、z/Architectureメインフレームのz/OSなど) では、このタイプのプログラムはリンケージ エディターと呼ばれます。名前が示すように、リンケージエディターには、個々のプログラム セクションの追加、置換、および/または削除を可能にする追加機能があります。OS/360 などのオペレーティング システムには、プログラムのコンポーネント セクションに関する補足データを含む実行可能ロード モジュールの形式があるため、個々のプログラム セクションを置き換えたり、プログラムの他の部分を更新して、リンケージ エディターでプロセスの一部として再配置可能なアドレスやその他の参照を修正したりできます。

この方法の利点の 1 つは、中間オブジェクト ファイルをすべて保持したり、変更されていないプログラム セクションを再コンパイルしたりしなくても、プログラムを保守できることです。また、プログラムの更新を、置き換えるオブジェクト モジュールだけを含む小さなファイル (元々はカード デッキ) の形式で配布することもできます。このようなシステムでは、オブジェクト コードは 80 バイトのパンチ カード イメージの形式であるため、その媒体を使用して更新をシステムに導入できます。OS/360 の後のリリースおよびそれ以降のシステムでは、ロード モジュールにコンポーネント モジュールのバージョンに関する追加データが含まれており、更新の追跡可能な記録が作成されます。また、既にリンクされているロード モジュールから オーバーレイ構造を追加、変更、または削除することもできます。

「リンケージ エディター」という用語は、プログラムがテキスト エディターのようにユーザー対話モードで動作することを意味するものではありません。これは、パンチ カード、DASD、磁気テープなどの順番に整理されたファイルでユーザーが編集コマンドを提供するバッチ モード実行を目的としています。

リンケージ編集（IBM命名法）または統合またはコレクション（ICL命名法）は、リンケージエディターまたは統合者がさまざまな部分を再配置可能なバイナリに結合する行為を指しますが、ターゲットアドレスの絶対バイナリへのロードと再配置は通常、別のステップと見なされます。^[2]

当初、リンカーは、生成された出力オブジェクト ファイルの配置に関して、ユーザーに非常に限られた制御しか与えませんでした。ターゲット システムが組み込みシステムなどのさまざまなメモリ要件で複雑になるにつれて、セグメントのベース アドレスの定義など、特定の要件に合わせて出力オブジェクト ファイルを生成するための制御をユーザーに与えることが必要になりました。このために、リンカー制御スクリプトが使用されました。

UnixおよびUnix系システムでは、リンカーは「ld」として知られています。「ld」という名前の由来は「LoaDer」と「Link eDitor」です。「loader」という用語は、リンク処理中に他のプログラムから外部シンボルをロードするプロセスを説明するために使用されました。^[5]

GNU リンカー (または GNU ld) は、GNU プロジェクトによるUnix コマンド ld のフリー ソフトウェア実装です。GNU ld はリンカーを実行し、ソフトウェア プロジェクトのコンパイル中に作成されたオブジェクト ファイルから実行可能ファイル (またはライブラリ) を作成します。リンカー スクリプトをGNU ld に渡すことで、リンク プロセスをより細かく制御できます。^{[6] GNU リンカーは}、GNU バイナリ ユーティリティ(binutils) の一部です。binutils では、2 つのバージョンの ld が提供されています。bfdに基づく従来の GNU ldと、 gold と呼ばれる「合理化された」ELF のみのバージョンです。

GNU ldのコマンドラインとリンカースクリプトの構文は、Unix系の世界の多くで事実上の標準となっています。LLVMプロジェクトのリンカーは、lldはドロップイン互換に設計されており、^[7]GNUコンパイラで直接使用できます。別のドロップイン代替品であるmoldは、高度に並列化され、高速化された代替品であり、GNUツールでもサポートされています。^[8]

• Fraser, Christopher W.; Hanson , David R. (1982 年 4 月)。「マシンに依存しないリンカー」。ソフトウェア:実践と経験。12 ( 4 )。John Wiley & Sons Ltd : 351–366。doi :10.1002/spe.4380120407。ISSN 1097-024X。S2CID  206508204  。
• オペレーティング システム 360 - リンケージ エディター (E) - プログラム ロジック マニュアル(PDF) (第 3 版)。International Business Machines Corporation。1969年 7 月 23 日 [1967 年 6 月]。プログラム番号 360S-ED-510。ファイル番号 S360-31。フォーム Y28-6610-2。2007年 10 月 1 日にオリジナル(PDF)からアーカイブ。2020年 3 月 7 日に取得。
• Jones, Douglas W. (1983年8 月)。「オブジェクト コードとしてのアセンブリ言語」。ソフトウェア:実践と経験。13 (8)。John Wiley & Sons Ltd : 715–725。doi : 10.1002 /spe.4380130806。ISSN 1097-024X。S2CID  42995338  。
• Levine, John R. (2000) [ 1999年 10 月]。リンカーとローダー。Morgan Kaufmann ソフトウェア エンジニアリングおよびプログラミング シリーズ (第 1 版)。サンフランシスコ、米国: Morgan Kaufmann。ISBN 1-55860-496-0. OCLC  42413382 . 2020年1月12日閲覧。コード: [1] 訂正: [2]
• Presser, Leon ; White, John R. (1972 年 9 月). 「リンカーとローダー」(PDF) . ACM Computing Surveys . 4 (3). カリフォルニア大学サンタバーバラ校、カリフォルニア州、米国: 149–167. doi :10.1145/356603.356605. S2CID  5694671. 2020 年 3 月 7 日にオリジナルからアーカイブ(PDF)されました。2020 年 3 月 7 日に取得。（19ページ）
• Ramsey, Norman (1996 年 5 月). 「カリー化によるマシン命令の再配置」(PDF) . ACM SIGPLAN Notices . 31 (5): 226–236. doi :10.1145/249069.231429. 2020 年 5 月 18 日のオリジナルからアーカイブ(PDF)。

無料辞書のウィクショナリーで「linker」を調べてください。

• イアン・ランス・ジャスティンのLinkersブログエントリ
• リンカーとローダー、Sandeep Grover によるLinux Journal の記事
• アセンブリ言語開発用の無料ツールの完全なコレクションを入手できる場所の別のリスト
• GNU リンカーマニュアル
• LLD - LLVM リンカー
• ld(1): GNU リンカー –  Linuxユーザーマニュアル– ユーザーコマンド