問題タブ [libunwind]

プログラムのある時点でスタック トレースを作成します。libcのbacktrace_symbols()関数で 1 回、libunwindunw_get_proc_name()から1 回。

backtrace_symbols() 出力:

unw_get_proc_name() の出力:

ここでは、命令ポインタアドレス (0x7f6b47ce9004) が同じで正しいことがわかります。backtrace_symbols()0x97004からの関数オフセットも正しいですが、 unw_get_proc_name()から取得したものではありません( )。0x458e4

誰かがここで何が起こっているのか、オフセットにこの違いが生じる原因を知っていますか?

どちらの方法も、次の例のような類似のコードを使用します。

バックトレース():

libunwind:

一連のシンボルとオブジェクトを含む .a ファイルがあります。セクションがあります

セクション全体を削除するには、どの binutil ツールを使用できますか?

以前の質問で、親プロセスから子プロセスのスタック トレースをプログラムで取得できるかどうかを確認しようとしていました。

成功しましたが、別の疑問が頭に浮かびました。プログラムの実行中にこれらのフレームを直接調べても安全ですか? ここでは、「子のスタックの値を変更しない」という意味で「安全」と定義しています。

たとえば、NPB-Serial CG Class A ベンチマークを実行して得たスタック トレースの例を次に示します。

各スタック ポインター エントリの値をコピーして、スタックのダンプを取得したいと考えています。たとえば、0x7ffe5e368e10そのアドレスから現在のスタック ポインターまでのすべての値を別の場所にコピーします。

これを行うリスクはありますか？それとも、これについて間違って考えていますか (これを行う簡単な方法があるように)?

セグメンテーション違反が原因でアプリケーションがクラッシュするという問題がある C++ アプリケーション (デーモン) を作成しました。

クラッシュが発生したコードに関する情報を取得するには、libunwind を使用します。これは、x86_x64 Linux システムで非常にうまく機能します。そこで私は素晴らしいスタックトレースを取得します。しかし、ARMアーキテクチャでは、スタックトレースは「デーモンコード」自体までのスタックのみで構成され、使用する共有ライブラリには含まれません

gcc 4.9 を使用しています (arm arm-linux-gnueabihf-g++4.9 用)。ライブラリとデーモンをデバッグ モード (-g) でビルドし、次のパラメータを使用してスタック トレース用のテーブルを取得します。

共有ライブラリに使用するリンカー用

x86 のサンプル スタック トレースは次のとおりです。

そしてここにアームデバイスからのトレースがあります。共有ライブラリのスタック情報がないようです?!

以下は、シグナル ハンドラから呼び出されるスタック トレースを構築するためのコードの概要です。

そして、ここにデーモン自体の要約があります:

私がいくつかのコンパイラフラグを逃したかどうかは誰にも分かりますか? 何か不足していますか？多くの投稿を見つけましたが、すべて言及されたコンパイラ フラグまたは libunwind を参照しています。見つけた他のいくつかのコードを試しましたが、スタックの深さは 1 しかありません ありがとう!

編集 11.11.2016:
テストのために、共有ライブラリの代わりに静的ライブラリを構築してアプリケーションに追加したため、動的リンクはもうありません。残念ながら、スタック トレースは同じ悪いものです。

私は親指モードですべてのものをコンパイルしようとし、アームコンパイラをgcc5/g++5に変更しました

同じ問題:-(