5

gdbを使用してlibtoolでビルドされたパッケージのテストプログラムをデバッグしようとすると、奇妙な問題が発生します。実行libtool --mode=execute gdb .libs/libfoo.soして関数のソースをリストするように依頼するとlist Bar::Baz、期待どおりにソースコードが取得されます。を実行するlibtool --mode=execute gdb binaryと、侵入しBar::Baz()てスタックトレースでその引数を確認できますが、次のようにソースファイルまたは行番号を取得できません。

#7  0x018348e5 in Bar::Baz(Qux*, Quux*) () from /path/to/libfoo.so
                           ^^^^^^^^^^^ <--- debug symbols are present!

同様にlist Bar::Baz、実行可能ファイルをデバッグしようとすると、次のようになります。

No line number known for 'Bar::Baz'.

バイナリがとリンクされていることを確認し、-gその機能を一覧表示できるmainので、デバッグ情報の一部が存在することがわかります。

と言うとinfo sources、ライブラリが構築されているファイルの完全なリストと、正しい絶対パスが表示されます。と言うとinfo shared、オブジェクトファイルへの正しいパスがリストさYesれ、Syms列にが表示されます。

何がうまくいかない可能性があり、それを修正する方法についてのさらなるアイデアはありますか？

編集1：誤っobjdump -gて、問題のあるライブラリを実行し、次の出力を取得しました。

/path/to/foo.so.0.0.0: file format elf32-i386
objdump: /path/to/foo.so.0.0.0: no recognized debugging information

objdump -h（私が実行しようとしたもの）にはたくさんの.debug_*セクションがリストされているので、これは驚くべきことです。objdumpマニュアルreadelf -wも同様に示唆しており、それは膨大な情報の山を印刷しているようです。ただし、実際に何が提供されるかを確認する必要があります。

編集2：それで、readelf -wいくつかの悟りを生み出しました。何らかの理由で、共有オブジェクトファイルには、リンクされているオブジェクトの大部分 からのデバッグ情報が含まれていないようです。Makefilesに基づいて、オブジェクトを共有ライブラリに実際に収集するコマンドが渡されず、情報が適切に伝播されない可能性があります。面白いことに、これは（現在のx86に対して）x86_64の同じコンパイラバージョンを含む、他のすべての構成で機能します（完全なデバッグ情報があります）。-g

編集3：実際には、LDFLAGSに-gが追加された変更されたMakefileを使用して完全に再構築されましたが、違いはありませんでした。今、私は元気で本当に困惑しています。

4

3 に答える 3

5

This is an answer to an old question, but your problem matched mine, but none of the solutions worked. Here is what worked for me.

Change CFLAGS -g to "-g -gstabs".

objdump was not recognizing the dwarf style debug information. -gstabs changes this format to one that works with objdump -g and objdump -S and my debugger.

Hope it helps.

NOTE: For me, I was building a linux kernel. This change was make in the linux kernel's Makefile.

于 2011-11-04T16:03:08.660 に答える
3

混乱の最初のポイント:デバッグシンボルが存在することを意味するものではありません(実際には、それらが存在しないことを意味Bar::Baz(Qux*, Quux*)します)。

デバッガーは関数名を分解するだけです。デバッグ シンボルが実際に存在する場合は、Bar::Baz(Qux* qux = 0x12..., Quux* quux = 0x234...)

本当の問題に関しては、シンボルが他のライブラリで定義されているのではないかと思います。

  • do の前にバイナリのリンク行に表示されlibfoo.so、
  • デバッグ シンボルなしでビルドされた

(ランタイムローダーは参照をBar::Baz()最初に見つけた定義にバインドします。)

ipフレーム #7 で印刷する場合info symbol <value-just-printed>は、「Aha!」が表示されると思います。一瞬。

編集:あなたの更新により、質問が自己矛盾しました。AFAICT、

  1. gdb実行時にデバッグシンボルを見ることができます
    libtool --mode=execute gdb .libs/libfoo.so
  2. しかし、あなたが実行するときではありませんlibtool --mode=execute gdb binary
  3. シンボル定義がまったく同じものから来ていることを確認しました .libs/libfoo.o
  4. デバッグシンボルが表示されreadelf -wません.libs/libfoo.o

上記のステートメントの少なくとも 1 つが誤りである可能性があります。

もしそれらがすべて本当なら、あなたはおそらく奇妙なバグを抱えているでしょうGDB ( readelf一方にバグが発生する可能性はありますが、両方に同時にバグが発生する可能性はほとんどありません)。

-gまた、に追加することLDFLAGSは一般的に間違っていることにも注意してください。CXXFLAGS代わりに追加するつもりでしたか？

于 2011-07-21T03:07:14.530 に答える
0

show language問題が発生したときにの出力がどうなるか疑問に思いました。そうでない場合はc++、おそらくset language c++必要ですか？

于 2011-07-31T13:25:02.793 に答える