実行時リンカー

リンカーは、動的リンクを使用する実行可能ファイルを作成するとき、PT_INTERP 型のプログラムヘッダー要素を実行可能ファイルに付加し、実行時リンカーをプログラムインタプリタとして呼び出すようにシステムに指示します。exec(2) と実行時リンカーは、協調してプログラムのプロセスイメージを作成します。この処理には以下の動作が伴います。

• 実行可能ファイルのメモリーセグメントをプロセスイメージに付加する

• 共有オブジェクトメモリーセグメントをプロセスイメージに付加する

• 実行可能ファイルと共有オブジェクトに対して再配置を行う

• 実行可能ファイルの読み取りに使用されたファイル記述子を閉じる (このファイル記述子が実行時リンカーに与えられている場合)

• 対応付けされるオブジェクトに依存する .init セクションを呼び出す。「初期化および終了関数」を参照

• プログラムがあたかも exec(2) から直接制御を受け取ったように見えるように、プログラムに制御を渡す

リンカーはまた、実行時リンカーが実行可能オブジェクトファイルと共有オブジェクトファイルを処理するときの手助けになるさまざまなデータを作成します。先出のプログラムヘッダーセグメントで示されているとおり、これらのデータは読み込み可能セグメントに存在します。したがって、これらのデータは実行時に使用可能です。(正確なセグメント内容はプロセッサに固有であることを思い出してください。)

• SHT_DYNAMIC 型の .dynamic セクションには、さまざまなデータが存在する。このセクションの始まりに存在する構造体には、他の動的リンク情報のアドレスが存在する。

• SHT_HASH 型の .hash セクションには、シンボルハッシュテーブルが存在する

• SHT_PROGBITS 型の .got セクションと .plt セクションには、2 つの別個のテーブルが存在する。つまり、大域オフセットテーブルと手続きリンクテーブルが存在する。次の項では、オブジェクトファイルのメモリーイメージを作成するために実行時リンカーがテーブルをどのように使用するかを説明する

「プログラムの読み込み (プロセッサ固有)」で説明しているとおり、共有オブジェクトは、ファイルのプログラムヘッダーテーブルに記録されているアドレスとは異なる仮想メモリーアドレスに置かれることができます。実行時リンカーは、アプリケーションが制御を取得する前に、メモリーイメージを再配置して絶対アドレスを更新します。プログラムヘッダーテーブルに指定されているアドレスにライブラリが読み込まれた場合、絶対アドレス値は正しいのですが、通常、このようなことは起きません。

実行時リンカーは、手続きリンクテーブルエントリを遅延評価できます。その場合、呼び出されない関数の解決/再配置に費やされる無駄を回避できます。詳細は、「手続きリンクテーブル (プロセッサに固有)」を参照してください。

プロセス環境 (exec(2) を参照) に、空ではない値を持つ LD_BIND_NOW という変数が存在する場合、実行時リンカーは、プログラムに制御を渡す前にすべての再配置を処理します。たとえば、以下の各環境エントリは、この動作を指定します。

LD_BIND_NOW=1  LD_BIND_NOW=on  LD_BIND_NOW=off

動的セクション

オブジェクトファイルが動的リンクに関係している場合、このオブジェクトファイルのプログラムヘッダーテーブルには、PT_DYNAMIC 型の要素が存在します。このセグメントには、.dynamic セクションが存在します。特殊なシンボル _DYNAMIC は、このセクションを示します。このセクションには、以下の構造体 (sys/link.h で定義される) の配列が存在します。

typedef struct {
        Elf32_Sword d_tag;
        union {
                Elf32_Word      d_val;
                Elf32_Addr      d_ptr;
                Elf32_Off       d_off;
        } d_un;
} Elf32_Dyn;
typedef struct {
        Elf64_Xword d_tag;
        union {
                Elf64_Xword     d_val;
                Elf64_Addr      d_ptr;
        } d_un;
} Elf64_Dyn;

このタイプの各オブジェクトの場合、d_tag は d_un の解釈に影響します。

d_val

このオブジェクトは、さまざまに解釈される整数値を表します。

d_ptr

このオブジェクトは、プログラムの仮想アドレスを表わします。すでに述べたように、ファイルの仮想アドレスは、実行時にメモリーの仮想アドレスに一致しないことがあります。実行時リンカーは、動的構造体に存在するアドレスを解釈するとき、元のファイル値とメモリーの基底アドレスに基づいて実際のアドレスを計算します。整合性のため、ファイルには動的構造体内のアドレスを補正するための再配置エントリは存在しません。

