0

私のgdbbtコールスタックは、関数名に関数アドレスを付けます。次にnm binary 、関数名とアドレスのマッピングを実行して生成しました。gdb アドレスとnm出力を一致させようとしたところ、一致しませんでした。関数のアドレス(gdb) btが高すぎる (物理アドレスのように見える)。

gdb 関数アドレス (例0x00007fffe6fc150f):

#9  0x00007fffe6fc150f in read_alias_file (fname=<value optimized out>, fname_len=<value optimized out>) at localealias.c:224
#10 0x00007fffe6fc1a4e in _nl_expand_alias (name=0x7fffffffed04 "en_IN") at localealias.c:189
#11 0x00007fffe6fbb62f in _nl_find_locale (locale_path=0x7fffe70df580 "/usr/lib/locale", locale_path_len=16, category=12, name=0x7fffffffdb90) at findlocale.c:119
#12 0x00007fffe6fbacf6 in *__GI_setlocale (catesagory=12, locale=<value optimized out>) at setlocale.c:303
#13 0x00007ffff17b8686 in

しかし、nm取得したバイナリからアドレスを実行すると、次のようになります

0000000005ddda04 t StubGLBindFragDataLocationIndexed
0000000005ddda3f t StubGLBindFramebuffer
0000000005ddda65 t StubGLBindRenderbuffer
0000000005ddda8b t StubGLBindTexture
0000000005dddab1 t StubGLBlendColor
0000000005dddaef t StubGLBlendFunc
0000000005dddb15 t StubGLBlitFramebuffer
0000000005dddb7e t StubGLBufferData
0000000005dddbbd t StubGLBufferSubData
0000000005dddc00 t StubGLCheckFramebufferStatus
0000000005dddc1e t StubGLClear
0000000005dddc3c t StubGLClearColor
0000000005dddc7a t StubGLClearStencil
0000000005dddc98 t StubGLColorMask
0000000005dddcda t StubGLCompileShader

マシンは 64 ビットです。

私が知っているように、gdb は仮想アドレスのみを表示します。しかし、なぜそれが非常に高くなり、アドレスの現在のnm出力と一致しないのかわかりません

gdb アドレスは仮想アドレスですか??。nmo/p は 000000000 から始まるため、実際の仮想アドレスのように見えます。しかし、なぜベースアドレスが自動的に追加されるのでしょうか?

注：サンプルtest.outで試しました。それはうまくいきます。コールスタック アドレスは仮想アドレスであり、シンボル出力btと完全に一致します。nm a.out

4

1 に答える 1

2

0x00007fffe6fc150fアドレスは共有ライブラリからのものです (このlibc.so.6場合)。これは仮想アドレスですが、実行ごとに異なる特定のロードアドレスにライブラリがロードされるため、出力と一致しません。nm /lib/libc.so.6

GDB コマンドを実行すると、いつlibc.so.6ロードされたかがわかります。info proc mapのロードアドレスがわかったらlibc.so.6、それを出力のすべてのアドレスに追加するnmと、結果はGDB 出力と一致します。

これが単純に機能した理由a.outは、(共有ライブラリとは異なり)a.outリンクされて固定ロード アドレス (通常0x400000は Linux x86_64 上) にロードされ、ダイナミック ローダーによって再配置されないためです。

于 2012-05-08T03:35:48.447 に答える