x86 Linuxの場合、プロセスA.exeはdlopen()を呼び出して共有ライブラリB.soをロードします。 B.soには、dlopen()が呼び出される直前にプロセスA.exeのどの関数が中断されたのかを知りたいコンストラクタがあります。共有ライブラリのコンストラクタ(_initセクション)では、どの関数が中断されているかを知る方法は?
B.soのコンストラクタ(_initセクション)はどのように知っていますか?
x86 Linuxの場合、プロセスA.exeはdlopen()を呼び出して共有ライブラリB.soをロードします。 B.soには、dlopen()が呼び出される直前にプロセスA.exeのどの関数が中断されたのかを知りたいコンストラクタがあります。共有ライブラリのコンストラクタ(_initセクション)では、どの関数が中断されているかを知る方法は?
B.soのコンストラクタ(_initセクション)はどのように知っていますか?
私があなたの質問を正しく理解している場合、アプリケーションAにはdlopen()を呼び出す可能性のあるいくつかの場所があり、これらの場所から呼び出された場所を知りたいと思っています。
まず、共有ライブラリは、誰がそれをロードしているかについて何も想定してはならないため、間違っています。もしそうならば、Valgrindでアプリケーションを実行することはできません。この場合、Valgrindは標準のダイナミックリンカではなく読み込みを行い、結果が不正になる可能性があるからです。
第2に、これを実際に行う必要がある場合(なぜですか?)、コンストラクタ関数でバックトレースを取ることがあります。次に、dlopen()を見つけるまで上方を検索し、次に高いスタックフレームにdlopenという関数を見つけます。
EDIT:スタックトレース内のアドレスを関数にマップするには、関連するバイナリのデバッグ情報または関数アドレスをシンボル名にマップするその他の方法が必要です。
この回答は正しいが、詳細は間違っています。 Valgrindでプログラムを実行すると、VG *はプログラムの動作をかなり忠実にエミュレートします。特に、プロセス内でbacktrace()を実行すると、VGの有無にかかわらず同様の結果が得られます。また、デバッグ情報は、アドレスを関数にマップするために必要ではありません。シンボルテーブルで十分です。 –
申し訳ありませんが、シンボルテーブルとデバッグ情報が混在しています。 – BjoernD
これでどのような問題を解決しようとしていますか? –