表 7-41 は、実行可能オブジェクトファイルと共有オブジェクトファイルのタグ要求についてまとめています。タグに「必須」という印が付いている場合、動的リンク配列にはその型のエントリが存在しなければなりません。また、「任意」は、タグのエントリが表われてもよいですが必須ではないことを意味します

DT_NULL

DT_NULL タグが付けられたエントリは、_DYNAMIC 配列の終わりを示します。

DT_NEEDED

この要素は、空文字 で終わっている文字列の文字列テーブルオフセットを保持し、必要な依存性の名前を与えます。オフセットは、DT_STRTAB エントリに記録されるテーブルへのインデックスです。これらの名前については、「共有オブジェクトの依存性」を参照してください。動的配列には、この型の複数のエントリが存在できます。これらのエントリの相対順序は意味がありますが、他の型のエントリに対するこれらのエントリの相対順序には意味がありません。

DT_PLTRELSZ

この要素は、手続きリンクテーブルに関連付けられている再配置エントリの合計サイズ (単位: バイト) を保持します。DT_JMPREL 型のエントリが存在する場合、DT_PLTRELSZ 型のエントリも必要です。

DT_PLTGOT

この要素は、手続きリンクテーブルまたは大域オフセットテーブルに関連付けられているアドレスを保持します。

DT_HASH

この要素は、シンボルハッシュテーブル (「ハッシュテーブル」に記述されている) を指し示します。ハッシュテーブルは、DT_SYMTAB 要素で示されるシンボルテーブルを参照します。

DT_STRTAB

この要素は、文字列テーブル (この章の前半部分で記述している) のアドレスを保持します。文字列テーブルには、実行時リンカーが必要とするシンボル名、依存性名、および他の文字列が存在します。

DT_SYMTAB

この要素は、再配置テーブル (この章の前半部分で記述している) のアドレスを保持します。32 ビットクラスのファイルに対しては Elf32_Sym エントリ、64 ビットクラスのファイルに対しては ELF 64_sym エントリが存在します。

DT_RELA

この要素は、再配置テーブル (この章の前半部分で記述している) のアドレスを保持します。再配置テーブルのエントリ (32 ビットファイルクラス用の Elf32_Rela、64 ビットファイルクラス用の ELF 64_Rela など) には、明示的加数が存在します。

オブジェクトファイルには、複数の再配置セクションが存在できます。リンカーは、実行可能オブジェクトファイルまたは共有オブジェクトファイルの再配置テーブルを作成するとき、これらのセクションを連結して単一のテーブルを作成します。これらの各セクションはオブジェクトファイル内で個々に独立したままですが、実行時リンカーは単一のテーブルとして扱います。実行時リンカーは、実行可能ファイルのプロセスイメージを作成したり、またはプロセスイメージに共有オブジェクトを付加したりするとき、再配置テーブルを読み取り、関連付けられている動作を実行します。

この要素が存在する場合、動的構造体には DT_RELASZ 要素と DT_RELAENT 要素も存在しなければなりません。再配置がファイルに対して「必須」の場合、DT_RELA または DT_REL が使用可能です (これらは両方とも使用可能ですが、必要ではありません)。

DT_RELASZ

この要素は、DT_RELA 再配置テーブルの合計サイズ (単位: バイト) を保持します。

DT_RELAENT

この要素は、DT_RELA 再配置エントリのサイズ (単位: バイト) を保持します。

DT_STRSZ

この要素は、文字列テーブルのサイズ (単位: バイト) を保持します。

DT_SYMENT

この要素は、シンボルテーブルエントリのサイズ (単位: バイト) を保持します。

DT_SYMINFO

この要素は、SHT_SUNW_syminfo セクションのアドレスを保持します。

DT_SYMINENT

この要素は、SHT_SUNW_syminfo テーブルエントリのサイズ (単位: バイト) を保持します。

DT_SYMINSZ

この要素は、SHT_SUNW_syminfo セクションのサイズ (単位: バイト) を保持します。

DT_INIT

この要素は、初期化関数のアドレスを保持します (初期化関数については、「初期化および終了関数」で記述しています)。

DT_FINI

この要素は、終了関数のアドレスを保持します (終了関数については、「初期化および終了関数」に記述されています)。

DT_SONAME

この要素は、空文字で終わっている文字列の文字列テーブルオフセットを保持し、共有オブジェクトの名前を与えます。このオフセットは、DT_STRTAB エントリに記録されているテーブルへのインデックスです。これらの名前については、「共有オブジェクトの依存性」を参照してください。

DT_RPATH

この要素は、ライブラリ検索パス (空文字で終わっている文字列) 文字列テーブルオフセットを保持します (ライブラリ検索パスについては、「依存関係を持つ共有オブジェクト」で記述しています)。このオフセットは、DT_STRTAB エントリに記録されているテーブルへのインデックスです。

