0

に取り組んでいRHEL WS 4.5ます。

このシステムに一致する glibc ソース rpm を取得し、それを開いて rpm2cpio を使用して内容を取得しました。

そのツリーで作業して、mtrace.c へのパッチを作成し (スタック バックトレース レベルをさらに追加したい)、スペック ファイルに組み込み、debuginfo rpm を含む新しい一連の RPM を作成しました。

これらすべてをテスト vm (同じ RH ベース イメージから作成) にインストールし、変更が含まれていることを確認できました。

しかし、より複雑な実行では、mtrace.c でクラッシュします...しかし、gdb はデバッグ情報を見つけることができないため、行番号情報を取得できず、実際に失敗をデバッグできません。

日付から、/usr/src/debug/glibc-2.3.6/ のテスト システムにデバッグ情報がインストールされていることを確認できると思います。

sharedlibrary libc* gdb で試し たところ、シンボルが既に読み込まれていることがわかりました。

私のテストには、ローカルでビルドされた python が含まれており、python の完全なシンボルが見つかりました。

私の感覚では、デバッグを有効にして rpmbuild の下で glibc がビルドされていない可能性があります。私はglibc.specファイルを見直し、さらにビルドしました

_enable_debug_packages

結果に影響を与える可能性があるように見える 1 として定義されます。rpmbuild のビルド ステップで呼び出された構成スクリプトを確認しても、何のヒントも得られませんでした。

うーん.. /usr/lib/debug/lib/libc-2.3.4.so.debug と /usr/lib/debug/lib/tls/i486/libc-2.3.4.so.debug を見つけましたが、これらは両方ともfile コマンドによって削除されたと報告されます。

4

2 に答える 2

0

のデバッグ情報mtrace.cが実際に存在することを確認してください。最初に、GLIBC の個別のデバッグ情報が というコンパイル ユニットを認識しているかどうかを確認しますmtrace.c

$ eu-readelf -w /usr/lib/debug/lib64/libc-2.15.so.debug  > t
$ grep mtrace t
           name                 (strp) "mtrace.c"
             name                 (strp) "mtrace"
 1     0     0         0         mtrace.c
 [10480]  "mtrace.c"
 [104bb]  "mtrace"
 [5052] symbol: mtrace, CUs: 446

次に、GDB が実際に glibc-debuginfo RPM からソース ファイルを見つけるかどうかを確認します。

(gdb) set pagination off
(gdb) start # pause your test program right after main()
(gdb) set logging on
Copying output to gdb.txt.
(gdb) info sources

GDB を終了し、gdb.txt で mtrace を grep すると、次のようなものが見つかるはずです。/usr/src/debug/glibc-2.15-a316c1f/malloc/mtrace.c

これは GDB 7.4 で動作します。RHEL 4.5 に同梱されている GDB バージョンが、上記で使用したすべてのコマンドをサポートするかどうかはわかりません。ただし、ソースから上流の GDB を構築することは、実際には Python よりも簡単です。

strack トレースを mtrace に追加しようとするときmalloc()は、GLIBC の malloc フックで直接的または間接的に呼び出さないようにしてください。

于 2012-11-03T09:46:42.143 に答える
0

一致しない RPM をインストールしているようです:

/usr/src/debug/glibc-2.3.6
で /usr/lib/debug/lib/libc-2.3.4.so.debug が見つかりました

同じバージョンはありません。それらが同じ -debuginfo RPM から来たということはありません。

これらは両方とも、file コマンドによって取り除かれたと報告されます。

これらはストリップとして表示されるべきではありません。それらが正しく構築されていないか、あなたstripが壊れています。

また、問題をデバッグするために、実際にこれらすべてを機能させる必要はないことに注意してください。ディレクトリで、RPMBUILDfull-debug を使用して glibc ビルド ディレクトリを見つけることができるはずですlibc.so.6debuginfoそのライブラリを VM にコピーするだけで、 RPMについて心配する必要はありません。

于 2012-10-31T05:12:11.187 に答える