第 2 章 リンカー

概要

リンク編集プロセスにより、1 つまたは複数の入力ファイルから出力ファイルが作成されます。出力ファイルの作成は、入力ファイルによって提供される入力セクションとともにリンカーに提供されたオプションによって指示されます。とともにリンカーに提供されたオプションによって指示されます。

ファイルはすべて、「実行可能なリンク書式 」 (ELF) で表示されます。ELF 書式の詳細については、第 7 章「オブジェクトファイル」を参照してください。ただし、ここでの概要説明では、まず、2 つの ELF 構造、「セクション」と「セグメント」について紹介する必要があります。

セクションとは、ELF ファイル内で処理できる、最も小さな、分割できない単位のことです。セグメントとは、セクションの集合で、exec(2) または実行時リンカー ld.so.1(1) によってメモリーイメージに対応付けできる最小の一単位を表します。

ELF セクションには多くのタイプがありますが、これらはすべて、リンク編集を基準にして次の 2 つのカテゴリに分類されます。

• プログラム命令 .text およびその関連データ .data や .bss など、その解釈がアプリケーションそのものに対してだけ意味のある「プログラムデータ」を含むセクション

• 「リンク編集情報」.symtab と .strtab から検出されるシンボルテーブル情報など、および .rela.text などの再配置情報を含むセクション

基本的には、リンカーにより、「プログラムデータセクション」が連結されて出力ファイルになります。「リンク編集情報セクション」は、リンカーによって解釈されて、別のセクションに修正されるか、またはこのあと処理される出力ファイルで使用される新しい出力情報セクションが生成されます。

リンカーの、次のような単純な機能の内訳については、この章で説明します。

• リンカーを通過するすべてのオプションの整合性を検証し、検査する

• 入力再配置可能オブジェクトから、同じ特性 (たとえば、型、属性、名前など) のセクションを結合し、出力ファイル内に新しい出力ファイルを形成する。これらの結合されたセクションは、次に、出力セグメントへと連結できる

• リンカーは、再配置可能オブジェクトと共有オブジェクトの両方からシンボルテーブル情報を読み取り、リファレンスを定義と検証し、統一させる。さらに、通常、出力ファイル内に新しいシンボルテーブルまたはテーブルを作成する

• リンカーは、入力再配置可能オブジェクトから再配置情報を読み取り、他の入力セクションを更新してこの情報を出力ファイルに適用する。さらに、実行時リンカーが使用するために出力再配置セクションも生成される

• リンカーは、作成したすべてのセグメントを記述した「プログラムヘッダー」を生成する

• リンカーは、必要に応じて、共有オブジェクトの依存関係などの情報を実行時リンカーに提供する、動的リンク情報セクションを生成する

「セクション」と関連する「セクション」を連結して「セグメント」にするといった連結プロセスは、リンカー内のデフォルト情報を使用して実行されます。通常、ほとんどのリンク編集の場合、リンカーによって提供されるデフォルトの「セクション」と「セグメント」の処理で十分ですが、これらのデフォルトは、関連する mapfile を指定した -M オプションを使用して操作できます (詳細は、第 8 章「mapfile のオプション」を参照してください)。

リンカーの起動

リンカーは、コマンド行から直接実行できます。また、コンパイラドライバを使用して実行することができます。以下の 2 つの項では、この両方の方法を詳しく説明していますが、コンパイル環境は、通常、複雑で、コンパイラドライバだけが認識する一連の操作の変更が行われる場合もあるため、後者の方法を選択されることをお勧めします。

直接起動

リンカーを直接的に起動させる場合は、出力を構築するために必要なすべてのオブジェクトファイルとライブラリを提供する必要があります。リンカーは、出力の構築に使用するつもりのオブジェクトモジュールまたはライブラリに関して、仮説を立てることをしません。たとえば、次のコマンドを発行するとリンカーは、入力ファイル test.o だけを使用して、a.out という動的実行可能プログラムを構築します。

$ ld test.o

a.out を有用な実行可能プログラムにするためには、これに初期設定および終了処理コードを組み込む必要があります。このコードは、言語またはオペレーティングシステム固有のもので、通常、コンパイラドライバによって提供されるファイルを通じて提供されます。

また、自分専用の初期設定および終了コードも指定できます。このコードは、実行時リンカーにより正確に認識され、使用できるようにするために、適切に暗号化およびラベル付けを行う必要があります。この暗号化とラベル付けも、コンパイラドライバによって提供されたファイルを通じて提供されます。

実際問題として、実行可能プログラムや共有オブジェクトなどの実行時オブジェクトを作成する場合は、コンパイルドライバを使用してリンカーを起動することをお勧めします。リンカーを直接起動をお勧めするのは、-r オプションを使用して、中間再配置可能オブジェクトを作成する場合だけです。

コンパイラドライバを使用する

リンカーを使用する従来の方法は、言語固有のコンパイラドライバを使用する方法です。入力ファイルとともに、cc(1)、f77(1) などのコンパイラドライバを指定します。すると、コンパイルドライバは、追加ファイルとデフォルトライブラリを追加して、リンク編集を完了させます。これらの追加ファイルは、たとえば、以下のようにコンパイルの呼出しを拡張することによって参照できます。

$ cc -# -o prog main.o
/usr/ccs/bin/ld -dy /opt/COMPILER/crti.o /opt/COMPILER/crt1.o ¥ 
/usr/ccs/lib/values-Xt.o -o prog main.o ¥ 
-YP,/opt/COMPILER/lib:/usr/ccs/lib:/usr/lib -Qy -lc ¥ 
/opt/COMPILER/crtn.o

この例は、コンパイラドライバによって組み込まれた実際のファイルの例ですが、リンカー起動の表示に使用されるメカニズムによって異なる場合があります。

リンカーオプションの指定

リンカーに対するオプションは、通常、コンパイラドライバのコマンド行を通じて渡されます。コンパイラとリンカーオプションは、ほとんど重複する部分はありません。重複が発生した場合には、通常、特定のオプションをリンカーに渡すことを許可するコマンド行構文がコンパイラドライバによって提供されますが、この代わりに、LD_OPTIONS 環境変数を設定して、リンカーにオプションを提供することもできます。次に例を示します。

$ LD_OPTIONS="-R /home/me/libs -L /home/me/libs" cc -o prog main.c -lfoo 

ここでは、-R および -L オプションがリンカーによって変換され、コンパイラドライバから受信したコマンド行オプションに付加されます。

リンカーは、オプションリスト全体を構文解析し、無効なオプションまたは関連する引数が無効なオプションを検索します。これらの無効なオプションのどちらかが検出された場合は、該当するエラーメッセージが生成され、さらにこのエラーが深刻なものである場合には、リンカーは自動的に終了します。次に例を示します。