DT_SYMBOLIC

この要素は、オブジェクトが、リンク編集時に適用されたシンボル結合を含むかどうかを示します。「-Bsymbolic の使用」も参照してください。

DT_REL

この要素は DT_RELA に似ていますが、テーブルに暗黙の加数 (32 ビットファイルクラス用の Elf32_Rel など) が存在する点が異なります。この要素が存在する場合、動的構造体には DT_RELSZ 要素と DT_RELENT 要素も存在しなければなりません。

DT_RELSZ

この要素は、DT_REL 再配置テーブルの合計サイズ (単位: バイト) を保持します。

DT_RELENT

この要素は、DT_REL 再配置エントリのサイズ (単位: バイト) を保持します。

DT_PLTREL

この要素は、手続きリンクテーブルが参照する再配置エントリの型を指定します。d_val 要素は、必要に応じて DT_REL または DT_RELA を保持します。1 つの手続きリンクテーブルでは、すべての再配置は、同じ再配置を使用しなければなりません。

DT_DEBUG

この要素は、デバッグ時に使用されます。

DT_TEXTREL

この構成要素が存在しない場合、再配置エントリが書き込み不能セグメント (プログラムヘッダーテーブルのセグメント許可で指定されます) に対する変更を発生させてはならないことを意味します。この構成要素が存在する場合、1 つまたは複数の再配置エントリが書き込み不能セグメントに対する変更を要求するかもしれません。また、実行時リンカーはしかるべく対応します。

DT_FLAGS_1

このエントリが存在する場合、このエントリの d_val 要素は、さまざまな状態フラグを保持します。表 7-42 を参照してください。

DT_POSFLAG_1

このエントリが存在する場合、このエントリの d_val 要素は、さまざまな状態フラグを保持します。これらのフラグは、.dynamic セクション内の直後の DT_* エントリに適用されます。

DT_JMPREL

このエントリが存在する場合、このエントリの d_ptr 要素は、手続きリンクテーブルにのみ関連付けられている再配置エントリのアドレスを保持します。これらの再配置エントリを分離しておくと、遅延結合が有効の場合、実行時リンカーはプロセス初期化時にこれらの再配置エントリを無視します。このエントリが存在する場合、DT_PLTRELSZ 型と DT_PLTREL 型の関連エントリも存在しなければなりません。

DT_VERDEF

この要素は、バージョン定義テーブル (この章の前半部分で記述している) のアドレスを保持します。32 ビットクラスのファイルに対しては Elf32_Verdef エントリ、64 ビットクラスのファイルに対しては Elf64_Verdef エントリが存在します。詳細は、「バージョン定義セクション」を参照してください。これらのエントリ内の要素には、DT_STRTAB エントリに記録されているテーブルへのインデックスが存在します。

DT_VERDEFNUM

この要素は、バージョン定義テーブルのエントリ数を指定します。

DT_VERNEED

この要素は、バージョン依存性テーブル (この章の前半部分で記述している) のアドレスを保持します。32 ビットクラスのファイルに対しては Elf32_Verneed エントリ、64 ビットクラスのファイルに対しては Elf64_Verneed エントリが存在します。詳細は、「バージョン依存セクション」を参照してください。これらのエントリ内の要素には、DT_STRTAB エントリに記録されているテーブルへのインデックスが存在します。

DT_VERNEEDNUM

この要素は、バージョン依存性テーブルのエントリ数を指定します。

DT_RELACOUNT

すべての Elf32_Rela あるいは Elf64_Rela R_*_RELATIVE 再配置は単一のブロックに入っており、このエントリはそのブロックのエントリ数を指定します。これにより、実行時リンカー は RELATIVE 再配置の処理を合理化できます。

DT_RELCOUNT

すべての Elf32_Rel R_*_RELATIVE 再配置は単一のブロックに入っており、このエントリはそのブロックのエントリ数を指定します。これにより、実行時リンカーは RELATIVE 再配置の処理を合理化できます。

DT_AUXILIARY

この要素は、空文字で終わっている文字列 (オブジェクトに命名している) の文字列テーブルオフセットを保持します。このオフセットは、DT_STRTAB エントリに記録されているテーブルへのインデックスです。補助オブジェクト内のシンボルは、このオブジェクト内のシンボルに優先して使用されます。

DT_FILTER

この要素は、オブジェクトを示す文字列 (空文字で終わっている文字列) の文字列テーブルオフセットを保持します。このオフセットは、DT_STRTAB エントリに記録されているテーブルへのインデックスです。このオブジェクトのシンボルテーブルは、命名されたオブジェクトのシンボルテーブルのフィルタとして使用されます。

