なぜ__builtin_return_address()
がARMの0以外の引数をサポートしないのか不思議です。 何とかARMのスタックから関数の呼び出し元アドレスを推測できないという問題がありますか? 他に何か?私の最愛のMIPS、唯一__builtin_return_address(0)
作品を含むいくつかのアーキテクチャ、上もGCCがARMアーキテクチャの呼び出し関数のアドレスを返す
おかげ
なぜ__builtin_return_address()
がARMの0以外の引数をサポートしないのか不思議です。 何とかARMのスタックから関数の呼び出し元アドレスを推測できないという問題がありますか? 他に何か?私の最愛のMIPS、唯一__builtin_return_address(0)
作品を含むいくつかのアーキテクチャ、上もGCCがARMアーキテクチャの呼び出し関数のアドレスを返す
おかげ
この記事によると< http://codingrelic.geekhold.com/2009/05/pre-mortem-backtracing.html>、
。 MIPSにはフレームポインタがないため、スタックを歩いて歩くのが難しくなります。フレーム0はリターンアドレスレジスタを直接使用できます。 ARMにもフレームポインタがない場合は、この制限が説明されます。
http://gcc.gnu.org/onlinedocs/gcc/Return-Address.htmlも参照してください。
ARMのバックトレースは、です。 Glibc backtrace
関数は最近は機能しますが、最新のコンパイラ/ glibcが必要です。また、すべてを-funwind-tablesでビルドする必要があります。 GDBはまた、デバッグ情報なしで問題を抱えています。
-funwind-tablesに言及してくれてありがとう!このコンパイラフラグを有効にするまでは、ARMのバックトレースは常に深さ1でした。 GCCの使用4.3.2。 – jfritz42
ARMでは、リターンアドレスはレジスタR14に渡され、別の関数を呼び出すときにそれを保存するのが、呼び出し先の義務です。したがって、フレームポインタを使用しても、戻りアドレスがスタックに格納されるという保証はありません。 –
実際、呼び出し命令によってスタックに保存されるのではなく、呼び出しアドレスが呼び出し先で保存されると、一般的に呼び出しアドレスを見つけることは不可能です。 dwarf2アンワインド/デバッギングデータを使用する方法があるはずですが、それは、__builtin_return_addressが、軽量のアンワインドライブラリ呼び出しではなく、簡単なビルトイン呼び出しである必要があります。 –
BTW、私はこのスタックトレース問題を[-finstrument-functions](http://gcc.activeventure.org/Code-Gen-Options.html)を使用して、すべての関数の入力/終了時に呼び出されます。もちろんオーバーヘッドはありますが、それは私には受け入れられます。 (そして、no_instrument_function'属性があり、最大の呼び出し速度が必要です...) –