ダイナミックリンカー

コンピューティングにおいて、ダイナミック リンカーは、実行時に (「実行時」に)実行可能ファイルに必要な共有ライブラリをロードしてリンクするオペレーティング システムの一部です。ライブラリの内容を永続ストレージからRAMにコピーし、ジャンプ テーブルを埋めて、ポインタを再配置します。特定のオペレーティング システムと実行可能形式によって、ダイナミック リンカーの機能と実装方法が決まります。

リンクは、実行可能ファイルがコンパイルされるときに実行されるプロセスを指すことがよくあります。一方、ダイナミック リンカーは、外部共有ライブラリを実行中のプロセスにロードし、それらの共有ライブラリを実行中のプロセスに動的にバインドするオペレーティング システムの特別な部分です。このアプローチは、ダイナミック リンクまたは遅延リンクとも呼ばれます。

ダイナミック リンク ライブラリ(DLL) は、Microsoft WindowsおよびOS/2オペレーティング システムにおける共有ライブラリの概念のMicrosoftによる実装です。これらのライブラリのファイル拡張子は通常、( ActiveXコントロールを含むライブラリの場合)、または(レガシーシステム ドライバの場合) です。DLL のファイル形式は Windows EXEファイルと同じです。つまり、32 ビットおよび64 ビットWindows の場合はPortable Executable (PE) 、16 ビットWindows の場合はNew Executable (NE) です。EXE と同様に、DLL にはコード、データ、リソースを任意の組み合わせで含めることができます。 DLLOCXDRV

DLL と同じファイル形式だがファイル拡張子が異なり、リソース セクションのみを含む可能性のあるデータファイルは、リソース DLL と呼ばれることがあります。このような DLL の例には、拡張子 を持つ多言語ユーザー インターフェイス ライブラリ、拡張子 を持つアイコンライブラリ、拡張子およびを持つフォントファイルなどがあります。^[1]MUIICLFONFOT

ほとんどのUnix 系システムでは、ダイナミック リンカーを構成するマシン コードのほとんどは、実際には外部実行可能ファイルであり、オペレーティング システムカーネルがexec関数の呼び出しの結果として新しく構築されたプロセス アドレス空間で最初にロードして実行しますposix_spawn。リンク時に、使用する必要があるダイナミック リンカーのパスが実行可能イメージに埋め込まれます。

実行可能ファイルがロードされると、オペレーティング システム カーネルはそこから動的リンカーのパスを読み取り、この別の実行可能バイナリをロードして実行しようとします。その試行が、たとえばそのパスのファイルが存在しないなどの理由で失敗すると、元の実行可能ファイルの実行試行は失敗します。次に、動的リンカーは、最初の実行可能イメージと、それが依存するすべての動的リンク ライブラリをロードし、実行可能ファイルを起動します。その結果、動的リンカーのパス名は、オペレーティング システムのアプリケーション バイナリ インターフェイスの一部になります。

Solaris、64 ビット版のHP-UX、Linux、FreeBSD、NetBSD、OpenBSD、DragonFly BSDなど、実行可能イメージと動的ライブラリにELF を使用する Unix 系システムでは、使用すべき動的リンカーのパスは、リンク時に実行可能ファイルのセグメントのセクションに埋め込まれます。これらのシステムでは、動的にロードされる共有ライブラリは、ファイル名のサフィックス(共有オブジェクト) によって識別できます。.interpPT_INTERP.so

動的リンカーは、プログラムの実行中またはプログラムのリンク中に動作を変更するように影響を受ける可能性があり、この例は、さまざまなUnix系システムのランタイムリンカーのマニュアルページで見ることができます。^{[2] [3] [4] [5] [6]}LD_LIBRARY_PATHこの動作の一般的な変更は、およびLD_PRELOAD 環境変数の使用です。これらは、それぞれ、共有ライブラリを別の場所で検索したり、通常はロードおよびリンクされないライブラリを強制的にロードしてリンクしたりすることで、ランタイムリンクプロセスを調整します。一例として、zlibc ^[7]があります。これは、としても知られuncompress.so、^[a]LD_PRELOAD ハックを介して使用すると透過的な解凍を容易にします。その結果、BSDおよびLinuxシステムで、圧縮済み（gzip圧縮）ファイルデータを、ファイルが圧縮されていないかのように読み取ることができます。基本的に、ユーザーは基礎となるファイルシステムに透過的な圧縮を追加できますが、いくつかの注意事項があります。このメカニズムは柔軟性があり、同じコードを簡単に変更して、ファイルの読み取り中に、要求したユーザープロセスにデータを提供する前に、データの追加処理や代替処理を実行できます。^{[8] [9]}

Apple Darwinオペレーティング システム、およびそれをベースに構築されたmacOSおよびiOSオペレーティング システムでは、使用すべき動的リンカーのパスは、実行可能イメージ内のMach-Oロード コマンドの 1 つにリンク時に埋め込まれます。これらのシステムでは、動的にロードされる共有ライブラリは、ファイル名のサフィックスまたはフレームワークのバンドル.dylib内の配置によって識別できます。