DT_CHECKSUM

この要素は、オブジェクトの選択されたセクションの簡単なチェックサムを保持します。gelf_checksum(3ELF) を参照してください。

DT_MOVEENT

この要素は、SHT_SUNW_move で定義されるセクションの合計サイズを保持します。「移動セクション」を参照してください。

DT_MOVESZ

この要素は、DT_MOVETAB 移動エントリのサイズ (単位: バイト) を保持します。

DT_MOVETAB

この要素は、移動テーブル (この章の前半部分で記述している) のアドレスを保持します。移動テーブルのエントリには、32 ビットクラスのファイルに対する Elf32_Move エントリ、64 ビットクラスのファイルに対する Elf64_Move エントリが存在します。

DT_CONFIG

この要素は、構成ファイルを定義する文字列 (ヌル文字で終端している文字列) の文字列テーブルオフセットを保持します。このオフセットは DT_STRTAB エントリに記録されているテーブルへのインデックスです。構成ファイルは、検索パス、ディレクトリキャッシュ、または代替オブジェクトを提供し、通常 DT_CONFIG エントリを指定するアプリケーションに固有です。crle(1) およびリンカーの -c オプションを参照してください。

DT_DEPAUDIT

この要素は、1 つあるいは複数の監査ライブラリを定義する文字列 (ヌル文字で終端している文字列) の文字列テーブルオフセットを保持します。このオフセットは DT_STRTAB エントリに記録されているテーブルへのインデックスです。監査ライブラリは実行時に、このオブジェクトを監査するために使用されます。リンカーの-P オプションを参照してください。

DT_AUDIT

この要素は、1 つあるいは複数の監査ライブラリを定義する文字列 (ヌル文字で終端している文字列) の文字列テーブルオフセットを保持します。このオフセットは DT_STRTAB エントリに記録されているテーブルへのインデックスです。監査ライブラリは実行時に、このオブジェクトを監査するために使用されます。リンカーの -p オプションを参照してください。

DT_FEATURE_1

このエントリが存在する場合、このエントリの d_val メンバーは実行時機能要求を定義する DTF_1_ フラグを保持します。関数 _check_rtld_feature() は、通常、コンパイラ供給の起動コードから実行時に呼び出され、要求された機能が存在することを確認します。「機能チェッカ」を参照してください。

DT_VALRNGLO - DT_VALRNGHI

この範囲の値は、動的構造体内の d_un.d_val フィールドで使用されます。

DT_ADDRRNGLO - DT_ADDRRNGHI

この範囲の値は、動的構造体内の d_un.d_ptr フィールドで使用されます。ELF オブジェクトが作成後に調整された場合、これらのエントリも更新する必要があります。

DT_SPARC_REGISTER

この要素には、STT_SPARC_REGISTER シンボルのインデックスが存在します。シンボルテーブルの各 STT_SPARC_REGISTER シンボルテーブルエントリには、これらのエントリの 1 つが存在します。

DT_LOPROC - DT_HIPROC

この範囲の値は、プロセッサに固有の使用方法に対して予約されます。

以下の動的状態フラグが現在、使用可能です。

DF_1_NOW

オブジェクトが読み込まれると、すべての再配置処理が行われます。「再配置が実行されるとき」を参照してください。この状態フラグは、リンカーの -z now オプションを使うことによって有効になります。

DF_1_GROUP

オブジェクトがグループの構成要素であることを示します。「シンボル検索」を参照してください。この状態フラグは、リンカーの -B group オプションを使うことによって有効になります。

DF_1_NODELETE

オブジェクトがプロセスから削除できないことを示します。したがってオブジェクトは、dlopen(3DL) で直接または依存性としてプロセスに読み込まれた場合、dlclose(3DL) で読み込み解除できません。この状態フラグは、リンカーの -z nodelete オプションを使うことによってオブジェクトに有効になります。

DF_1_LOADFLTR

この状態フラグは、「フィルタ」に対してのみ意味があります (「フィルタとしての共有オブジェクト」を参照してください)。フィルタが読み込まれると、関連付けられているすべてのフィルティーが直ちに処理されます (「フィルタ対象の処理」を参照してください)。この状態フラグは、リンカーの -z loadfltr オプションを使うことによってオブジェクトに有効になります。

DF_1_INITFIRST

オブジェクトが読み込まれると、このオブジェクトと共に読み込まれた他のオブジェクトより先に、このオブジェクトの初期化セクションが実行されます。「デバッギングエイド」を参照してください。この特殊な状態フラグは、libthread.so.1 で使用されることを意図しています。この状態フラグは、リンカーの -z initfirst オプションを使うことによって有効になります。

DF_1_NOOPEN