$ ld -X -z sillydefs main.o 
ld:illegal option -- X 
ld: fatal: option -z has illegal argument `sillydefs'

この例では、リンカーの検査により、不当なオプション -X が認識され、-z オプションに不当な引数が検出されました。1 つの引数を必要とするオプションが、誤って 2 回指定されている場合には、リンカーは該当する警告を表示しますが、リンク編集は継続します。次に例を示します。

$ ld -e foo ...... -e bar main.o 
ld: warning: option -e appearsmore than once, first setting taken

また、リンカーはオプションリストを調べて重大な不一致も検出します。次に例を示します。

$ ld -dy -a main.o 
ld: fatal: option -dy and -a are incompatible

すべてのオプションを処理しても、エラー状態が検出されなかった場合は、次にリンカーは、入力ファイルの処理を行います。

通常使用されるリンカーオプションについては、付録 A 「リンカーのクイックリファレンス」 を参照してください。また、全リンカーオプションの詳細については、ld(1) のマニュアルページを参照してください。

入力ファイルの処理

リンカーは、入力ファイルをコマンド行上に表示された順番に読み取ります。各ファイルは、オープンされ、その ELF ファイルタイプを判別するために検査され、どのように処理する必要があるかが決定されます。リンク編集に必要な入力に適用するファイルタイプは、リンク編集の結合モード、「静的」または「動的」のいずれかによって決定されます。

「静的」方法では、リンカーが入力ファイルとして受け入れるのは、再配置可能オプションまたはアーカイブライブラリだけです。「動的」方法では、リンカーは、共有オブジェクトも受け入れます。

再配置可能オブジェクトは、リンク編集プロセスへの最も基本的な入力ファイルタイプを示しています。これらのファイル内の「プログラムデータ」のセクションは、生成される出力ファイルイメージに結合されます。「リンク編集情報」のセクションは、今後の利用のために構成されますが、出力ファイルイメージには組み込まれません。それは、これを配置する場所として、新しいセクションが生成されるからです。シンボルは、その検査および解析を考慮して、最終的に出力イメージ内に 1 つまたは複数のシンボルテーブルを作成できるように、特定の内部シンボルテーブル内に集められます。

入力ファイルは、リンク編集のコマンド行上に直接指定できますが、アーカイブライブラリと共有オブジェクトは、通常、 -l オプションを使用して指定します (このメカニズムについてと、それが 2 種類のリンクモードにどのように関係するかについては、「追加ライブラリとのリンク」を参照してください)。ただし、通常、共有オブジェクトが共有ライブラリと呼ばれ、さらに、これら 2 つのオブジェクトを同じオプションを使用して指定したとしても、共有オブジェクトとアーカイブライブラリは全く別のものです。次の 2 つの項で、この違いについて説明します。

アーカイブ処理

アーカイブは、ar(1) を使用して構築され、通常、アーカイブシンボルテーブルとともに再配置可能オブジェクトの集合で構成されます。このシンボルテーブルにより、これらの定義の提供するオブジェクトとシンボル定義との関係がわかります。デフォルトでは、リンカーを使用すると、アーカイブ構成要素を選択して抽出できます。リンカーがアーカイブを読み取る場合は、結合処理を完了させるために必要なアーカイブから、オブジェクトだけを選択するように作成された内部シンボルテーブル内の情報を使用します。さらに、1 つのアーカイブのすべての構成要素を明示的に抽出することも可能です。

次のような場合に、リンカーはアーカイブから再配置可能オブジェクトを抽出します。

• アーカイブに、現在リンカーの内部シンボルテーブル内に保持されている、シンボルリファレンス (「未定義」シンボルと呼ぶ場合もある) を満たすシンボル定義が入っている場合

• アーカイブに、現在リンカーの内部シンボルテーブル内に保持されている、「未確認」シンボル定義を満たす「データ」シンボル定義が入っている場合。この例としては、FORTRAN COMMON ブロック定義があります。この定義により、同じ DATA シンボルを定義する再配置可能オブジェクトが抽出される

• リンカーの -z allextract が実行された場合。 このオプションにより、選択式のアーカイブ抽出は中止され、処理中のアーカイブからアーカイブ構成要素がすべて抽出される

選択式アーカイブ抽出においては、ウィークシンボルリファレンスでは、-z weakextract オプションが発効されていない限り、アーカイブからの抽出は実行されません。ウィークシンボルについては、「単純な解析」の項で詳しく説明しています。

オプション -z weakextract、-z allextract、および -z defaultextract により、複数のアーカイブ間でアーカイブメカニズムを切り替えることができます。

選択式アーカイブ抽出の場合、リンカーは、リンカーの内部シンボルテーブル内に蓄積されたシンボル情報を満たすために必要な、再配置可能オブジェクトを抽出するアーカイブを通る複数のパスを作成します。リンカーが、再配置可能オブジェクトを抽出せずに、アーカイブを通る完全なパスを作成すると、リンカーは次の入力ファイルの処理に移ります。

アーカイブに遭遇した時点で、必要な再配置可能オブジェクトだけをアーカイブから抽出することによりメカニズムは、入力ファイルリスト内のアーカイブの位置が重要であることを意味しています (詳細については、「コマンド行上のアーカイブの位置」を参照してください)。

リンカーは、アーカイブを通る複数のパスを作成し、シンボルを解析しますが、このメカニズムは、ランダムに構成された再配置可能オブジェクトが組み込まれた大容量のアーカイブの場合には、非常にコストがかかります。このような場合は、lorder(1) や tsort(1) などのツールを使用してアーカイブ内の再配置可能オブジェクトを配列し、リンカーが実行しなければならないパスの数を削減することができます。

共有オブジェクトの処理

共有オブジェクトは、分割不可能な、1 つまたは複数の入力ファイルの以前の編集によって生成された総体単位です。リンカーが共有オブジェクトを処理すると、共有オブジェクトの全内容は、その結果作成された出力ファイルイメージの「論理的」な部分になります。共有オブジェクトは、リンク編集中には物理的にコピーされないため、プロセスが実行されるまで実際には組み込まれません。この論理的な組み込みは、リンク編集プロセスにとって共有オブジェクト内に定義された「すべての」シンボルエントリが利用可能になることを意味しています。

リンカーは、共有オブジェクトの「プログラムデータ」セクションと、ほとんどの「リンク編集情報」セクションを使用しません。そのため、これらのセクションは、共有オブジェクトが結合された実行可能プロセスに生成されるときに、実行時リンカーによって変換されます。ただし、共有オブジェクトのエントリが記憶され、情報は出力ファイルイメージ内に格納されて、このオブジェクトには依存関係があり、実行時に使用可能にする必要があるかどうかが指示されます。

デフォルトでは、リンク編集の一部として指定された共有オブジェクトはすべて、作成されるオブジェクト内に依存関係として記録されます。この記録は、そのオブジェクトが、共有オブジェクトによって提供された実際のリファレンスシンボルを生成するかどうかに関係なく実行されます。実行時リンクのオーバヘッドを最小限にするには、作成されたオブジェクトからシンボルリファレンスを解析するために必要な依存関係だけを、リンク編集の一部として指定します。または、リンカーの -z ignore オプションを使用すると、使用しない共有オブジェクトの依存関係の記録を抑制できます。

共有オブジェクトに、他の共有オブジェクトに対する依存関係がある場合、この依存関係も処理されます。この処理は、すべてのコマンド行入力ファイルの処理が終了したあとで実行されます。このような共有オブジェクトは、シンボル解析処理を完了させるために使用されますが、生成される出力ファイルイメージ内に、その名前は依存関係として記録されません。

リンク編集コマンド行上の共有オブジェクトの位置は、アーカイブ処理のための位置に比べるとそれほど重要ではありませんが、大域な効力を持たせることができます。複数のシンボルに同じ名前を付けると、再配置可能オブジェクトと共有オブジェクト間や複数の共有オブジェクト間に出現させることができます (詳細については、「シンボル解析」を参照してください)。

リンカーによって処理される共有オブジェクトの順序は、出力ファイルイメージ内に格納された従属情報に保持されます。実行時リンカーがこの情報を読み取るため、指定された共有オブジェクトは同じ順序で読み込まれます。そのため、リンカーと実行時リンカーは、多重に定義された一連のシンボルのうち、1 つのシンボルの最初のエントリを選択します。

複数のシンボル定義と、他のシンボル用に 1 つのシンボル定義の挿入を説明した情報は、-m オプションを使用して生成されたロードマップ出力内に報告されます。

追加ライブラリとのリンク

通常、コンパイラドライバによって、適切なライブラリがリンカーに指定されているかどうかが確認されますが、ほとんどの場合、自分独自のライブラリを指定することが必要です。共有オブジェクトとアーカイブは、リンカーに必要な入力ファイルに明示的に命名することによって指定できますが、より一般的で柔軟性のある方法として、リンカーの -l オプションを使用する方法があります。

ライブラリの命名規約

規則により、通常、共有オブジェクトは接頭辞 lib と接尾辞 .so で指定され、アーカイブは接頭辞 lib と接尾辞 .a で指定されます。たとえば、libc.so とは、コンパイル環境で使用可能になった標準 C ライブラリの共有オブジェクトバージョンで、libc.a とは、そのアーカイブバージョンです。

これらの規則は、リンカーの -l オプションによって認識されます。このオプションは、通常、追加ライブラリをリンク編集に供給する場合に使用します。次の例では、リンカーに libfoo.so を検索するように指示し、これが検出できない場合には、libfoo.a を検索してから次の検索ディレクトリに移動するように指示しています。

$ cc -o prog file1.c file2.c -lfoo

命名規約には、共有オブジェクトの「コンパイル」環境での使用に関するものと、共有オブジェクトの実行時環境での使用に関するものがあります。コンパイル環境では、単に .so 接尾辞を使用するのに対し、実行時環境では、通常、追加のバージョン番号を指定した接尾辞を使用します。詳細については、「命名規約」および 「バージョンアップファイル名の管理」を参照してください。

動的モードでリンク編集を行う場合、共有オブジェクトとアーカイブとを組み合わせたものへのリンクを選択できます。静的モードでリンク編集を行う場合、入力を受け入れるのはアーカイブライブラリだけです。

動的モードで、ライブラリの検索を可能にする -l オプションを使用すると、リンカーは、まず、指定されたディレクトリ内で、指定された名前と一致する共有オブジェクトを検索します。一致するものが見つからない場合、リンカーは、次に同じディレクトリ内でアーカイブライブラリを検索します。静的モードで -l オプションを使用する場合は、アーカイブライブラリだけが検索されます。

共有オブジェクトとアーカイブとの混合体へのリンク

動的モードでのライブラリ検索メカニズムでは、指定されたディレクトリを調べて共有オブジェクトを検索し、次にアーカイブライブラリを検索しますが、-B オプションを使用すると必要な検索タイプのより適切なコントロールを保存できます。

コマンド行上に -Bdynamic と -Bstatic オプションを必要な回数だけ指定することによって、ライブラリ検索は共有オブジェクト またはアーカイブをそれぞれ切り替えることができます。たとえば、アーカイブ libfoo.a と共有オブジェクト libbar.so とリンクするには、次のコマンドを発行します。

$ cc -o prog main.o file1.c -Bstatic -lfoo -Bdynamic -lbar 

キーワード -Bstatic と -Bdynamic は、正確には対称ではありません。 -Bstatic を指定すると、リンカーは、次の -Bdynamic の発生まで入力として共有オブジェクトを受け入れませんが、-Bdynamic を指定すると、リンカーは、指定されたディレクトリ内で、まず最初に共有オブジェクトを検索し、次にアーカイブを検索します。

上記の例をより正確に説明すると、リンカーは、最初に libfoo.a を検索し、次に libbar.so を検索します。そしてこれに失敗すると libbar.a を検索します。最後に、libc.so を検索し、これに失敗すると libc.a を検索します。

コマンド行上のアーカイブの位置

コマンド行上のアーカイブの位置は、作成される出力ファイルに影響を及ぼします。リンカーがアーカイブを検索する唯一の目的は、以前に参照したことのある定義されていない仮の外部リファレンスを解析することです。この検索が完了し、必要な再配置可能オブジェクトが抽出されると、このアーカイブは、コマンド行上のアーカイブに続く入力ファイルから入手した新しいシンボルの解析には使用できません。たとえば、次のコマンドでは、file1.c から入手したことのあるシンボルリファレンスを解析するためだけに、libfoo.a を検索するように、リンカーに指示しています。

$ cc -o prog file1.c -Bstatic -lfoo file2.c file3.c -Bdynamic 

libfoo.a は、file2.c または file3.c のシンボルリファレンスを解析するためには、使用できません。

原則として、コマンド行の最後にアーカイブを指定するのが最善の方法です。ただし、最後にアーカイブを配置するには、複数の定義を重複させる必要がある場合は除きます。

リンカーが検索するディレクトリ

ここまでの例はすべて、リンカーが、コマンド行上にリストされたライブラリを検索する場所を認識していることを前提としています。デフォルトでは、32 ビットオブジェクトをリンクする場合、リンカーがライブラリを検索するディレクトリとして認識しているのは、2 つの標準的なディレクトリ /usr/ccs/lib と /usr/lib です。64 ビットの SPARC オブジェクトのリンクの場合は、1 つの標準的なディレクトリ /usr/lib/sparcv9 のみが使用されます。これ以外のディレクトリを検索させたい場合には、リンカーの検索パスに明示的に付加する必要があります。

リンカー検索パスを変更するには、コマンド行オプションを使用するか、環境変数を使用するという 2 種類の方法があります。

コマンド行オプションの使用

-L オプションを使用すると、ライブラリ検索に新しいパス名を追加できます。このオプションは、コマンド行上で遭遇したその地点で、検索パスに影響を与えます。たとえば、次のコマンドは、path1 (次に /usr/ccs/lib と /usr/lib) を検索し、libfoo を検出しますが、libbar を検出する場合は、path1 と path2 (次に /usr/ccs/lib と /usr/lib) を検索します。

$ cc -o prog main.o -Lpath1 file1.c -lfoo file2.c -Lpath2 -lbar

-L オプションを使用して定義されたパス名は、リンカー専用で、実行時リンカーが使用するために作成される出力ファイルイメージ内には記録されません。

カレントディレクトリ内のライブラリの検索にリンカーを使用する場合は、-L を指定する必要があります。ピリオド (.) を使用して、カレントディレクトリを示すことができます。

-Y オプションを使用すると、リンカーが検索するデフォルトのディレクトリを変更できます。このオプションに指定する引数は、ディレクトリのリストをコロンで区切った書式で示します。たとえば、次のコマンドは、ディレクトリ /opt/COMPILER/lib と /home/me/lib 内だけを調べて libfoo を検索します。

$ cc -o prog main.c -YP,/opt/COMPILER/lib:/home/me/lib -lfoo

-Y オプションを使用して指定したディレクトリは、-L オプションを使用して補足できます。

環境変数の使用

コロンで区切られたディレクトリリストをとる環境変数 LD_LIBRARY_PATH を使用しても、リンカーのライブラリ検索パスを付加できます。この最も一般的な書式 LD_LIBRARY_PATH では、セミコロンで区切られた 2 つのディレクトリリストをとります。最初のリストは、コマンド行上に指定されたリストよりも前に検索され、2 番目のリストはコマンド行上のリストよりもあとに検索されます。64 ビット SPARC オブジェクトを処理するときには、アクティブな LD_LIBRARY_PATH 設定を上書きする環境変数 LD_LIBRARY_PATH_64 もあります。

ここでは、LD_LIBRARY_PATH の設定と、いくつかの -L オプションを指定したリンカーの呼出しを組み合わせています。

$ LD_LIBRARY_PATH=dir1:dir2;dir3
$ export LD_LIBRARY_PATH
$ cc -o prog main.c -Lpath1 ... -Lpath2 ... -Lpathn -lfoo

有効な検索パスは、次のとおりです。

dir1:dir2:path1:path2... pathn:dir3:/usr/ccs/lib:/usr/lib

LD_LIBRARY_PATH 定義の一部にセミコロンが指定されてない場合は、指定されたディレクトリリストは、-L オプションのあとで解釈されます。次に例を示します。

$ LD_LIBRARY_PATH=dir1:dir2
$ export LD_LIBRARY_PATH
$ cc -o prog main.c -Lpath1 ... -Lpath2 ... -Lpathn -lfoo

ここでは、有効な検索パスは次のとおりです。

path1:path2... pathn:dir1:dir2:/usr/ccs/lib:/usr/lib

この環境変数は、実行時リンカーの検索パスを拡張する場合にも使用できます (詳細については、「実行時リンカーによって検索されるディレクトリ」を参照してください)。この環境変数がリンカーに影響しないようにするには、-i オプションを使用します。

実行時リンカーが検索するディレクトリ

デフォルトでは、実行時リンカーがライブラリを検出する場所として認識する標準的な場所は 1 つだけで、32 ビットオブジェクトを処理する場合は/usr/lib、64 ビット SPARC オブジェクトを処理する場合は /usr/lib/sparcv9 です。この他のディレクトリを検索する場合は、実行時リンカーの検索パスに明示的に追加する必要があります。

動的な実行可能プログラムまたは共有オブジェクトは、付加された共有オブジェクトとリンクされ、これらの共有オブジェクトは、実行時リンカーによるプロセスの実行中に再び配置される必要がある従属物として記録されます。リンク編集中には、1 つまたは複数のパス名を出力ファイル内に記録できます。これらのパス名は、実行時リンカーが共有オブジェクトの従属物を検索する場合に使用されます。この記録されたパス名は、「実行パス」と呼ばれます。

-z nodefaultlib オプションを使用してオブジェクトを作成すると、実行時に、標準的な場所 (/usr/lib あるいは /usr/lib/sparcv9) を検索しないようにできます。このオプションを使用すると、オブジェクトのすべての依存関係はその実行パスを使用して検索されます。多くの場合はこのオプションを使用せず、ユーザーが実行時リンカーのライブラリ検索パスをどのように修正しても、最後の構成要素は必ず、32 ビットオブジェクトの場合は /usr/lib、64 ビット SPARC オブジェクトの場合は /usr/lib/sparcv9 です。

-デフォルトの検索パスは、実行時構成ファイルを使用して管理できます (「デフォルトの検索パスの設定」を参照)。ただし、オブジェクト作成者はこのファイルの存在に頼らず、実行パスあるいは標準的なシステムのデフォルト設定のみを使用して、オブジェクトがその依存関係を検索できるようにしてください。

コロンで区切られたディレクトリリストをともなう、-R オプションを使用すると、動的実行可能プログラムまたは共有ライブラリ内に実行パスを記録できます。次に例を示します。

$ cc -o prog main.c -R/home/me/lib:/home/you/lib -Lpath1 ¥
-Lpath2 file1.c file2.c -lfoo -lbar

上記の例では、動的実行可能プログラム prog 内に、実行パス /home/me/lib:/home/you/lib が記録されます。実行時リンカーは、共有オブジェクトの依存関係を配置する場合に、これらのパスを使用してから、デフォルトのロケーション /usr/lib を使用します。この場合、この実行パスは、libfoo.so.1 と libbar.so.1 の配置に使用されます。

リンカーは、複数の -R オプションを受け取り、コロンで区切られたこれらの指定内容をそれぞれ結合します。そのため、上記の例は、次のようにも示すこともできます。

$ cc -o prog main.c -R/home/me/lib -Lpath1 -R/home/you/lib ¥
-Lpath2 file1.c file2.c -lfoo -lbar

さまざまな場所にインストールされる可能性のあるオブジェクトについては、$ORIGIN 動的ストリングトークンを使用して、柔軟に実行パスを記録できます。「関連する依存関係の配置」を参照してください。

-R オプションを指定することによる履歴的に代替とは、環境変数 LD_RUN_PATH を設定して、リンカーがこれを使用できるようにすることです。LD_RUN_PATH および -R の適用範囲と機能は全く同じですが、この両方を指定した場合は、-R によって LD_RUN_PATH は上書きされます。

セクションの初期設定と終了

.init と .fini セクションタイプを使用すると、実行時の初期設定および終了処理が行えます。これらのセクションタイプは、他のセクションと同様に入力再配置可能オブジェクトから結合されます。ただし、コンパイラドライバからも、入力ファイルリストの冒頭部分と末尾に付加する追加ファイルの一部として、.init と .fini を指定できます。

これらのファイルには、.init および .fini コードを、それぞれ予約シンボル名 _init と _fini のにより識別される個別の機能にカプセル化する効果があります。

動的実行可能プログラムまたは共有オブジェクトを構築すると、リンカーにより出力ファイルのイメージ内のこれらのシンボルアドレスが記録されます。そのため、初期設定および終了処理中は、動的実行可能プログラムまたは共有オブジェクトは実行時リンカーによって呼び出すことができます。これらのセクションの実行時処理の詳細については、「デバッギングエイド」を参照してください。

.init と .fini セクションの作成は、アセンブラを使用して直接実行できます。あるいは、コンパイラの中にはその宣言を単純化するための特別なプリミティブを提供しているものもあります。たとえば、次のコードセグメントの結果、関数 foo に対する「呼び出し」が .init セクション内に配置され、関数 bar に対する「呼び出し」が .fini セクション内に配置されます。

#pragma init (foo)
#pragma fini (bar)
foo()
{
    /* Perform some initialization processing. */
    ...... 
}   

bar()
{
    /* Perform some termination processing. */
    ....... 
}

共有オブジェクトとアーカイブライブラリの両方に組み込むことができる、初期設定コードと終了コードの設計をするときには注意が必要です。このコードが、アーカイブライブラリ内のいくつかの再配置可能オブジェクト全体に分散された場合、このアーカイブを使用したアプリケーションのリンク編集は、モジュールの一部しか抽出できないため、初期設定コードと終了コードの一部だけしか抽出できません。そして実行時に、コードのこの部分だけが実行されます。

共有オブジェクトがアプリケーションの依存関係の一つとして対応付けされている場合は、共有オブジェクトに対して構築された同じアプリケーションには、実行時に実行される、累積した初期設定コードと終了コードがすべて入っています。

また、.init コードが、dldump(3DL) を使用してメモリーをダンプできる動的オブジェクトとともに組み込まれている場合は、データの初期設定は独立させることをお勧めします。

シンボルの処理

入力ファイルの処理中に、入力再配置可能オブジェクトから局所シンボルが出力ファイルイメージに渡されます。大域シンボルはすべて、リンカーの内部に蓄積されます。この内部のシンボルテーブルは、処理される新しい大域シンボルのエントリごとに検索され、過去の入力ファイルで、同じ名前のシンボルに遭遇したことがあるかどうかが判別されます。同じ名前のシンボルに遭遇したことがある場合には、2 つのシンボルのうちどちらを保持するかを決定するために、シンボル解析プロセスが呼び出されます。

入力ファイル処理の完了時に、シンボル解析中に深刻なエラー状態が発生しなかった場合は、リンカーは、リンク編集の失敗を招く、結合されていないシンボルリファレンス (未定義シンボル) が残ってないかどうか判別します。

最後に、リンカーの内部シンボルテーブルが、作成されるイメージのシンボルテーブルに追加されます。

次の項では、シンボル解析と未定義シンボルの処理について詳しく説明します。

シンボル解析

シンボル解析は、簡単で直感的に分かるものから、複雑で当惑するようなものまで、すべての範囲を実行します。解析は、リンカーによって自動的に実行されるか、警告診断プログラムを伴って表示されるか、またはその結果、重大なエラー状態になります。

2 つのシンボルの解析は、シンボルの属性、シンボルを入手したファイルのタイプおよび生成されるファイルのタイプによって異なります。シンボルの属性についての詳細は、「シンボルテーブル」を参照してください。ただし、以下に説明するシンボルタイプは、識別する価値のある 3 つの基本的なシンボルタイプです。

未定義シンボル

このシンボルは、ファイル内で参照されましたが、記憶領域アドレスが割り当てられていません。

未確定シンボル

このシンボルは、ファイル内で作成されましたが、まだサイズが決められていないか、または記憶領域内に割り当てられていません。このようなシンボルは、初期化されていない C シンボル、または FORTRAN COMMON ブロックとしてファイル内に表示されます。

定義シンボル

このシンボルは、作成されてからファイル内の記憶領域アドレスおよびスペースが割り当てられています。

この最も単純な形式においては、シンボル解析には優先度関係の使用が伴います。つまり、定義シンボルは未確定シンボルよりも優先され、次に未確定シンボルは、未定義シンボルよりも優先されます。

次の C コードの例では、これらのシンボルタイプがどのようにして生成されるかを示しています (未定義シンボルには接頭辞 u_ が、未確定シンボルには接頭辞 t_ が、定義シンボルには接頭辞 d_ がそれぞれ付いています)。

$ cat main.c
extern int      u_bar;
extern int      u_foo();
 
int             t_bar;
int             d_bar = 1;
 
d_foo()
{
        return (u_foo(u_bar, t_bar, d_bar));
}
$ cc -o main.o -c main.c
$ nm -x main.o
 
[Index]   Value      Size      Type  Bind  Other Shndx   Name
...............
[8]     |0x00000000|0x00000000|NOTY |GLOB |0x0  |UNDEF  |u_foo
[9]     |0x00000000|0x00000040|FUNC |GLOB |0x0  |2      |d_foo
[10]    |0x00000004|0x00000004|OBJT |GLOB |0x0  |COMMON |t_bar
[11]    |0x00000000|0x00000000|NOTY |GLOB |0x0  |UNDEF  |u_bar
[12]    |0x00000000|0x00000004|OBJT |GLOB |0x0  |3      |d_bar

単純な解析

このシンボル解析は、群をぬいて最もよく使用されるもので、類似した特徴を持つ 2 つのシンボルが削除された場合や、1 つのシンボルが他のシンボルよりも優先される場合に実行されます。このシンボル解析は、リンカーによって自動的に実行されます。たとえば、同じ結びつきを伴う複数のシンボルでは、あるファイルから未定義シンボルへのリファレンスは結合されるか、または他のファイルからの定義シンボルまたは未確定シンボル定義によって満たされます。あるいは、あるファイルからの未確定シンボル定義は、他のファイルからの定義シンボルの定義に結合されます。

解析を受けるシンボルは、大域結合またはウィーク結合されます。ウィーク結合の方が、大域結合よりも優先度が低くなります。そのため、異なる結びつきを伴うシンボルは、基本規則のわずかな変更に従って解析されます。しかし、まず初めに、シンボルがどのように作成されるかを紹介しましょう。

ウィークシンボルは通常、個別にあるいは大域シンボルの別名として、コンパイラによって定義されます。この機構では、pragma 定義を使用します。

$ cat main.c
#pragma weak    bar
#pragma weak    foo = _foo
 
int             bar = 1;
 
_foo()
{
        return (bar);
}
$ cc -o main.o -c main.c
$ nm -x main.o
 
[Index]   Value      Size      Type  Bind  Other Shndx   Name
...............
[7]     |0x00000000|0x00000004|OBJT |WEAK |0x0  |3      |bar
[8]     |0x00000000|0x00000028|FUNC |WEAK |0x0  |2      |foo
[9]     |0x00000000|0x00000028|FUNC |GLOB |0x0  |2      |_foo

ウィークの別名 foo に、大域シンボル _foo と同じ属性が割り当てられていることに注意してください。この関係は、リンカーによって保持され、その結果、シンボルには出力イメージ内の同じ値が割り当てられます。

シンボル解析においては、ウィーク定義シンボルは、同じ名前の大域定義によって自動的に上書きされます。

単純なシンボル解析のこの他の形式は、再配置可能オブジェクトと共有オブジェクト間、または複数の共有オブジェクト間に発生し、挿入と呼ばれます。このような場合、シンボルが複数回定義されている場合、リンカーにより、再配置可能オブジェクト、または複数の共有オブジェクト間の最初の定義が自動的に採用されます。再配置可能オブジェクトの定義、または最初の共有オブジェクトの定義は、他のすべての定義上に挿入するといわれます。この挿入を使用すると、1 つの共有オブジェクト、動的実行可能プログラム、または他の共有オブジェクトによって提供された機能を上書きできます。

ウィークシンボルと挿入の組み合わせることにより、非常に有用なプログラミングテクニックを使用できます。たとえば、標準 C ライブラリは、再定義可能ないくつかのサービスを提供していますが、ANSI C は、システム上になければならない一連の標準サービスを定義し、厳密に適合するプログラム内に置き換えることはできません。

たとえば、関数 fread(3C) は、ANSI C ライブラリの関数ですが、関数 read(2) は、ANSI C ライブラリの関数ではありません。適合する ANSI C プログラムは、read(2) を再定義でき、予測できる方法で fread(3C) を使用できなければなりません。

ここでの問題は、read(2) は、標準 C ライブラリ内に fread(3C) を実装する基盤になるため、read(2) を再定義するプログラムは、fread(3C) の実装を間違える可能性があるのではないかと思われます。このような間違いをなくすためには、ANSI C は、実装には、そこに予約されていない名前は使用できないように指定します。さらに、以下に示す pragma 指示語を使用することにより、この予約名を定義できます。

#pragma weak read = _read

また、この予約名から、関数 read(2) の別名が生成されます。こうすることにより、ユーザーは、fread(3C) の実装に妥協することなく、自分専用の read() 関数を自由に定義できます。

標準 C ライブラリの、共有オブジェクトまたはアーカイブバージョンのどちらにリンクしている場合でも、ユーザーによる read() の再定義に対するリンカーからのクレームはありません。前者の場合には、挿入によって方法が決められ、後者の場合には、read(2) の C ライブラリの定義をウィークにすることにより、自動的に上書き可能になります。

リンカーの -m オプションを使用すると、挿入されるすべてのシンボルリファレンスのリストが、セクションの読み込みアドレス情報とともに標準出力に書き込まれます。

複雑な解析

複雑な解析は、同じ名前を持つ 2 つのシンボルが、異なる属性とともに検出された場合に発生します。この場合、リンカーは最も適切なシンボルを選択し、そのシンボル、対立する属性、およびそのシンボル定義を取り出したファイルの ID を示す警告メッセージを生成します。次に例を示します。

$ cat foo.c
int array[1];
 
$ cat bar.c
int array[2] = { 1, 2 };
 
$ cc -dn -r -o temp.o foo.c bar.c
ld: warning: symbol `array' has differing sizes:
        (file foo.o value=0x4; file bar.o value=0x8);
        bar.o definition taken

