5.2. Debuginfo パッケージのインストール
Red Hat Enterprise Linux は、オペレーティングシステムに含まれるアーキテクチャー依存の RPM 用の
-debuginfo パッケージも提供します。packagename-debuginfo-version-release.architecture.rpm パッケージには、パッケージソースファイルと最終的なインストール済みバイナリの関係についての詳細情報が含まれます。debuginfo パッケージには両方の .debug ファイルが含まれ、これらには DWARF debuginfo とバイナリパッケージのコンパイルに使用されるソースファイルが含まれます。
注記
debuginfo と同等の情報がインストールされていない場合にパッケージのデバッグを試行しても、デバッガー機能のほとんどは機能しません。例えば、エクスポートされた共有ライブラリー関数の名前は利用可能ですがが、これらに一致するソースファイル行は debuginfo パッケージがインストールされていないと使用できません。
お使いのプログラムに
gcc コンパイルオプション -g を使用してください。デバッグのエクスペリエンスは、最適化 (-O2 などの gcc オプション -O) が -g と一緒に適用される場合に向上します。
Red Hat Enterprise Linux 6 では、debuginfo パッケージが Red Hat Network の新規チャンネルで利用できるようになりました。パッケージ (通常は
packagename-debuginfo) の -debuginfo パッケージをインストールするには、まずマシンが対応する Debuginfo チャンネルをサブスクライブする必要があります。例えば、Red Hat Enterprise Server 6 の場合、対応するチャンネルは Red Hat Enterprise Linux Server Debuginfo (v. 6) になります。
Red Hat Enterprise Linux システムパッケージは、最適化 (gcc オプション
-O2) でコンパイルされています。これは、いくつかの変数が <optimized out> と表示されることを意味します。コードのステップスルーによる多少の「ジャンプ」がありますが、クラッシュを分析することができます。最適化のために一部の情報が欠落する場合、コードを逆アセンブルし、ソースに手動で一致させることにより、正しい変数情報を得ることができます。ただし、これは例外ケースにのみ適用され、通常のデバッグには適していません。
システムパッケージの場合、GDB はその機能を制限する debuginfo パッケージの欠落があるかどうかをユーザーに通知します。
gdb ls [...] Reading symbols from /bin/ls...(no debugging symbols found)...done. Missing separate debuginfos, use: debuginfo-install coreutils-8.4-16.el6.x86_64 (gdb) q
デバッグされるシステムパッケージが既知である場合、上記の GDB で提案されるコマンドを使用します。これにより、packagename が依存するすべてのデバッグパッケージが自動的にインストールされます。
# debuginfo-install packagename
5.2.1. コアファイル解析用の Debuginfo パッケージのインストール
コアファイルは、プロセスのクラッシュ時のメモリーイメージを表すものです。システムプログラムのクラッシュをバグ報告する場合、Red Hat では 『Red Hat 導入ガイド』の『自動バグ報告ツール』の章で説明されている ABRT ツールの使用を推奨しています。ABRT が目的に適さない場合のために、ABRT で自動化されるステップを以下に説明します。
プロセスのクラッシュ時に
ulimit -c unlimited 設定が使用される場合、コアファイルは現在のディレクトリーにダンプされます。コアファイルには、プロセスによってディスクファイルの元の状態から修正されたメモリ領域のみが含まれます。クラッシュの完全な解析を実行するには、コアファイルに以下が含まれている必要があります。
- コアファイル自体
/usr/sbin/sendmailなどのクラッシュした実行可能バイナリー- クラッシュ時にバイナリーでロードされたすべての共有ライブラリー
- 実行可能ファイルおよびそのロードされたすべてのライブラリー用の .debug ファイルおよびソースファイル (どちらも debuginfo RPM に保存されている)
適切な解析を行うには、関係するすべての RPM 用の正確な
version-release.architecture か、または独自にコンパイルしたバイナリーの同じビルドが必要になります。クラッシュ時に、アプリケーションがすでにディスク上の yum によって再コンパイルされているか、または更新されている場合、コアファイルの解析に適してないファイルのレンダリングが行われます。
コアファイルには、関連するすべてのバイナリーの build-id が含まれます。build-id についての詳細は、「build-id バイナリーの一意の ID」 を参照してください。コアファイルのコンテンツは以下のように表示されます。
$ eu-unstrip -n --core=./core.9814 0x400000+0x207000 2818b2009547f780a5639c904cded443e564973e@0x400284 /bin/sleep /usr/lib/debug/bin/sleep.debug [exe] 0x7fff26fff000+0x1000 1e2a683b7d877576970e4275d41a6aaec280795e@0x7fff26fff340 . - linux-vdso.so.1 0x35e7e00000+0x3b6000 374add1ead31ccb449779bc7ee7877de3377e5ad@0x35e7e00280 /lib64/libc-2.14.90.so /usr/lib/debug/lib64/libc-2.14.90.so.debug libc.so.6 0x35e7a00000+0x224000 3ed9e61c2b7e707ce244816335776afa2ad0307d@0x35e7a001d8 /lib64/ld-2.14.90.so /usr/lib/debug/lib64/ld-2.14.90.so.debug ld-linux-x86-64.so.2
各行に含まれるそれぞれの列の意味は以下のようになります。
- 特定のバイナリーがマップされるメモリー内アドレス (たとえば、最初の行の
0x400000)。 - バイナリーのサイズ (たとえば、最初の行の
+0x207000)。 - バイナリーの 160-bit SHA-1 build-id (たとえば、最初の行の
2818b2009547f780a5639c904cded443e564973e)。 - build-id バイトが保存されていたメモリ内アドレス (たとえば、最初の行の
@0x400284)。 - ディスク上のバイナリーファイル (ある場合)(たとえば、最初の行の
/bin/sleep)。これは、このモジュールのeu-unstripで検索されました。 - ディスク上の debuginfo ファイル (ある場合)(たとえば、
/usr/lib/debug/bin/sleep.debug)。ただし、バイナリーファイル参照を代わりに使用するのがベストプラクティスになります。 - コアファイルの共有ライブラリーリストに保存される共有ライブラリー名 (たとえば、3 行目の
libc.so.6)。
それぞれの build-id (例えば、
ab/cdef0123456789012345678901234567890123) では、シンボリックリンクがその debuginfo RPM に組み込まれます。上記の /bin/sleep 実行可能ファイルを例にすると、coreutils-debuginfo RPM には、他のファイルの中でもとりわけ以下が含まれます。
lrwxrwxrwx 1 root root 24 Nov 29 17:07 /usr/lib/debug/.build-id/28/18b2009547f780a5639c904cded443e564973e -> ../../../../../bin/sleep* lrwxrwxrwx 1 root root 21 Nov 29 17:07 /usr/lib/debug/.build-id/28/18b2009547f780a5639c904cded443e564973e.debug -> ../../bin/sleep.debug
ケースによっては (コアファイルのロードなど)、GDB は、
name-debuginfo-version-release.rpm パッケージ の名前、バージョンまたはリリースを認識しません。このような場合に、GDB は異なるコマンドを提案します。
gdb -c ./core [...] Missing separate debuginfo for the main executable filename Try: yum --disablerepo='*' --enablerepo='*debug*' install /usr/lib/debug/.build-id/ef/dd0b5e69b0742fa5e5bad0771df4d1df2459d1
バイナリーパッケージ packagename-debuginfo-version-release.architecture.rpm の version-release.architecture は完全一致である必要があります。それが異なる場合、GDB は debuginfo パッケージを使用することができません。異なるビルドの同じ version-release.architecture であっても、debuginfo パッケージの互換性がなくなる可能性があります。GDB が debuginfo が不足していることを報告する場合は、以下を必ず再チェックしてください。
rpm -q packagename packagename-debuginfo- version-release.architecture 定義が一致する必要があります。
rpm -V packagename packagename-debuginfo- このコマンドは、packagename などの修正された可能性のある設定ファイルを除いて一切の出力を行いません。
rpm -qi packagename packagename-debuginfo- version-release.architecture は、Vendor、Build Date、および Build Host が一致する情報を表示する必要があります。Red Hat Enterprise Linux RPM パッケージ用の CentOS debuginfo RPM を使用しても機能しません。
必要な build-id が既知である場合、以下のコマンドはどの RPM にそれが含まれるかを照会します。
$ repoquery --disablerepo='*' --enablerepo='*-debug*' -qf /usr/lib/debug/.build-id/ef/dd0b5e69b0742fa5e5bad0771df4d1df2459d1
たとえば、コアファイルに一致する実行可能ファイルのバージョンは、以下でインストールできます。
# yum --enablerepo='*-debug*' install $(eu-unstrip -n --core=./core.9814 | sed -e 's#^[^ ]* \(..\)\([^@ ]*\).*$#/usr/lib/debug/.build-id/\1/\2#p' -e 's/$/.debug/')
バイナリーが RPM にパッケージされておらず、yum リポジトリーに保存されていない場合は同様のメソッドを使用することができます。
/usr/bin/createrepo を使用し、カスタムアプリケーションビルドでローカルリポジトリーを作成することができます。