dlopen(3DL) を使ってオブジェクトを実行中プロセスに追加できないことを示します。この状態フラグは、リンカーの -z nodlopen オプションを使うことによってオブジェクトに有効になります。

DF_1_DIRECT

オブジェクトには、直接結合情報が存在します。

DF_1_INTERPOSE

オブジェクトシンボルテーブルは、起動性実行可能プログラム以外のすべてのシンボルの前に挿入されます。この状態フラグは、リンカーの -z interpose オプションを使うことによって有効になります。

DF_1_NODEFLIB

このオブジェクトの依存関係を検索する場合、デフォルトのライブラリ検索パスを無視します。「実行時リンカーが検索するディレクトリ」を参照してください。この状態は、リンカーの -z nodefaultlib オプションを使用してオブジェクトに記録されます。

DF_1_NODUMP

このオブジェクトは dldump(3DL) によってダンプできません。このオプションの候補には、libdl.so.1 などのフィルタが含まれます。libdl.so.1 は、crle(1) を使用して構成ファイルを生成する際に含めることができます。この状態は、リンカーの -z nodump オプションを使用してオブジェクトに記録されます。

DF_1_CONFALT

crle(1) によって生成された代替構成オブジェクトであることを示します。この状態により実行時リンカーがトリガーされ、構成ファイル $ORIGIN/ld.config.app-name が検索されます。

DF_P1_LAZYLOAD

後続の DT_* エントリは、読み込まれるオブジェクトを示します。このオブジェクトのローディングは、Syminfo テーブルエントリで示されるシンボル結合がこのオブジェクトを明確に参照するまで遅延されます。

DF_P1_GROUPPERM

後続の DT_* エントリは、読み込まれるオブジェクトを示します。このオブジェクト内のシンボルは、一般的なシンボル解決に対しては使用できません。このオブジェクト内のシンボルは、このオブジェクトを読み込ませたオブジェクト (1 つまたは複数) に対してのみ使用可能です。

以下の動的機能フラグが現在、使用可能です。

動的配列の終わりの DT_NULL 要素と、DT_NEEDED 要素と DT_POSFLAG_1 要素の相対順序を除き、エントリは任意の順序で現れることができます。テーブルに示されていないタグ値は、保留されます。

共有オブジェクトの依存性

実行時リンカーがオブジェクトファイルのメモリーセグメントを作成するとき、依存性 (動的構造体の DT_NEEDED エントリに記録される) は、プログラムのサービスを提供するためにどの共有オブジェクトが必要であるかを示します。参照された共有オブジェクトとそれが依存するものを繰り返し結合することによって、実行時リンカーは完全なプロセスイメージを作成します。

実行時リンカーは、記号参照を解決するとき、横形探索を使用してシンボルテーブルを調べます。つまり、実行時リンカーはまず実行可能プログラム自身のシンボルテーブルを参照し、次に DT_NEEDED エントリのシンボルテーブルを (順番に) 参照し、次に第 2 レベルの DT_NEEDED エントリといった具合に参照します。

共有オブジェクトが依存性リストにおいて複数回参照されるときでも、実行時リンカーはこの共有オブジェクトをプロセスに 1 回だけ結合します。

依存リストに示されている名前は、オブジェクトファイルの作成に使用される共有オブジェクトの DT_SONAME 文字列またはパス名です。

大域オフセットテーブル (プロセッサ固有)

一般に位置に依存しないコードには絶対仮想アドレスは存在できません。大域オフセットテーブルには内部で使用するデータの絶対アドレスが存在しており、したがって、位置からの独立性とプログラムのテキストの共有性を低下させることなくアドレスが使用可能になります。プログラムは、位置に依存しないアドレス指定を使用して大域オフセットテーブルを参照し、絶対値を抜き出すことで位置に依存しない参照を、絶対位置に向け直します。

最初は、大域オフセットテーブルには再配置エントリで要求される情報が存在します (詳細は、「再配置」を参照してください)。システムが読み込み可能オブジェクトファイルのメモリーセグメントを作成した後、実行時リンカーが再配置エントリを処理します。これらの再配置エントリのいくつかは、R_SPARC_GLOB_DAT 型 (SPARC の場合) または R_386_GLOB_DAT 型 (IA の場合) であり、大域オフセットテーブルを参照します。

実行時リンカーは、関連付けられているシンボル値を判定し、絶対アドレスを計算し、適切なメモリーテーブルエントリにを正しい値を設定します。リンカーがオブジェクトファイルを作成するとき、絶対アドレスは認識されていませんが、実行時リンカーはすべてのメモリーセグメントのアドレスを認識しており、したがって、これらのメモリーセグメントに存在するシンボルの絶対アドレスを計算できます。

