は、私はちょうど今(5年)によってかなり古いですスタックトレースにファイル名と行番号を取得するためのポータブル/スタンダードに準拠した方法はありますか?
How to generate a stacktrace when my gcc C++ app crashes
を読みました。いくつかの答えは、スタックフレームごとに関数の名前とオフセット(私が推測するスタック内)を得ることを可能にする解決策を示唆しています。しかし、私が(そして他人が)実際に必要とするのは、呼び出しが行われたソースファイル名と行番号です(コードがデバッグ情報でコンパイルされていると仮定します)。これを行うglibcの一部にリンクされている答えの1つ(libSegfault; this directory - segfault.c
、backtracesyms.c
、のファイルを参照) - それで可能ですです。
私の質問は以下のとおりです。
- この情報は、プラットフォームに依存しない方法、またはいくつかの標準(POSIX ??)に準拠して1で抽出することができ
- はなぜこれをサポートしていませんlibunwindの? (I はwebsiteを見てと思っています)
- これは、コンパイラのC/C++標準ライブラリ(少なくともC/C++アプリケーションの場合)に依存しますか?
注:あなたがバイナリは、それが-g
でコンパイルされたC/C++の場合ので、デバッグ情報をしていると仮定して
- 。もちろん、適切なライブラリでは、デバッグ情報が利用可能かどうかをチェックします。
いいえ。標準的な方法はありません。 CやC++の言語標準やPOSIX標準では、それを行う方法が規定されていません。 Libunwindはおそらくあなたが得ることができるほどの移植可能性に近いです - 他にもいくつかの匹敵するライブラリがあるかもしれません。そして、はい、プラットフォームに依存します - o/sとコンパイラ。シグナルハンドラのスタックトレースは...面白いことがあります。 –
@JonathanLeffler:しかし、gdbは多くのプラットフォームでそれをやっていませんか? gccでコンパイルされていないバイナリに対しても? – einpoklum
はい、GDBには、プラットフォームによって異なる複雑なコードがあります。行って見てください - それは自明ではありません。これはプラットフォーム用に定義されたABIに対応し、デバッグモデル(Dwarf vs ...)、オブジェクトファイル(および実行可能ファイル)の形式(ELF vs COFF vs ...)などに依存します。 macOSで動作するものはWindowsでは動作せず、どちらもLinuxでは動作しません。それはlibunwindのような図書館が活躍する場です。 –