私はクロスコンパイル環境で gdb を使用しており、多くの共有ライブラリを含むターゲット アーキテクチャ用の Linux ツリーを構築しています。
問題:コア ダンプを分析すると、gdb は .so ファイルとそのシンボルへのパスを見つけますが、ソース ファイルは見つけません。
ホストのセットアップ:
tree/<-- ルートを構築
tree/apps/myapp/myapp<--クラッシュするアプリ
tree/libs/mysharedlib/<-- 共有ライブラリはこのようなパスから構築され、target/ にインストールされます
tree/target/ <-- ターゲット ビルド ルート
tree/target/usr/bin/<-- クラッシュするバイナリがここに入る
tree/target/lib<-- いくつかの .so:s
tree/target/usr/lib<-- いくつかの .so:s
出力例:
...
#9 0x2b038cfc in start_thread (arg=0x32dff4d0) at pthread_create.c:302
302 pthread_create.c: No such file or directory.
in pthread_create.c
...
gdb はデフォルトでソースファイルを検索する場所をどのように認識していますか?
gdb で 'directory' コマンドを使用してソース ディレクトリを手動で指定できることはわかっていますが、それは機能しますが、すべての共有ライブラリに対してそれを行いたくありません。すべてのものが構築されたルートを設定したいと思います。gdbserver を使用してライブ デバッグを行うと、gdb はすべての共有ライブラリのソースを自動的に検出するため、コア ファイルについても同じ動作が必要です。
バイナリのデバッグ情報で指定されているのは .c ファイル名だけですか、それともパスもありますか? 相対的か絶対か？