プログラムがシンボルの絶対アドレスへの直接アクセスを必要とする場合、このシンボルには大域オフセットテーブルエントリが存在します。実行可能ファイルと共有オブジェクトには別個の大域オフセットテーブルが存在するので、シンボルのアドレスはいくつかのテーブルに現れることがあります。実行時リンカーは、プロセスイメージのコードに制御を与える前に大域オフセットテーブルのすべての再配置を処理します。したがって、実行時に絶対アドレスが使用可能になります。

テーブルのエントリ 0 は、_DYNAMIC シンボルで参照される動的構造体のアドレスを保持するために予約されています。したがって、実行時リンカーなどのプログラムは、再配置エントリを処理していなくても自身の動的構造体を見つけることができます。このことは、実行時リンカーにとって特に重要です。なぜなら、実行時リンカーは他のプログラムに頼ることなく自身を初期化してメモリーイメージを再配置しなければならないからです。

システムは、異なるのプログラムの同じ共有オブジェクトに対して、異なるメモリーセグメントアドレスを与えることがあります。さらに、システムはプログラムを実行するごとに異なるライブラリアドレスを与えることさえあります。しかし、プロセスイメージがいったん作成されると、メモリーセグメントのアドレスは変更されません。プロセスが存在する限り、そのプロセスのメモリーセグメントは固定仮想されたアドレスに存在します。

大域オフセットテーブルの形式と解釈は、プロセッサに固有です。SPARC プロセッサと IA プロセッサの場合、_GLOBAL_OFFSET_TABLE_ シンボルは、テーブルをアクセスするために使用できます。64 ビットコードの場合、シンボルタイプは Elf64_Addr の配列です。

extern Elf32_Addr _GLOBAL_OFFSET_TABLE_[]; 

シンボル _GLOBAL_OFFSET_TABLE_ は、.got セクションの中央に存在でき、その場合は、負の添字と負でない添字の両方がアドレスの配列になることができます。

手続きリンクテーブル (プロセッサに固有)

大域オフセットテーブルは位置に依存しないアドレスの計算を絶対位置に変換するので、手続きリンクテーブルは位置に依存しない関数呼び出しを絶対位置に変換します。リンカーは、ある 1 つの実行可能オブジェクトまたは共有オブジェクトから別の実行可能オブジェクトまたは共有オブジェクトへの実行転送 (関数呼び出しなど) を解決できません。したがって、リンカーはプログラム転送制御を手続きリンクテーブルのエントリに与えます。

SPARC: 手続きリンクテーブル

SPARC アーキテクチャの場合、手続きリンクテーブルは私用データに存在します。実行時リンカーは、宛先の絶対アドレスを判定し、これらの絶対アドレスに従って手続きリンクテーブルのメモリーイメージに変更を加えます。このようにして実行時リンカーは、位置からの独立性とプログラムのテキストの共有性を低下させることなくエントリを向け直します。実行可能ファイルと共有オブジェクトファイルには、別個の手続きリンクテーブルが存在します。

最初の 4 つの手続きリンクテーブルエントリは、予約されます。 テーブルの各エントリは 3 ワード (12 バイト) を占めており、最後のテーブルエントリの後には nop 命令が続きます。64 ビット SPARC オブジェクトの場合、各エントリは 8 つの命令 (32 バイト) を占めており、32 バイト境界で整列されなければなりません (テーブル全体は 256 バイト境界で整列されなければなりません)。

再配置テーブルは、手続きリンクテーブルに関連付けられています。_DYNAMIC 配列の DT_JMP_REL エントリは、最初の再配置エントリの位置を与えます。再配置テーブルには、各手続きリンクテーブルエントリに対して 1 つのエントリが同じ順番で存在します。最初の 4 つのエントリを除き、再配置タイプは R_SPARC_JMP_SLOT であり、再配置オフセットは関連付けられている手続きリンクテーブルエントリの先頭バイトのアドレスを指定し、シンボルテーブルインデックスは該当するシンボルを参照します。

手続きリンクテーブルの説明のため、表 7-45 は 4 つのエントリを示しています。最初の 2 つのエントリは予約されている最初の 4 つのエントリの内の 2 つであり、3 番目のエントリは name1 に対する呼び出しであり、4 番目のエントリは name2 に対する呼び出しです。この例では、name2 のエントリがテーブルの最後のエントリであることを前提としており、後に続く nop 命令が示されています。左欄は、動的リンクが行われる前のオブジェクトファイルの命令を示しています。右欄は、実行時リンカーが手続きリンクテーブルエントリを修正することにしてとり得る方法を示しています。

.PLT0:
     unimp
	    unimp
	    unimp