ダイナミック リンカーは、ターゲット実行可能ファイルを共有ライブラリにリンクするだけでなく、ターゲット実行可能ファイルがリンク時に認識しているメモリ内の特定のアドレス ポイントにマシン コード関数を配置します。実行可能ファイルがダイナミック リンカーと対話する必要がある場合、実行可能ファイルは、それらの既知のアドレス ポイントの 1 つに対して、マシン固有の呼び出しまたはジャンプ命令を実行するだけです。macOS および iOS プラットフォーム上の実行可能ファイルは、プロセスの実行中にダイナミック リンカーと対話することがよくあります。実行可能ファイルがダイナミック リンカーと対話して、最初の起動から数時間後に、より多くのライブラリをロードし、より多くのシンボルを解決する可能性があることもわかっています。macOS または iOS プログラムがダイナミック リンカーと頻繁に対話する理由は、Apple のCocoaおよびCocoa Touch API と、それらが実装されている言語であるObjective-C の両方によるものです (詳細については、それぞれのメイン記事を参照してください)。

ダイナミック リンカーは、その動作の一部を変更するように強制することができます。ただし、他の Unix 系オペレーティング システムとは異なり、これらの変更は、ダイナミック リンカーによって無視される (場合によっては無視される) ヒントです。この例は、dyldのマニュアル ページで確認できます。^[10]DYLD_FRAMEWORK_PATHこの動作を変更する一般的な方法は、環境変数と環境変数の使用ですDYLD_PRINT_LIBRARIES。前述の変数の前者は、共有ライブラリの実行可能ファイルの検索パスを調整し、後者は、ロードおよびリンクされるライブラリの名前を表示します。

AppleのmacOSダイナミックリンカーは、 Darwinの一部としてリリースされたオープンソースプロジェクトであり、Appleのオープンソースdyldプロジェクトで見つけることができます。^[11]

AIXなどのXCOFFを使用する Unix 系オペレーティング システムでは、動的にロードされる共有ライブラリはファイル名サフィックス を使用します。 .a

動的リンカーは、プログラムの実行中またはプログラムのリンク中に動作を変更するように影響を受けることがあります。この動作を変更する一般的な方法は、LIBPATH 環境変数を使用することです。この変数は、共有ライブラリを別の場所で検索し、通常はロードおよびリンクされないライブラリを強制的にロードおよびリンクすることで、ランタイム リンク プロセスを調整します。

IBM OS/360 およびその後継製品におけるアセンブラ言語プログラムからの動的リンクは、通常、リンクされるライブラリ モジュールをプログラムで使用できるようにするオペレーティング システム ルーチンをアクティブにするスーパーバイザ コール命令を含む LINK マクロ命令を使用して行われます。ライブラリ モジュールは、制御カードで指定され、プログラムの特定の実行でのみ使用可能な「STEPLIB」または「JOBLIB」、PARMLIB の LINKLIST に含まれるライブラリ (システム起動時に指定)、またはシステム起動時に特定の再入可能モジュールがロードされる「リンク パック領域」に存在する場合があります。

Multicsオペレーティング システムでは、実行可能ファイルを含むすべてのファイルはセグメントです。現在のセグメントの一部ではないルーチンを呼び出すと、システムはメモリ内またはディスク上で参照されているセグメントを見つけ、それを実行中のプロセスのアドレス空間に追加します。動的リンクは通常の操作方法であり、静的リンク (バインダーを使用) は例外です。

動的リンクは、一般的にコンパイル時にリンクするよりも遅く（CPU サイクルを多く必要とする）^[12]。これは、実行時に実行されるほとんどのプロセスでも同様である。しかし、動的リンクは多くの場合、よりスペース効率が高い（実行時のディスク上およびメモリ内）。ライブラリが静的にリンクされている場合、実行中のすべてのプロセスは、呼び出されるライブラリ関数の独自のコピーにリンクされます。したがって、ライブラリが異なるプログラムによって何度も呼び出される場合、そのライブラリ内の同じ関数がシステムのメモリ内の複数の場所に複製されます。共有の動的ライブラリを使用すると、コンパイル時に各ファイルをライブラリの独自のコピーにリンクしてメモリ領域を無駄にする可能性がある代わりに、一度に 1 つのライブラリのコピーだけがメモリに格納され、メモリ領域が他の場所で使用できるようになります。^[13]さらに、動的リンクでは、ライブラリは実際に使用されている場合にのみロードされます。^[14]

• 直接バインディング
• DLL 地獄
• 動的ロード
• 遅延バインディング
• プレリンク
• 動的なデッドコードの除去

• Levine, John R. (2000) [ 1999年 10 月]。リンカーとローダー。Morgan Kaufmann ソフトウェア エンジニアリングおよびプログラミング シリーズ (第 1 版)。サンフランシスコ、米国: Morgan Kaufmann。ISBN 1-55860-496-0. OCLC  42413382. 2012年12月5日にオリジナルからアーカイブ。2020年1月12日閲覧。コード: [1][2] エラッタ: [3]

• ダイナミック リンクとロード、IECC.com
• Linux と Windows のダイナミック リンク、パート 1、Symantec.com
• Linux 動的ライブラリの分析、IBM.com