如何获取GDB调用栈追踪？无可执行文件时能否用Core Dump调试？

嘿，我来帮你搞定这两个GDB的问题：

获取调用栈其实很简单，分几种场景操作：

• 如果正在用GDB调试运行中的程序（比如通过gdb ./your_app启动，再用run让程序跑起来），当程序触发断点或者崩溃暂停时，直接输入命令 bt（这是backtrace的简写，大家都爱用这个快捷命令），就能看到完整的调用栈——从当前卡住的函数一直回溯到程序入口main函数。
• 要是想同时查看每个栈帧里的局部变量细节，就用 bt full，这个命令会把每个栈帧的局部变量值也打出来，排查bug的时候特别有用。
• 遇到调用栈特别长的情况，只想看前N层？输入 bt N 就行，比如bt 3就只显示最上面的3层栈帧；反过来，想看最后N层的话，用 bt -N。
• 另外还有个info stack命令，和bt功能差不多，只是输出格式略有区别，你可以根据习惯选着用。

很可惜，做不到，你必须要有对应的原始可执行文件才行。原因其实很好理解：

• Core dump只是程序崩溃那一刻的内存快照，里面存的是当时的内存数据、寄存器状态这些运行时信息，并没有包含程序本身的代码，也没有地址到函数符号的映射关系。
• 调试信息文件（比如用objcopy分离出来的.debug文件）是和可执行文件一一对应的，它的作用是把内存地址翻译成函数名、行号，但这些地址是基于可执行文件的链接地址的。GDB需要可执行文件来把core dump里的运行时地址转换为调试信息里的链接地址，才能完成解析。
• 要是没了可执行文件，就算你有core dump和调试信息文件，GDB也没法把那些冰冷的内存地址和调试信息关联起来，最后只能看到一堆毫无意义的地址，根本出不来函数名和行号。

内容的提问来源于stack exchange，提问作者Eugene Panichkin