.PLT1:
	    unimp
	    unimp
	    unimp
	    ...

.PLT0:
	    save    %sp,-64,%sp
	    call    runtime-linker
	    nop
.PLT1:
	    .word   identification
	    unimp
	    unimp
	    ...

	... 
.PLT101:
	    sethi    (.-.PLT0),%g1
	    ba,a     .PLT0
	    nop
.PLT102:
	    sethi    (.-.PLT0),%g1
	    ba,a     .PLT0
     nop

	...
.PLT101:
	    sethi   (.-.PLT0),%g1
	    sethi   %hi(name1),%g1
	    jmp1    %g1+%lo(name1),%g0
.PLT102:
	    sethi   (.-.PLT0),%g1
	    sethi   %hi(name2),%g1
	    jmp1    %g1+%lo(name2),%g0

     nop

	    nop

実行時リンカーとプログラムは、以下の手順に従って手続きリンクテーブル内のシンボル参照を協調して解決します。ただし、以下に記述されている手順は、単に説明用のためのものです。実行時リンカーの正確な実行時動作については、記述されていません。

1. 実行時リンカーは、プログラムのメモリーイメージを最初に作成するとき、手続きリンクテーブルの初期エントリに、実行時リンカー自身のルーチンの 1 つに制御を渡すように変更を加える。実行時リンカーはまた、識別情報 (identification) を 2 番目のエントリに格納する。リンカー自身のルーチンが制御を受け取った時、このワードを調べることで、このルーチンを呼び出したオブジェクトを見つけることができる

2. 他のすべての手続きリンクテーブルエントリは、最初は先頭エントリに渡される。これで、実行時リンカーは各テーブルエントリの最初の実行時に制御を取得する。たとえば、プログラムが name1 を呼び出すと、制御が .PLT101 に渡される

3. sethi 命令は、現在の手続きリンクテーブルエントリと最初の手続きリンクテーブルエントリの距離を計算する。つまり、.PLT101 と .PLT0 の距離を計算する。この値は、%g1 レジスタの最上位 22 ビットを占める。この例では、実行時リンカーが制御を受け取ると、%g1 には 0x12f000 が格納される

4. 次に、ba,a 命令が .PLT0 にジャンプして、スタックフレームを作成し、実行時リンカーを呼び出す

5. 実行時リンカーは、識別情報の値を使うことによってオブジェクトのデータ構造体 (再配置テーブルを含む) を取得する

6. 実行時リンカーは、%g1 値をシフトし手続きリンクテーブルエントリのサイズで除算することで、name1 の再配置エントリのインデックスを計算する。再配置エントリ 101 には R_SPARC_JMP_SLOT が存在し、オフセットは .PLT101 のアドレスを指定し、シンボルテーブルインデックスは name1 を参照。したがって、実行時リンカーはシンボルの実際の値を取得し、スタックを戻し、手続きリンクテーブルエントリに変更を加え、本来の宛先に制御を渡す

実行時リンカーは、メモリーセグメント欄に示された命令シーケンスを作成しなければならないということはないのですが、作成することがあります。もし作成した場合は、いくつかの点についてより詳しい説明が必要です。

• コードを再入可能にするためには、手続きリンクテーブルの命令は、特定の順番で変更が加えられる。実行時リンカーが関数の手続きリンクテーブルエントリを修正中に信号が到達した場合、信号処理コードは、予想可能であり (かつ正しい) 結果を与える元の関数を呼び出すことができなければならない

• 実行時リンカーは、2 つのワードに変更を加えてエントリを変換する。実行時リンカーは、各ワードを自動的に更新する。再入可能性は、まず nop を jmp1 命令で上書きし、次に ba,a を sethi 命令で上書きすることで実現される。再入可能関数呼び出しがワードの 2 つの更新間に発生した場合、jmp1 は ba,a 命令の遅延スロットに存在し、遅延命令を取り消す。したがって、実行時リンカーは再び制御を取得す。実行時リンカーに対する両方の呼び出しで、同じ手続きリンクテーブルエントリに変更が加えられますが、これらの変更は互いに干渉しない

• 手続きリンクテーブルエントリの最初の sethi 命令は、1 つ前のエントリの jmp1 命令の遅延スロットを埋める。sethi は %g1 レジスタの値を変更するが、以前の内容を捨てても問題はない

• 変換後、最後の手続きリンクテーブルエントリ (前述した .PLT102) は、jmp1 に対して遅延命令を必要とする。要求されている後続の nop は、この遅延スロットを埋める