ここで、データ項目の配列の定義が指定された 2 つのファイルでは、サイズの必要条件が異なっています。シンボル配列の必要条件が異なる場合には、同様の診断プログラムが作成されます。この 2 つのケースの場合、リンカーの -t オプションを使用すると、診断プログラムを抑制できます。

この他の属性形式の違いに、シンボルの「タイプ」があります。次に例を示します。

$ cat foo.c
bar()
{
        return (0);
}
$ cc -o libfoo.so -G -K pic foo.c
$ cat main.c
int     bar = 1;
 
main()
{
        return (bar);
}
$ cc -o main main.c -L. -lfoo
ld: warning: symbol `bar' has differing types:
        (file main.o type=OBJT; file ./libfoo.so type=FUNC);
        main.o definition taken

ここで、シンボル bar() は、データ項目と関数の両方として定義されています。

このコンテキスト内の型とは、ELF で表されたシンボルタイプのことです。このシンボルタイプは、まったく手を加えられていない場合を除いて、プログラミング言語が使用するデータ型には関連していません。

このような場合には、再配置可能オブジェクトと共有オブジェクト間で解析が発生したときには、再配置可能オブジェクトの定義がとられます。または、2 つの共有オブジェクト間で解析が発生した場合には、最初の共有オブジェクトの定義がとられます。このような解析が異なる結合間 (「ウィーク」または「大域」) で発生すると、警告メッセージも同時に作成されます。

リンカーの -t オプションを使用しても、シンボルタイプ間の不一致は抑制できません。

重大な解析

解析できないシンボルの重複によって、重大なエラー状態が発生します。この場合、シンボルを入手したファイルの名前と同時に、そのシンボル名を指摘した適切なエラーメッセージが表示されて、出力ファイルは生成されません。この重大なエラー状態によってリンカーは停止しますが、すべての入力ファイルの処理が、まず最初に完了します。この要領で、重大な解析エラーをすべて識別できます。

最も一般的な、重大エラー状態は、2 つの再配置可能オブジェクトが両方とも同じ名前のシンボルを定義していて、どちらのシンボルもウィーク定義ではない場合に発生します。

$ cat foo.c
int bar = 1;
 
$ cat bar.c
bar()
{
        return (0);
}
 
$ cc -dn -r -o temp.o foo.c bar.c
ld: fatal: symbol `bar' is multiply defined:
        (file foo.o and file bar.o);
