我有一个不是使用调试符号构建的可执行文件的核心转储.
我可以恢复argv内容,看看命令行是什么？
如果我运行gdb,我可以看到一个回溯,我可以导航到main()框架.有一次,有没有办法恢复argv,而不知道它的确切地址？
我在x86_x64(Intel Xeon cpu)上运行一个CEntOS Linux发行版/内核,
我有希望的一个原因是核心转储似乎显示了部分争议.
(程序是postgres,当我加载核心文件时,gdb打印一个消息,其中包含postgres数据库用户名,客户端OP地址和查询的前10个字符))
解决方法
在x86_64上,参数以％rdi,％rsi等寄存器(
calling convention)传递.
因此,当您进入主框架时,您应该能够：
(gdb) p $rdi # == argc (gdb) p (char**) $rsi # == argv (gdb) set $argv = (char**)$rsi (gdb) set $i = 0 (gdb) while $argv[$i] > print $argv[$i++] > end
不幸的是,当您切换帧时,GDB通常不会恢复$rdi和$rsi.所以这个例子不行：
cat t.c
#include <stdlib.h>
int bar() { abort(); }
int foo() { return bar(); }
int main()
{
foo();
return 0;
}
gcc t.c && ./a.out
Aborted (core dumped)
gdb -q ./a.out core
Core was generated by `./a.out'.
Program terminated with signal 6,Aborted.
#0 0x00007fdc8284aa75 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0 0x00007fdc8284aa75 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007fdc8284e5c0 in *__GI_abort () at abort.c:92
#2 0x000000000040052d in bar ()
#3 0x000000000040053b in foo ()
#4 0x000000000040054b in main ()
(gdb) fr 4
#4 0x000000000040054b in main ()
(gdb) p $rdi
$1 = 5524 ### clearly not the right value
所以你必须再工作一些…
您可以做的是使用知识如何在process startup设置Linux堆栈,结合GDB将恢复堆栈指针的事实：
(gdb) set backtrace past-main (gdb) bt #0 0x00007ffff7a8da75 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff7a915c0 in *__GI_abort () at abort.c:92 #2 0x000000000040052d in bar () #3 0x000000000040053b in foo () #4 0x0000000000400556 in main () #5 0x00007ffff7a78c4d in __libc_start_main (main=<optimized out>,argc=<optimized out>,ubp_av=<optimized out>,init=<optimized out>,fini=<optimized out>,rtld_fini=<optimized out>,stack_end=0x7fffffffdad8) at libc-start.c:226 #6 0x0000000000400469 in _start () (gdb) frame 6 (gdb) disas Dump of assembler code for function _start: 0x0000000000400440 <+0>: xor %ebp,%ebp 0x0000000000400442 <+2>: mov %rdx,%r9 0x0000000000400445 <+5>: pop %rsi 0x0000000000400446 <+6>: mov %rsp,%rdx 0x0000000000400449 <+9>: and $0xfffffffffffffff0,%rsp 0x000000000040044d <+13>: push %rax 0x000000000040044e <+14>: push %rsp 0x000000000040044f <+15>: mov $0x400560,%r8 0x0000000000400456 <+22>: mov $0x400570,%rcx 0x000000000040045d <+29>: mov $0x40053d,%rdi 0x0000000000400464 <+36>: callq 0x400428 <__libc_start_main@plt> => 0x0000000000400469 <+41>: hlt 0x000000000040046a <+42>: nop 0x000000000040046b <+43>: nop End of assembler dump.
所以现在我们预期原始的％rsp为$rsp 8(一个POP,两个PUSH),但是由于在指令0x0000000000400449中完成的对齐,它可能在$rsp 16
我们来看看有什么？
(gdb) x/8gx $rsp+8 0x7fffbe5d5e98: 0x000000000000001c 0x0000000000000004 0x7fffbe5d5ea8: 0x00007fffbe5d6eb8 0x00007fffbe5d6ec0 0x7fffbe5d5eb8: 0x00007fffbe5d6ec4 0x00007fffbe5d6ec8 0x7fffbe5d5ec8: 0x0000000000000000 0x00007fffbe5d6ecf
这看起来很有希望：4(怀疑argc),其次是4个非空指针,后跟NULL.
我们来看看是否平静下来：
(gdb) x/s 0x00007fffbe5d6eb8 0x7fffbe5d6eb8: "./a.out" (gdb) x/s 0x00007fffbe5d6ec0 0x7fffbe5d6ec0: "foo" (gdb) x/s 0x00007fffbe5d6ec4 0x7fffbe5d6ec4: "bar" (gdb) x/s 0x00007fffbe5d6ec8 0x7fffbe5d6ec8: "bazzzz"
的确,这就是我调用二进制文件的方式.作为最后的理智检查,0x00007fffbe5d6ecf看起来像环境的一部分？
(gdb) x/s 0x00007fffbe5d6f3f 0x7fffbe5d6f3f: "SSH_AGENT_PID=2874"
是的,这就是环境的开始(或结束).
所以你有它.
最终注意事项：如果GDB没有打印< optimize out>很多,我们可以从帧#5中恢复argc和argv.在GDB和GCC两方面都有工作,使GDB打印少得多的“优化出”…
另外,当加载核心时,我的GDB打印：
Core was generated by `./a.out foo bar bazzzz'.
否定了整个运动的需要.但是,这仅适用于短命令行,而上述解决方案将适用于任何命令行.
