ここは gdb 初心者なので、明らかに明らかなことを見落としていないことを願っています… (見落としていたとしても、親切な人なら指摘してくれるのではないでしょうか? ;)
OS X Lion で GCC C++ アプリケーションをデバッグしています。STL が非常に重いため、コンテナーのプリティ プリントには、Python をサポートする (つまり、v7 以上の) GDB バージョンを使用したいと考えています。私のアプリケーションは、面倒な作業をすべて行うバックエンド ライブラリ (.dylib) と、非常に単純なフロントエンド アプリケーションに分割されています。すべてのソースとバイナリは共通のソース パスの下にあり、すべてがデバッグ シンボルを使用してコンパイルされています (-g と -ggdb の両方を試しました)。
XCode で GDB バージョン (「GNU gdb 6.3.50-20050815 (Apple バージョン gdb-1820)」として識別) を使用すると、フレームのソース行をバックトレースに表示することは、それぞれの呼び出しはフロントエンド アプリまたはバックエンド ライブラリで発生します。
(gdb) f12
#12 FL3D::Resource::createMesh_ の 0x000000010002ddc5 (this=0x7fff5fbff7c8, fl3d=@0x7fff5fbff1f8, id=) /Development/workspace/fl3d/libfl3d/resource.cpp:234
234 std::vector& t = textureIndices_.at(i);
(gdb)
ここまでは順調ですね。一方、GDB 7.5 および 7.4.1 は、ライブラリからソース行を提供することを拒否します。
(gdb) f12
#12 FL3D::Resource::createMesh_(FL3D::FL3DParser&, std::string) の 0x000000010002ddc5 () from /Development/workspace/fl3d/libfl3d/build/libfl3d.dylib
(gdb)
与えられたさまざまな応答に本当に混乱しています.gdb6はソースファイルへの正しいパスと正しい行を出力しますが、gdb7は関数プロトタイプを正しく取得します(おそらく.dylibのデバッグシンボルから読み取られますか?)が、そうではありませんソースについて何かを知っているようです。興味深いことに、フロントエンドの main() 関数の呼び出しに対応するソース行が表示されます!
「dir libfl3d」を使用して、ライブラリのソース ファイルへのパスを手動で設定しようとしましたが、何も変わりません。また、アプリケーションを実行すると、gdb6 は「共有ライブラリのシンボルを読み込んでいます」と何度か言いますが、gdb7 はそうではありませんが、両方のバージョンで正しく解決されているように見えるため、シンボルは問題ではないようです。
私はここで頭がいっぱいです。ポインタはありますか？