ld: fatal: File processing errors. No output written to int.o

ここで、foo.c と bar.c には、シンボル bar に対する重複する定義があります。リンカーは、どちらを優先すべきか判別できないため、通常、この処理は放棄されます。ただし、リンカーの -z muldefs オプションを使用すると、このエラー状態を防ぐことができ、リンカーが、最初のシンボル定義をとるように設定できます。

未定義シンボル

すべての入力ファイルを読み取り、シンボル解析がすべて完了すると、リンカーは、シンボル定義に結合されていないシンボルリファレンスの内部シンボルテーブルを検索します。これらのシンボルリファレンスは、未定義シンボルと呼ばれます。これらの未定義シンボルがリンク編集処理に及ぼす影響は、生成される出力ファイルのタイプや、場合によってはシンボルのタイプによって異なります。

実行可能ファイルの作成

リンカーが実行可能ファイルを作成しているときは、リンカーのデフォルトの動作は、シンボルを定義されないままにする必要がある適切なエラーメッセージを表示して、リンク編集を終了させることです。次のように、再配置可能オブジェクト内のシンボル「リファレンス」が、シンボル「定義」と絶対に一致しない場合に、シンボルは定義されないままの状態になります。

$ cat main.c
extern int foo();

main()
{
         return (foo());
}
$ cc -o prog main.c
Undefined           first referenced
 symbol                 in file