LD_BIND_NOW 環境変数は、動的リンクの動作を変更します。この環境変数の値が空文字列以外の場合、実行時リンカーは、プログラムに制御を渡す前に R_SPARC_JMP_SLOT 再配置エントリ (手続きリンクテーブルエントリ) を処理します。LD_BIND_NOW が空文字列の場合、実行時リンカーは、各テーブルエントリの最初の実行時にリンクテーブルエントリを評価します。

IA: 手続きリンクテーブル

IA アーキテクチャの場合、手続きリンクテーブルは共有テキストに存在しますが、私用大域オフセットテーブルのアドレスを使用します。実行時リンカーは、宛先の絶対アドレスを判定し、これらの絶対アドレスに従って大域オフセットテーブルのメモリーイメージに変更を加えます。このようにして実行時リンカーは、位置からの独立性とプログラムのテキストの共有性を低下させることなくエントリを向け直します。実行可能ファイルと共有オブジェクトファイルには、別個の手続きリンクテーブルが存在します。

.PLT0:  pushl   got_plus_4
        jmp     *got_plus_8
        nop;    nop
        nop;    nop
.PLT1:  jmp     *name1_in_GOT
        pushl   $offset
        jmp     .PLT0@PC
.PLT2:  jmp     *name2_in_GOT
        pushl   $offset
        jmp     .PLT0@PC
        ...

.PLT0:  pushl   4(%ebx)
        jmp     *8(%ebx)
        nop;    nop
        nop;    nop
.PLT1:  jmp     *name1@GOT(%ebx)
        pushl   $offset
        jmp     .PLT0@PC
.PLT2:  jmp     *name2@GOT(%ebx)
        pushl   $offset
        jmp     .PLT0@PC
        ...

実行時リンカーとプログラムは、以下の手順に従って手続きリンクテーブル内と大域オフセットテーブル内のシンボル参照を協調して解決します。

1. 実行時リンカーは、プログラムのメモリーイメージを最初に作成するとき、大域オフセットテーブルの 2 番目と 3 番目のエントリに特殊な値を設定する。これらの値については、以下の手順で説明する

2. 手続きリンクテーブルが位置に依存していない場合、大域オフセットテーブルのアドレスは、%ebx に存在しなければならない。プロセスイメージにおける各共有オブジェクトファイルには自身の手続きリンクテーブルが存在しており、制御は同じオブジェクトファイル内からのみ手続きリンクテーブルエントリに渡される。したがって、呼び出し側関数は、手続きリンクテーブルエントリを呼び出す前に、大域オフセットテーブル基底レジスタをセットしなければならない

3. たとえば、プログラムが name1 を呼び出すと、制御が .PLT1 に渡される

4. 最初の命令は、name1 の大域オフセットテーブルエントリのアドレスにジャンプする。大域オフセットテーブルは最初は、後続の pushl 命令のアドレスを保持します (name1 の実アドレスは保持しない)

5. したがって、プログラムは再配置オフセット (offset) をスタックにプッシュする。再配置オフセットは、再配置テーブルへの 32 ビットの負ではないバイトオフセット。指定された再配置エントリには R_386_JMP_SLOT が存在しており、オフセットは、前の jmp 命令で使用された大域オフセットテーブルエントリを指定する。再配置エントリにはシンボルテーブルインデックスも存在しており、実行時リンカーはこれを使って参照されたシンボル name1 を取得する

6. プログラムは、再配置オフセットをプッシュした後、.PLT0 (手続きリンクテーブルの先頭エントリ) にジャンプする。pushl 命令は、2 番目の大域オフセットテーブルエントリ (got_plus_4 または 4(%ebx)) の値をスタックにプッシュして、実行時リンカーに 1 ワードの識別情報を与える。プログラムは次に、3 番目の大域オフセットテーブルエントリ (got_plus_8 または 8(%ebx)) のアドレスにジャンプして、実行時リンカーにジャンプする

7. 実行時リンカーはスタックを戻し、指定された再配置エントリを調べ、シンボルの値を取得し、name1 の実際のアドレスを大域オフセットテーブルエントリに格納し、そして宛先にジャンプする

8. その後の手続きリンクテーブルエントリに対する実行は、name1 に直接渡される (実行時リンカーの再呼び出しは行われない)。これは、.PLT1 における jmp 命令は、pushl 命令にはジャンプする代わりに、name1 にジャンプするから

LD_BIND_NOW 環境変数は、動的リンク動作を変更します。この環境変数の値が空文字列以外の場合、実行時リンカーは、プログラムに制御を渡す前に R_386_JMP_SLOT 再配置エントリ (手続きリンクテーブルエントリ) を処理します。LD_BIND_NOW が空文字列の場合、実行時リンカーは、各テーブルエントリの最初の実行時にリンクテーブルエントリを評価します。