core调试

1. 前言:
有的程序可以通过编译, 但在运行时会出现Segment fault(段错误). 这通常都是指针错误引起的.
但这不像编译错误一样会提示到文件->行, 而是没有任何信息, 使得我们的调试变得困难起来.


2. gdb:
有一种办法是, 我们用gdb的step, 一步一步寻找. 
这放在短小的代码中是可行的, 但要让你step一个上万行的代码, 我想你会从此厌恶程序员这个名字, 而把他叫做调试员.
我们还有更好的办法, 这就是core file.


3. ulimit:
如果想让系统在信号中断造成的错误时产生core文件, 我们需要在shell中按如下设置:
#设置core大小为无限
ulimit -c unlimited
#设置文件大小为无限
ulimit unlimited


这些需要有root权限, 在ubuntu下每次重新打开中断都需要重新输入上面的第一条命令, 来设置core大小为无限.


4. 用gdb查看core文件:
下面我们可以在发生运行时信号引起的错误时发生core dump了.
发生core dump之后, 用gdb进行查看core文件的内容, 以定位文件中引发core dump的行.
gdb [exec file] [core file]
如:
gdb ./test test.core
在进入gdb后, 用bt命令查看backtrace以检查发生程序运行到哪里, 来定位core dump的文件->行


MIPS系统 core dump 调试
用gdb打开core dump文件：gdb application coredump
bt命令可以显示出完整的调用栈，当然，因为gdb本身不够完善，调用栈有可能是错误的，这个时候就需要自己跟踪寄存器和反汇编的方法来完成这件事情了。
info register可以查看coredump记录下来的寄存器值
其中pc寄存器就是当前的指令指针，也就是说，在执行PC指向的指令时，程序crash了。
info symbol pc 就可以查看当前指令在哪个符号（哪个函数）。
disassemble pc 就可以查看当前指令所在的函数。
gdb就在这步上可能出错，因为它的反汇编不是很成熟，所以可能把一片函数连在一起。
这就需要直接将编译出来的程序进行object dump来查看编译结果，从这里找到指令指针，从而找到当前指令，也就知道了当前指令所在的函数。
object dump 可以使用objdump程序来完成。
如果要查看调用栈的上层，gdb的up命令来切换到调用当前函数前的寄存器状态，这样通过分析pc就能得出上层调用函数了。
以此类推，完整的调用栈就出来了。

可以用gdb的down命令来执行与up想反的寄存器状态切换。