foo                     main.o
ld: fatal: Symbol referencing errors. No output written to prog

これと同様の方法で、共有オブジェクトが動的実行可能プログラムを構築するために使用されているときに、共有オブジェクト内のシンボルリファレンスが、シンボル定義と絶対に一致しない場合は、このシンボルリファレンスも未定義シンボルになります。

$ cat foo.c
extern int bar;
foo()
{
        return (bar);
}
 
$ cc -o libfoo.so -G -K pic foo.c
$ cc -o prog main.c -L. -lfoo
Undefined           first referenced
 symbol                 in file
bar                     ./libfoo.so
ld: fatal: Symbol referencing errors. No output written to prog

上記の例のような場合に、未定義シンボルを許可するには、リンカーの -z nodefs オプションを使用することにより、重大なエラー状態を防ぐことができます。

-z nodefs オプションを使用する場合は、注意が必要です。処理の実行中に使用できないシンボルリファレンスが要求されると、重大な実行時再配置エラーが発生します。このエラーは、初期化の実行中とアプリケーションのテスト中に検出できますが、実行パスが複雑であるために起こったこのエラー状態は、検出に時間がかかり、時間と費用が浪費される場合にがあります。

シンボルは、再配置可能オブジェクト内のシンボルリファレンスが、暗黙の内に定義された共有オブジェクト内のシンボル定義に結合されている場合にも、未定義シンボルのままになる場合があります。たとえば、上記の例で使用したファイル main.c および foo.c に以下のように続く場合です。

$ cat bar.c
int bar = 1;
 
$ cc -o libbar.so -R. -G -K pic bar.c -L. -lfoo
$ ldd libbar.so
        libfoo.so =>     ./libfoo.so
 
$ cc -o prog main.c -L. -lbar
Undefined           first referenced
 symbol                 in file
foo                     main.o  (symbol belongs to implicit ¥
                        dependency ./libfoo.so)
ld: fatal: Symbol referencing errors. No output written to prog

ここで、prog は、libbar.so への明示的なリファレンスを使用して構築されます。また、libbar.so には libfoo.so への依存性があるため、prog から libfoo.so への暗黙的なリファレンスが確立します。

main.c は、libfoo.so によって作成されたインタフェースへの特定のリファレンスを実行するため、prog は、実際に libfoo.so に依存性を持つことになります。ただし、生成される出力ファイル内に記録されるのは、明示的な共有オブジェクトの依存関係だけです。そのため、libbar.so の新しいバージョンが開発され、libfoo.so への依存性がなくなった場合、prog は実行に失敗します。

この理由から、このタイプのバインディングは重大であると考えられ、暗黙的な参照は、prog のリンク編集中にライブラリを直接参照することにより、明示的に実行される必要があります (この例で示した重大なエラーメッセージ内に必要なリファレンスのヒントがあります)。

共有オブジェクトの生成

リンカーが共有オブジェクトを生成する場合、デフォルトにより、未定義シンボルをリンク編集の末尾に残すことができます。これにより、共有オブジェクトはシンボルを、動的実行可能プログラムの構築に使用する場合、再配置可能オブジェクトまたは他の共有オブジェクトのどちらからでもインポートできます。リンカーの -z defs オプションを使用すると、未定義シンボルが残っていた場合に、強制的に重大エラーにすることができます (「追加シンボルの定義」で説明している extern mapfile 指示文も参考にしてください)。

通常、自己組み込み共有オブジェクトは、外部シンボルへのすべてのリファレンスは名前の付いた依存関係によって満たされ、最大の柔軟性が提供がされます。この場合の共有オブジェクトは、共有オブジェクトの必要条件を満たす依存関係を判別し、確立したユーザー以外の、多数のユーザーによって使用されます。

ウィークシンボル

生成中の出力ファイルタイプがどのようなタイプであっても、リンク編集中に結合されないウィークシンボルリファレンスにより、重大なエラー状態が発生します。

静的実行可能プログラムを生成中の場合は、シンボルは絶対シンボルに変換され、ゼロの値が割り当てられます。

動的実行可能プログラムまたは共有オブジェクトの作成中の場合は、シンボルは定義されていないウィークリファレンスとして残されます。プロセスの実行中に、実行時リンカーがこのシンボルを検索し、一致が検出されない場合は、重大な実行時再配置エラーを生成する代わりに、そのリファレンスをゼロのアドレスに結合します。

従来は、これらの定義されていないウィークリファレンスシンボルは、機能の存在をテストするためのメカニズムとして使用されていました。たとえば、次の C コードフラグは、共有オブジェクト libfoo.so.1 内で次のように使用されていました。

#pragma weak    foo

extern  void    foo(char *);

void bar(char * path)
{
         void (* fptr)();

         if ((fptr = foo) != 0)
                (* fptr)(path);
}

アプリケーションがリファレンス libfoo.so.1 で構築されると、シンボル foo の定義が検出されたかどうかに関係なく、リンク編集は、正常に完了します。アプリケーションの実行中に、機能アドレスが非ゼロをテストすると、その機能が呼び出されます。ただし、シンボル定義が検出されない場合には、機能アドレスはゼロをテストするため、その機能は呼び出されません。

ただし、コンパイルシステムは、定義されないセマンティクスを保持しながら、このアドレスの比較テクニックを参照します。その結果、テストステートメントは最適化処理によって削除されます。さらに、実行時シンボルの結合メカニズムでは、このテクニックの使用にこれ以外の制限も加え、これにより、すべての動的オブジェクトが整合性のあるモデルを使用できる状態ではなくなります。

ユーザーは、この方法で定義されていないウィークリファレンスを使用することをやめ、その代わりに RTLD_DEFAULT フラグを指定した dlsym(3DL) を使用してシンボルの存在テストを行うことをお勧めします (「機能のテスト」を参照してください)。

出力ファイル内の未確定シンボル順序

入力ファイルの追加は、通常、その追加の順に出力ファイルに表示されます。ただし、未確定シンボルとそれに関連する記憶領域を処理するときに、例外が発生します。未確定シンボルは、その解析が完了するまで完全に定義されません。再配置可能オブジェクトからの定義シンボルに遭遇すると、解析が実行されます。すると、表示される順序は、定義を調べるために実行された結果になります。

シンボルグループの順序を制御したい場合には、未確定定義は、ゼロで初期化されたデータ項目に際定義する必要があります。たとえば、次のような未確定定義をすると、出力ファイル内のデータ項目が、ソースファイル foo.c に記述された元の順序と比較されて再配列されます。

$ cat foo.c
char A_array[0x10];
char B_array[0x20];
char C_array[0x30];

$ cc -o prog main.c foo.c
$ nm -vx prog | grep array
[32]    |0x00020754|0x00000010|OBJT |GLOB |0x0  |15  |A_array
[34]    |0x00020764|0x00000030|OBJT |GLOB |0x0  |15  |C_array
[42]    |0x00020794|0x00000020|OBJT |GLOB |0x0  |15  |B_array

これらのシンボルを、初期化されたデータ項目として定義することにより、入力ファイル内のこれに関連したシンボルの配列が、出力ファイル内にも持ち越されます。

