リンカーとライブラリ

内部対応付け構造

ELF ベースのリンカーのもっとも重要なデータ構造の 1 つとして対応付け構造があります。デフォルト mapfile に対応するデフォルト対応付け構造が、リンカーにより使用されます。ユーザーの mapfile はすべて、デフォルト対応付け構造内に特定の値を追加または上書きします。

一般的な (ただし多少簡略化した) 対応付け構造を図 9–1 に示します。「エントランス基準」ボックスは、デフォルトの対応付け指令内の情報に対応しています。「セグメント属性記述子」ボックスは、デフォルトのセグメント宣言内の情報に対応しています。「出力記述子」ボックスは、各セグメントの下に来るセクションの詳細な属性を示します。セクション自体は丸で囲んであります。

図 9–1 簡単な対応付け構造

リンカーはセクションをセグメントに対応付ける際に、次の手順で行います。

セクションを読み取る際に、リンカーは合致するものを見つけるために、一連のエントランス基準を検査します。指定したすべての条件が合致する必要があります。

図 9–1 では、text セグメントに入るセクションの場合、section_type は $PROGBITS、section_flags は ?A!W でなければなりません。エントランス基準では名前は指定されていないので、名前 .text は必要ありません。エントランス基準では実行ビットは何も指定されていないので、セクションは section_flags 値の X または !X のどちらかでもかまいません。

エントランス基準に合致するものが見つからない場合、セクションはその他すべてのセグメントの後の出力ファイルの最後に置かれます。この情報に関するプログラムヘッダーエントリは作成されません。
セクションがセグメントの中に入る際に、リンカーは次のようにそのセグメントの既存の一連の出力セクション記述子を検査します。

セクションの属性値が既存の出力セクション記述子の属性値とまったく合致する場合、セクションは出力セクション記述子に対応するセクションの列挙の最後に置かれます。

たとえば、section_name が .data1、section_type が $PROGBITS、section_flags が ?AWX のセクションは、図 9–1 の 2 番目のエントランス基準ボックスにあてはまり、data セグメントに置かれます。セクションは 2 番目の出力セクション記述子ボックスにちょうど一致し (.data1、$PROGBITS、?AWX)、このボックスに対応する一連のセクションの最後に追加されます。fido.o、rover.o、および sam.o の .data1 セクションは、このことを示しています。

一致する出力セクション記述子が見つからず、同じ section_type の出力セクション記述子がほかに存在する場合、セクションとして同じ属性値で新しい出力セクション記述子が作られ、そのセクションは新しい出力セクション記述子と対応づけられます。出力セクション記述子およびセクションは、同じセクションタイプの最後の出力セクション記述子の後に置かれます。Figure 9–1 の図 9–1 セクションはこの方法で配置されました。

指定されたセクションタイプの出力セクション記述子がほかに存在しない場合、新しい出力セクション記述子が作られ、セクションはそのセクション内に置かれます。

注 –
入力セクションが、SHT_LOUSER と SHT_HIUSER の間にユーザー定義のセクションタイプ値を保持する場合、このセクションタイプ値は $PROGBITS セクションとして処理されます。mapfile でこの section_type 値に名前を付ける方法はありませんが、これらのセクションは、エントランス基準でその他の属性値指定 (section_flags、section_name) を使って付け直すことができます。
すべてのコマンド行で指定されたオブジェクトファイルとライブラリが読み取られた後、セグメントがセクションをまったく含まない場合、そのセグメントに対してはプログラムヘッダーエントリは作られません。

注 –

$SYMTAB、$STRTAB、$REL、および $RELA 型の入力セクションは、リンカーにより内部で使用されます。これらのセクションタイプを参照する指令は、リンカーで作った出力セクションしかセグメントに対応付けできません。