dbx では、Linux プラットフォームの objcopy コマンド、および Oracle Solaris プラットフォームの gobjcopy コマンドの各オプションを使用して、実行可能ファイルから個別のデバッグファイルにデバッグ情報をコピーし、その情報を実行可能ファイルからストリップして、これらの 2 つのファイルの間にリンクを作成することができます。
dbx は、次の順序で別のデバッグファイルを検索し、最初に見つかったファイルからデバッグ情報を読み取ります。
実行可能ファイルを含むディレクトリ。
実行可能ファイルを含むディレクトリ内の debug という名前のサブディレクトリ。
グローバルデバッグファイルディレクトリのサブディレクトリ。これは、dbxenv 変数 debug_file_directory がそのディレクトリのパス名に設定されている場合は表示または変更できます。環境変数のデフォルト値は、/usr/lib/debug です。
たとえば、次の手順は、実行可能ファイル a.out の個別のデバッグファイルを作成する方法を説明しています。
objcopy --only-keep-debug a.out a.out.debug
objcopy --strip-debug a.out
objcopy --add-gnu-debuglink=a.out.debug a.out
Oracle Solaris プラットフォームでは、gobjcopy コマンドを使用します。Linux プラットフォームの場合、objcopy コマンドを使用します。
Linux プラットフォームでは、objcopy –help コマンドを使用して、このプラットフォームで –add-gnu-debuglink オプションがサポートされているかどうかを調べることができます。objcopy コマンドの –only-keep-debug オプションは、a.out.debug を完全な実行可能ファイルにすることができる cp a.out a.out.debug コマンドに置き換えることができます。
デフォルトでは、ロードオブジェクトには割り当て可能なセクションと割り当て不可のセクションの両方が含まれています。割り当て可能なセクションは、実行可能コードとそのコードが実行時に必要とするデータが含まれているセクションです。割り当て不可のセクションには、実行時のファイルの実行には必要がない補足情報が含まれています。これらのセクションは、デバッガおよびその他の可観測性ツールの動作をサポートします。オブジェクト内の割り当て不可のセクションは、実行時にオペレーティングシステムによってメモリーに読み込まれないため、どのようなサイズであっても、メモリーの使用やその他の実行時パフォーマンスの側面に影響を与えません。
利便性のため、割り当て可能なセクションと割り当て不可のセクションは、通常どちらも同じファイルに保持されます。しかし、これらのセクションを分離した方が有用な場合があります。特に、高度に最適化されたコードのきめ細かいデバッグをサポートするには、大量のデバッグデータが必要になります。最近のシステムでは、記述されるコードよりもデバッグデータの方が簡単に大きくなります。32 ビットオブジェクトのサイズは 4G バイトに制限されています。非常に大きな 32 ビットオブジェクトでは、デバッグデータのためにこの制限を超え、オブジェクトを作成できなくなる可能性があります。
従来より、これらの問題に対処するために、ロードオブジェクトからは割り当て不可のセクションがストリップされています。除去は有効ですが、あとで必要になる可能性があるデータも破棄されます。Oracle Solaris リンカーは、代わりに、割り当て不可のセクションを補助ファイルに書き込むことができます。この機能は、–z ancillary コマンド行オプションを使用して有効にします。
% ld ... –z ancillary[=outfile] ... /* Your file is separated into a.out and b.out, where a.out: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, ancillary object b.out b.out: ELF 32-bit LSB ancillary 80386 Version 1, primary object a.out */
補助ファイルには、デフォルトでプライマリ出力オブジェクトと同じ名前と .anc ファイル拡張子が付けられます。ただし、–z ancillary オプションに outfile の値を指定することで、別の名前を付けることができます。
–z ancillary が指定されると、リンカーは次のことを行います。
すべての割り当て可能なセクションがプライマリファイルに書き込まれます。さらに、SHF_SUNW_PRIMARY セクションヘッダーフラグが設定された 1 つ以上の入力セクションを含むすべての割り当て不可のセクションがプライマリファイルに書き込まれます。
残りのすべての割り当て不可のセクションが補助ファイルに書き込まれます。
両方の出力ファイルは、次の既知の割り当て不可のセクションの完全な同一コピーを受信します。
セクション名文字列テーブル。
完全な非動的シンボルテーブル。
.symtab に関連付けられたシンボルテーブルの拡張インデックスセクション。
.symtab に関連付けられた非動的文字列テーブル。
プライマリオブジェクトとすべての補助オブジェクトを識別したり、調査されているオブジェクトを識別したりするために必要な情報が含まれています。
プライマリファイルとすべての補助ファイルには、セクションヘッダーの同じ配列が含まれています。各セクションは、すべてのファイルで同じセクションインデックスを持っています。
プライマリファイルと補助ファイルはいずれも同じセクションヘッダーを定義しますが、ほとんどのセクションのデータは、前述のように 1 つのファイルに書き込まれます。セクションのデータが特定のファイル内に存在しない場合は、SHF_SUNW_ABSENT セクションヘッダーフラグが設定され、sh_size フィールドは 0 になります。
この構成により、セクションヘッダーの完全なリスト、完全なシンボルテーブル、およびプライマリファイルと補助ファイルの完全なリストのすべてを 1 つのファイルの検査から取得することが可能になります。
dbx は次に、実行可能ファイルで補助ファイルを探すことにより、これらの補助ファイルを dbx が個別のデバッグファイルを使用するのと同様に使用できます。コンパイル時には、次のように –z ancillary オプションを使用します。
%CC -g -z ancillary=a.out demo.cpp //"a.out" contains the ancillary object
プライマリロードオブジェクトとそれに関連付けられたすべての補助ファイルには、すべてのロードオブジェクトを識別して関連付けることができる .SUNW_ancillary セクションが含まれています。
詳細については、Oracle Solaris 11.2 リンカーとライブラリガイド の第 2 章リンカーを参照してください。