$ cat foo.c
char A_array[0x10] = { 0 };
char B_array[0x20] = { 0 };
char C_array[0x30] = { 0 };

$ cc -o prog main.c foo.c
$ nm -vx prog | grep array
[32]    |0x000206bc|0x00000010|OBJT |GLOB |0x0  |12  |A_array
[42]    |0x000206cc|0x00000020|OBJT |GLOB |0x0  |12  |B_array
[34]    |0x000206ec|0x00000030|OBJT |GLOB |0x0  |12  |C_array

追加シンボルの定義

シンボルを入力ファイルから提供することに加えて、ユーザーは、リンク編集に、追加のシンボルリファレンスまたは定義を指定できます。最も簡単な形式で、シンボルリファレンスは、リンカーの -u オプションを使用して作成できます。より柔軟性の高いものは、リンカーの -M オプションと、それに関連した、シンボルリファレンスと種々のシンボル定義を定義できる mapfile を使用して作成できます。

-u オプションを指定すると、リンク編集コマンド行からシンボルリファレンスを作成するためのメカニズムが使用できます。このオプションは、リンク編集をすべてアーカイブから実行する場合に使用でき、また、複数のアーカイブから抽出するオブジェクトの選択における柔軟性を向上させることができます (アーカイブの抽出については、「アーカイブ処理」の項を参照してください)。

たとえば、動的実行可能プログラムの生成を、シンボル foo と bar へのリファレンスを実行する再配置可能オブジェクト main.o から抽出してみましょう。この場合、lib1.a 内に組み込まれた再配置可能オブジェクト foo.o からシンボル定義 foo を入手し、さらに lib2.a 内に組み込まれた再配置可能オブジェクト bar.o からシンボル定義 bar を入手します。

ただし、アーカイブ lib1.a にも、シンボル bar を定義する再配置可能オブジェクトが組み込まれています (lib2.a に提供されたものとは機能的に異なると仮定した場合)。必要なアーカイブ抽出を指定する場合は、次のようなリンク編集を使用できます。

$ cc -o prog -L. -u foo -l1 main.o -l2

ここで、-u オプションは、シンボル foo へのリファレンスを生成します。このリファレンスによって、再配置可能オブジェクト foo.o がアーカイブ lib1.a から抽出されます。シンボル bar への最初のリファレンスは、lib1.a が処理されてから生じる main.o 内で実行されるため、再配置可能オブジェクト bar.o はアーカイブ lib2.a から入手されます。

この単純な例では、lib1.a からの 再配置可能オブジェクト foo.o は、シンボル bar の直接的または間接的な参照は行いません。この参照を行なった場合、再配置可能オブジェクト bar.o は、その処理中に、lib1.a から抽出されます (アーカイブを処理するリンカーの多重パスについては、「アーカイブ処理」を参照してください)。

より広範囲なシンボル定義のセットは、リンカーの -M オプションと関連する mapfile を使用して入手できます。これらの mapfile エントリの構文は次のとおりです。

[ name ] {
      scope:
            symbol [ = [ type ] [ value ] [ size ] [ extern ] ];
} [ dependency ];

name

このシンボル定義のセットのラベルは、もしあれば、イメージ内のバージョン定義を識別できます。詳細については、第 5 章「バージョンアップ」を参照してください。

scope

生成される出力ファイル内のシンボルのバインディングの可視性を示しています。これには、値 local (局所) または global (大域) のいずれかが入ります。mapfile で定義されたすべてのシンボルは、リンク編集プロセス中に、scope (スコープ) 内で global (大域) として処理されます。つまり、これらのシンボルは、入力ファイルのいずれかから入手された、同じ名前の他のシンボルに対して解析されます。ただし、local (局所) scope として定義シンボルは、生成される実行可能プログラムまたは共有オブジェクトのファイル内の局所結合が指定されたシンボルに変更されます。

symbol

要求されたシンボルの名前です。この名前のあとに、シンボル属性 (type、value、size のいずれか) が付いていない場合には、シンボルリファレンスの作成になります。このリファレンスは、この項の最初に説明した -u オプションを使用して生成するリファレンスとまったく同じものです。このシンボル名にシンボル属性が付いている場合には、シンボル定義は、関連する属性を使用して生成されます。

local スコープ内では、このシンボル名は、特別な 「auto-reduction」(自動縮小) 指示語「*」として定義できます。この指示語を使用すると、すべての大域シンボル (mapfile 内に global と明示的に定義されていないもの) に、生成される実行可能プログラムまたは共有オブジェクトファイル内で、局所結合を受け取ります。

type

シンボルのタイプ属性を示します。また、ここには、data、function、common のいずれかが入ります。最初の 2 つのタイプ属性の結果は、絶対的なシンボル定義になります (「シンボルテーブル」を参照してください)。後者のタイプ属性の結果は、未確定シンボル定義になります。

value

シンボルの値属性を示し、Vnumber の書式をとります。

size

シンボルのサイズ属性を示し、Snumber の書式をとります。

extern

シンボルが、作成されているオブジェクトに外部的に定義されていることを示します。このオプションを使用して、-z defs オプションで示された未定義シンボル (「共有オブジェクトの生成」を参照) を抑制できます。

dependency

この定義が継承する version definition (バージョン定義) を示します。詳細については、第 5 章「バージョンアップ」を参照してください。

バージョン定義または自動縮小のいずれかの指示語が指定されている場合、バージョン情報が作成されるイメージ内に記録されます。このイメージが実行可能プログラムまたは共有オブジェクトである場合には、シンボル縮小も適用されます。

作成されるイメージが再配置可能オブジェクトである場合は、デフォルトにより、シンボル縮小は適用されません。この場合、シンボル縮小はバージョン情報の一部として記録され、これらの縮小は、再配置可能オブジェクトが最終的に実行可能プログラムまたは共有オブジェクトの生成に使用されるときに適用されます。リンカーの -B reduce オプションを使用すると、再配置可能オブジェクトを生成するときに、強制的にシンボル縮小を実行できます。

バージョン情報の詳細については、第 5 章「バージョンアップ」に記載してあります。

インタフェース定義を確実に安定させるためには、シンボル名の定義に対しワイルドカードによる拡張を行わないようにします。

この項では、このあと、この mapfile 構文を使用した例をいくつか示します。

以下の例は、3 つのシンボルリファレンスを定義する方法と、これらを使用してアーカイブから構成要素を抽出する方法を示しています。このアーカイブ抽出は、複数の -u オプションをリンク編集に指定することにより実現できますが、この例では、最終的なシンボルの範囲を、局所に縮小する方法も示しています。

$ cat foo.c
foo()
{
         (void) printf("foo: called from lib.a¥n");
}
$ cat bar.c
bar()
{
         (void) printf("bar: called from lib.a¥n");
}
$ cat main.c
extern  void    foo(), bar();

main()
{
         foo();
         bar();
}
$ ar -rc lib.a foo.o bar.o main.o
$ cat mapfile
{
         local:
                 foo;
                 bar;
         global:
                 main;
};
$ cc -o prog -M mapfile lib.a
$ prog
foo: called from lib.a
bar: called from lib.a
$ nm -x prog | egrep "main$|foo$|bar$"
[28]    |0x00010604|0x00000024|FUNC |LOCL |0x0  |7      |foo
[30]    |0x00010628|0x00000024|FUNC |LOCL |0x0  |7      |bar
[49]    |0x0001064c|0x00000024|FUNC |GLOB |0x0  |7      |main

大域から局所へのシンボル範囲の縮小の重要性については、「シンボル範囲の縮小」で説明しています。

次の例では、2 つの絶対シンボル定義を定義し、これらを使用して入力ファイル main.c からのリファレンスを解析する方法を示しています。

$ cat main.c
extern  int     foo();
extern  int     bar;

main()
{
         (void) printf("&foo = %x¥n", &foo);
         (void) printf("&bar = %x¥n", &bar);
}
$ cat mapfile
{
         global:
                 foo = FUNCTION V0x400;
                 bar = DATA V0x800;
};
$ cc -o prog -M mapfile main.c
$ prog
&foo = 400 &bar = 800
$ nm -x prog | egrep "foo$|bar$"
[37]    |0x00000800|0x00000000|OBJT |GLOB |0x0  |ABS    |bar
[42]    |0x00000400|0x00000000|FUNC |GLOB |0x0  |ABS    |foo

入力ファイルから入手される場合、関数のシンボル定義またはデータ項目は、通常、データ記憶域の要素に関連しています。mapfile 定義は、このデータ記憶域を構成するためには不十分であるため、これらのシンボルは、絶対値として残しておく必要があります。

ただし、mapfile は、common または未確定シンボルを定義する場合にも使用できます。他のタイプのシンボル定義とは違って、未確定シンボルは、ファイル内の記憶域を占有しませんが、実行時に割り当てる記憶域の定義は行います。そのため、このタイプのシンボル定義は、作成される出力ファイルの記憶域割り当ての一因となります。

未確定シンボルの特徴は、他のシンボルタイプとは異なり、その値の属性によって、その配列条件が示される点です。mapfile 定義は、リンク編集の入力ファイルから入手された未確定定義の再配列に使用されます。

次の例では、2 つの未確定シンボルの定義を示しています。シンボル foo は、新しい記憶領域を定義しているのに対し、シンボル bar は、実際に、ファイル main.c 内の同じ未確定定義の配列を変更するために使用されます。

$ cat main.c
extern  int     foo;
int             bar[0x10];
 
