gdb:地址范围映射

| 我正在分析此核心转储
   Program received signal SIGABRT, Aborted.
    0xb7fff424 in __kernel_vsyscall ()
    (gdb) where
    #0  0xb7fff424 in __kernel_vsyscall ()
    #1  0x0050cd71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
    #2  0x0050e64a in abort () at abort.c:92
    #3  0x08083b3b in ?? ()
    #4  0x08095461 in ?? ()
    #5  0x0808bdea in ?? ()
    #6  0x0808c4e2 in ?? ()
    #7  0x080b683b in ?? ()
    #8  0x0805d845 in ?? ()
    #9  0x08083eb6 in ?? ()
    #10 0x08061402 in ?? ()
    #11 0x004f8cc6 in __libc_start_main (main=0x805f390, argc=15, ubp_av=0xbfffef64, init=0x825e220, fini=0x825e210, 
        rtld_fini=0x4cb220 <_dl_fini>, stack_end=0xbfffef5c) at libc-start.c:226
    #12 0x0804e5d1 in ?? ()
我不知道哪个功能which1 which映射到OR,例如
#10 0x08061402 in ?? ()
属于哪个地址范围... 请帮我调试一下。     
已邀请:
        您的程序没有调试符号。用
-g
重新编译。确保您没有剥离可执行文件,例如通过将
-s
传递给链接器。     
        即使@ user794080没这么说,他的程序也是32位linux可执行文件的可能性也很大。 (有两种可能的原因(我能想到))无法显示主要可执行文件中的符号(并且堆栈跟踪中[0x08040000,0x08100000范围内的所有符号都来自主要可执行文件)。 实际上,主要可执行文件已被剥离(这与 ninjalj's的答案),并且经常在\'-s \'传递给链接器时发生,可能是无意间。 该可执行文件已经使用新的GCC进行了编译,但是正在由旧的GDB进行调试,这会在某些较新的矮人结构上引起窒息(GDB应该对此发出警告)。     
        要知道哪些库已映射到应用程序中,请记录您的程序的pid,在gdb中停止并在其他控制台中运行
cat /proc/$pid/maps
$ pid是停止的进程的pid。在http://linux.die.net/man/5/proc中描述了地图文件的格式-从\“ / proc / [number] / maps开始 包含当前映射的内存区域及其访问权限的文件。“ 另外,如果您的操作系统不使用ASLR(地址空间布局随机化)或为程序禁用了该功能,则可以使用
ldd ./program
列出链接的库及其内存范围。但是,如果打开了ASLR,您将无法获得实际的内存映射范围信息,因为它会随着程序的每次运行而改变。但是即使那样,您仍然会知道,动态链接了哪些库并为其安装了debuginfo。     
        堆栈可能已损坏。如果堆栈上的返回地址已被(例如)缓冲区溢出所覆盖,则会发生\“ ?? \”。     

要回复问题请先登录注册