main()
{
        (void) printf("&foo = %x¥n", &foo);
        (void) printf("&bar = %x¥n", &bar);
}
$ cat mapfile
{
        global:
                foo = COMMON V0x4 S0x200;
                bar = COMMON V0x100 S0x40;
};
$ cc -o prog -M mapfile main.c
ld: warning: symbol `bar' has differing alignments:
        (file mapfile value=0x100; file main.o value=0x4);
        largest value applied
$ prog
&foo = 20940
&bar = 20900
$ nm -x prog | egrep "foo$|bar$"
[37]    |0x00020900|0x00000040|OBJT |GLOB |0x0  |16     |bar
[42]    |0x00020940|0x00000200|OBJT |GLOB |0x0  |16     |foo

このシンボル解析の診断は、リンカーの -t オプションを使用すると表示されません。

シンボル範囲の縮小

前の項では、mapfile 内のローカル範囲を持つように定義シンボル定義を使用して、シンボルの最終的な結合を縮小する方法を示しました。このメカニズムは、入力の一部として生成されたファイルを使用する、将来のリンク編集に対するシンボルの可視性を削減するという重要な役割を果たします。実際、このメカニズムは、ファイルのインタフェースの厳密な定義をするために提供されているため、他のユーザーに対して、機能の使用を制限できます。

たとえば、簡単な共有オブジェクトを、ファイル foo.c と bar.c から生成するとします。ファイル foo.c には、他のユーザーも使用できるように設定するサービスを提供する大域シンボル foo が組み込まれています。ファイル bar.c には、共有オブジェクトの根底となるインプリメンテーションを提供するシンボル bar と str が組み込まれています。簡単に構成された共有オブジェクトは、通常、これらの 3 つのシンボルすべてには、次のように大域範囲が指定されています。

$ cat foo.c
extern  const char *    bar();
 
const char * foo()
{
        return (bar());
}
$ cat bar.c
const char * str = "returned from bar.c";
 
const char * bar()
{
        return (str);
}
$ cc -o lib.so.1 -G foo.c bar.c
$ nm -x lib.so.1 | egrep "foo$|bar$|str$"
[29]    |0x000104d0|0x00000004|OBJT |GLOB |0x0  |12     |str
[32]    |0x00000418|0x00000028|FUNC |GLOB |0x0  |6      |bar
[33]    |0x000003f0|0x00000028|FUNC |GLOB |0x0  |6      |foo

このようにすると、この共有オブジェクトが提供する機能を、他のアプリケーションのリンク編集の一部として使用できます。シンボル foo へのリファレンスは、共有オブジェクトによって提供されたインプリメンテーションに結合されます。

大域結合により、シンボル bar と str への直接リファレンスも可能ですが、これは、危険な結果を招く場合があります。それは、ユーザーが、関数 foo の基礎となるインプリメンテーションをあとから変更すると、それが原因で知らないうちに、bar または str に結合された既存のアプリケーションが失敗または誤作動を起こします。

この他の、シンボル bar と str の大域結合の結果、同じ名前のシンボルによって、割り込みすることが可能になります (共有オブジェクト内へのシンボルの割り込みについては、「単純な解析」の項で説明しています)。この割り込みは、意図的に行うことができ、これを使用することにより、共有オブジェクトが提供する目的の機能を取り囲むことができます。また反対に、この割り込みは、同じ共通のシンボル名をアプリケーションと共有オブジェクトの両方に使用した結果として、知らないうちに実行される場合もあります。

共有オブジェクトを開発する場合は、シンボル bar と str の範囲を局所結合に縮小して、このような事態から保護することができます。次に例を示します。

$ cat mapfile
{
        local:
                bar;
                str;
};
$ cc -o lib.so.1 -M mapfile -G foo.c bar.c
$ nm -x lib.so.1 | egrep "foo$|bar$|str$"
[27]    |0x000003dc|0x00000028|FUNC |LOCL |0x0  |6      |bar
[28]    |0x00010494|0x00000004|OBJT |LOCL |0x0  |12     |str
[33]    |0x000003b4|0x00000028|FUNC |GLOB |0x0  |6      |foo

ここでは、シンボル bar と str は、共有オブジェクトのインタフェースの一部としては使用できません。そのため、これらのシンボルは、外部のオブジェクトによって参照されることができないか、割り込みはできません。ユーザーは、インタフェースをこの共有オブジェクト用に効果的に定義できます。インプリメンテーションの基礎となる詳細を隠している間は、このインタフェースを管理できます。

このようなシンボル範囲の縮小には、この他にもパフォーマンスにおける利点があります。実行時に必要だったシンボル bar と str に対するシンボルの再配置は、現在は、関連する再配置に縮小されます。これにより、実行時の、共有オブジェクトの初期設定と処理のオーバヘッドが削減されます (シンボル再配置のオーバーヘッドの詳細は、「再配置を実行する場合」を参照してください)。

リンク編集間で処理されるシンボル数が多くなると、mapfile 内で各ローカル範囲への縮小を定義する能力の維持が困難になります。その代わりとなる、より柔軟性のあるメカニズムを使用すると、共有オブジェクトインタフェースを、保持する必要がある大域シンボルとして定義でき、他のシンボルはすべて局所結合に縮小するようにリンカーに指示できます。このメカニズムは、特別な 自動縮小 指示語の「*」を使用して実行します。たとえば、前の mapfile 定義を書き換えて、foo を、生成される出力ファイル内で必要な大域シンボルとしてのみ定義します。

$ cat mapfile
lib.so.1.1
{         global:
                 foo;
         local:
                 *;
};
$ cc -o lib.so.1 -M mapfile -G foo.c bar.c
$ nm -x lib.so.1 | egrep "foo$|bar$|str$"
[30]    |0x00000370|0x00000028|FUNC |LOCL |0x0  |6      |bar
[31]    |0x00010428|0x00000004|OBJT |LOCL |0x0  |12     |str
[35]    |0x00000348|0x00000028|FUNC |GLOB |0x0  |6      |foo

この例では、バージョン名 lib.so.1.1 も mapfile 指示語の一部として定義しています。このバージョン名により、ファイルのシンボルインタフェースを定義する、内部バージョン定義が確立されます。バージョン定義の作成は推奨されています。バージョン定義により、ファイルの展開全体を通して使用できる、内部バージョンメカニズムの基礎が形成されます。この詳細については、第 5 章「バージョンアップ」を参照してください。

バージョン名が指定されていないと、出力ファイル名がバージョン定義のラベル付けに使用されます。出力ファイル内に作成されたバージョン情報は、リンカーの -z noversion オプションを使用して表示しないようにできます。

バージョン名が指定されている場合は必ず、すべての大域シンボルをバージョン定義に割り当てる必要があります。バージョン定義に割り当てられていない大域シンボルが残っていると、リンカーにより重大なエラー状態が発生します。

$ cat mapfile
lib.so.1.1 {
         global:
                 foo;
};
$ cc -o lib.so.1 -M mapfile -G foo.c bar.c
Undefined           first referenced
 symbol                 in file
str                     bar.o  (symbol has no version assigned)
bar                     bar.o  (symbol has no version assigned)
ld: fatal: Symbol referencing errors. No output written to lib.so.1

実行可能プログラムまたは共有オブジェクトを作成するときに、シンボルの縮小処理が行われると、該当するシンボルが縮小されると同時に、出力イメージ内にバージョン定義が記録されます。デフォルトにより、再配置可能オブジェクトの生成時に、バージョン定義は作成されますが、シンボルの縮小処理は行われません。その結果、シンボル縮小のシンボルエントリは、大域のまま残されます。たとえば、「自動縮小」指示語が指定された、前の mapfile と関連する再配置可能オブジェクトを使用して、シンボル縮小が表示されていない中間再配置可能オブジェクトが作成されます。

$ ld -o lib.o -M mapfile -r foo.o bar.o
$ nm -x lib.o | egrep "foo$|bar$|str$"
[17]    |0x00000000|0x00000004|OBJT |GLOB |0x0  |3      |str
[19]    |0x00000028|0x00000028|FUNC |GLOB |0x0  |1      |bar
[20]    |0x00000000|0x00000028|FUNC |GLOB |0x0  |1      |foo

ただし、このイメージ内に作成された「バージョン定義」は、シンボル縮小が要求されたという事実を記録します。再配置可能オブジェクトが、最終的に、実行可能プログラムまたは共有オブジェクトの生成に使用されるときに、シンボル縮小が実行されます。すなわち、リンカーは、mapfile からデータを処理するのと同じ方法で、再配置可能オブジェクト内に組み込まれたシンボル縮小を読み取り、解釈します。

そのため、上記の例で作成された中間再配置可能オブジェクトは、ここで、共有オブジェクトの生成に使用されます。

$ cc -o lib.so.1 -M mapfile -G lib.o
$ nm -x lib.so.1 | egrep "foo$|bar$|str$"
[22]    |0x000104a4|0x00000004|OBJT |LOCL |0x0  |14     |str
[24]    |0x000003dc|0x00000028|FUNC |LOCL |0x0  |8      |bar
[36]    |0x000003b4|0x00000028|FUNC |GLOB |0x0  |8      |foo

シンボル縮小は、再配置可能オブジェクトが構築されるときに、リンカーの -B reduce オプションを使用して強制的に実行されます。

$ ld -o lib.o -M mapfile -B reduce -r foo.o bar.o
$ nm -x lib.o | egrep "foo$|bar$|str$"
[15]    |0x00000000|0x00000004|OBJT |LOCL |0x0  |3      |str
[16]    |0x00000028|0x00000028|FUNC |LOCL |0x0  |1      |bar
[20]    |0x00000000|0x00000028|FUNC |GLOB |0x0  |1      |foo

出力イメージの生成

入力ファイルの処理とシンボル解析がすべて、重大なエラーが発生することもなく完了すると、リンカーは出力イメージファイルの生成を開始します。リンカーは、出力ファイルイメージを完成させるために生成する必要がある追加セクションを確立します。これには、入力ファイルからの局所シンボル定義が組み込まれたシンボルテーブルとともに、その内部シンボルテーブルから収集された大域およびウィークシンボル情報が組み込まれます。

また、実行時リンカーが必要とする、出力の再配置および動的情報セクションも組み込まれます。出力セクション情報が確立されると、出力ファイルの合計サイズが算出され、それに従って出力ファイルイメージが作成されます。

動的実行可能プログラムまたは共有オブジェクトを構築するときに、通常、2 つのシンボルテーブルが生成されます。.dynsym とその関連ストリングテーブル .dynstr には、レジスタ (これらがローカルであっても)、大域シンボル、ウィークシンボル、およびセクションシンボルが組み込まれます。これらのセクションは、実行時にプロセスイメージの一部として対応付けされる text セグメントの一部になります。これにより、実行時リンカーは、これらのセクションを読み取り、必要な再配置を実行できます。

.symtab とその関連ストリングテーブル .strtab には、入力ファイル処理から収集された「すべての」シンボルが含まれています。これらのセクションは、プロセスイメージの一部として対応付けされず、リンカーの -s オプションを使用するか、リンク編集後に strip(1) を使用して、イメージから取り除くことさえ可能です。

予約シンボルは、シンボルテーブルの生成中に作成されます。予約シンボルは、リンクプロセスに対する特別な意味を持ち、ユーザーのコードでは定義できません。

_etext

テキストセグメントのあとの最初のロケーション

_edata

初期化されたデータの最初のロケーション

_end

すべてのデータのあとの最初のロケーション

_DYNAMIC

動的情報セクション (.dynamic セクション) のアドレス

_END_

_end と同じですが、このシンボルには局所範囲があります (「_START_」を参照)。

_GLOBAL_OFFSET_TABLE_

リンカーが提供するアドレステーブル (.got セクション) への、ポジション固有のリファレンス。このテーブルは、ポジション固有のデータリファレンスから構成されます。このデータリファレンスは、 -K pic オプションを使用してコンパイルされたオブジェクト内で発生します (詳細については、「位置に依存しないコード」を参照してください)。

_PROCEDURE_LINKAGE_TABLE_

リンカーが提供するアドレステーブル (.plt セクション) への、ポジション固有のリファレンス。このテーブルは、ポジション固有の関数リファレンスから構成されます。このデータリファレンスは、-K pic オプションを使用してコンパイルされたオブジェクト内で発生します (詳細については、「位置に依存しないコード」を参照してください)。

_START_

テキストセグメント内の最初のロケーション。このシンボルは、_END_ とともに、局所範囲を持ち、オブジェクトのアドレス範囲を確立する手段を提供します。

リンカーは、実行可能プログラムを生成する場合、追加シンボルを検出して実行可能プログラムのエントリポイントを定義します。シンボルがリンカーの -e オプションを使用して指定された場合、これが使用されます。それ以外の場合は、リンカーは予約シンボル名 _start と main を検出します。これらのシンボルが存在しない場合には、テキストセグメントの最初のアドレスが使用されます。

出力ファイルを作成すると、入力ファイルからのすべてのデータセクションは新しいイメージにコピーされます。入力ファイル内に指定された再配置は、出力イメージに適用されます。生成する必要がある新しい再配置情報に加えて、他のリンカーが生成した情報もすべて、新しいイメージに書き込まれます。

デバッギングエイド

Solaris リンカーには、デバ ッギングライブラリが付いていて、これを使用するとリンク編集プロセスをより詳細に監視できます。このライブラリは、ユーザー自身のアプリケーションまたはライブラリのリンク編集を理解またはデバッグする場合に役立ちます。これは、ビジュアルエイドで、このライブラリを使用して表示される情報のタイプは、定数のままであると予期されますが、この情報の正確な形式は、リリースごとにわずかに変更される場合があります。

ELF フォーマットを熟知していないと、デバッギング出力の中には見慣れないものがあるかもしれませんが、多くのものが一般的な関心を惹くものでしょう。

デバッギングは、-D オプションを使用して実行できます。また、作成された出力はすべて標準エラーに直接送信されます。このオプションは、1 つまたは複数のトークンで拡張し、必要なデバッギングのタイプを指示する必要があります。使用できるトークンは、-Dhelp を使用して表示できます。次に例を示します。

$ ld -Dhelp
debug:
debug:           For debugging the link-editing of an application:
debug:                  LD_OPTIONS=-Dtoken1,token2 cc -o prog ...
debug:           or,
debug:                  ld -Dtoken1,token2 -o prog ...
debug:           where placement of -D on the command line is significant
debug:           and options can be switched off by prepending with `!'.
debug:
debug:
debug: args      display input argument processing
debug: basic     provide basic trace information/warnings
debug: detail    provide more information in conjunction with other
debug:           options
debug: entry     display entrance criteria descriptors
debug: files     display input file processing (files and libraries)
debug: help      display this help message
debug: libs      display library search paths; detail flag shows actual
debug:           library lookup (-l) processing
debug: map       display map file processing
debug: move      display move section processing
debug: reloc     display relocation processing
debug: sections  display input section processing
debug: segments  display available output segments and address/offset
debug:           processing; detail flag shows associated sections
debug: support   display support library processing
debug: symbols   display symbol table processing;
debug:           detail flag shows resolution and linker table addition
debug: versions  display version processing
debug: got       display GOT symbol information

このリストは、一例で、リンカーに有用なオプションを表示しています。正確なオプションは、リリースごとに異なる場合があります。

ほとんどのコンパイラドライバは、-D オプションの解釈をその前処理フェーズ中に行うため、リンカーにこのオプションを渡すためには、LD_OPTIONS 環境変数のメカニズムが適しています。

次の例では、入力ファイルの監視方法を示しています。これは、特に、リンク編集中に、配置されたライブラリ、またはアーカイブから抽出された再配置可能オブジェクトを判別する場合に有用です。

$ LD_OPTIONS=-Dfiles cc -o prog main.o -L. -lfoo
............
debug: file=main.o  [ ET_REL ]
debug: file=./libfoo.a  [ archive ]
debug: file=./libfoo.a(foo.o)  [ ET_REL ]
debug: file=./libfoo.a  [ archive ] (again)
............

ここでは、prog のリンク編集を満足させるために、構成要素 foo.o がアーカイブライブラリ libfoo.a から抽出されています。foo.o の抽出が、その他の再配置可能オブジェクトの抽出を認めていないことを検証するために、このアーカイブが 2 回 (again) 検索されていることに注意してください。(again) が複数表示されていることによって、このアーカイブが lorder(1) と tsort(1) を使用した並び替えの候補になっていることがわかります。

シンボル トークンを使用することにより、どのシンボルによってアーカイブ構成要素が抽出されたか、また、最初のシンボルリファレンスを実行したオブジェクトを判別できます。

$ LD_OPTIONS=-Dsymbols cc -o prog main.o -L. -lfoo
............
debug: symbol table processing; input file=main.o  [ ET_REL ]
............
debug: symbol[7]=foo  (global); adding
debug:
debug: symbol table processing; input file=./libfoo.a  [ archive ]
debug: archive[0]=bar
debug: archive[1]=foo  (foo.o) resolves undefined or tentative symbol
debug:
debug: symbol table processing; input file=./libfoo(foo.o)  [ ET_REL ]
.............

ここでは、シンボル foo は、main.o によって参照され、リンカーの内部シンボルテーブルに付加されます。このシンボルリファレンスによって、再配置可能オブジェクト foo.o が、アーカイブ libfoo.a から抽出されます。

この出力は、このマニュアル用に簡素化したものです。

detail トークンを、シンボルトークンとともに使用すると、入力ファイル処理中のシンボル解析を監視できます。

$ LD_OPTIONS=-Dsymbols,detail cc -o prog main.o -L. -lfoo
............
debug: symbol table processing; input file=main.o  [ ET_REL ]
............
debug: symbol[7]=foo  (global); adding
debug:   entered  0x000000 0x000000 NOTY GLOB  UNDEF REF_REL_NEED
debug:
debug: symbol table processing; input file=./libfoo.a  [ archive ]
debug: archive[0]=bar
debug: archive[1]=foo  (foo.o) resolves undefined or tentative symbol
debug:
debug: symbol table processing; input file=./libfoo.a(foo.o)  [ ET_REL ]
debug: symbol[1]=foo.c
.............
debug: symbol[7]=bar  (global); adding
debug:   entered  0x000000 0x000004 OBJT GLOB  3     REF_REL_NEED
debug: symbol[8]=foo  (global); resolving [7][0]
debug:       old  0x000000 0x000000 NOTY GLOB  UNDEF main.o
debug:       new  0x000000 0x000024 FUNC GLOB  2     ./libfoo.a(foo.o)
debug:  resolved  0x000000 0x000024 FUNC GLOB  2     REF_REL_NEED

ここでは、main.o からの、オリジナルの未定義シンボル foo が、アーカイブ構成要素 foo.o から抽出されたシンボル定義で上書きされます。このシンボルの詳細情報は、各シンボルの属性に反映されます。

上記の例からわかるように、デバッギングトークンのいくつかを使用すると、豊富な出力が作成されます。入力ファイルのサブセットにかかわるアクティビティだけに関心がある場合には、-D オプションを、リンク編集コマンド行内に直接配置し、オンとオフを切り替えます。次に例を示します。

$ ld .... -o prog main.o -L. -Dsymbols -lbar -D!synbols .... 

ここでは、シンボル処理の表示がオンになるのは、ライブラリ libbar の処理中だけです。

リンク編集コマンド行を入手するには、使用しているドライバからコンパイル行を拡張する必要があります。詳細については、「コンパイラドライバを使用する」を参照してください。