利用BDI实现GDB调试

BDI本身提供的命令还是比较有限的，从调试的角度来看的话，也就是可以知道当前的PC指针和对应的核寄存器，无法实现任何高级的功能。因此利用GDB提供的remote功能实现硬件GDB调试，几乎是实际调试的必然之选。

笔者是用BDI调试uboot的一部分功能(fwupdate我们自己写的一个固件升级程序)，历经坎坷，总算摸到了点门道。以下分享一下这个的关键过程。

1.启动

在完成正常烧写后，硬件应该可以直接启动到u-boot命令行的。那么在通过JTAG连接上BDI后，还能这样做吗？ 能，当然能，关键是在BDI的配置文件中，STARTUP要设置为RUN，而不能是RESET。这里，RUN对应的是不影响硬件本身的启动，RESET则是通过JTAG直接复位芯片，并用配置文件中的[INIT]部分作初始化。

2. 断点类型

在配置文件中还有一个关键点是断点类型BREAKMODE，BDI支持HARD和SOFT两种，硬件断点HARD的资源比较有限，ARM9仅仅才2个。软件断点就比较自由了，想设多少随意。大部分情况下面，我们只需要用软件断点就可以了。只有极少数情况，如程序在NAND flash中执行时，才需要使用硬件断点。还有一点，除了程序断点，BDI也同样支持设定数据断点，本来以为数据断点必须用硬件断点，但后来尝试下来发现好像软件断点也是可以的。

3.设置断点

BDI的命令集中已经包含了设置断点的命令，bi设置程序断点，bd设置数据断点。有一点非常重要，在设定断点时，尤其是数据断点时，必须要根据实际的访问方式来设定断点。例如，笔者用bd设置了一个数据断点，但是却从来都不在断点停下来，后来发现，是因为bd设定的是4个字节的数据断点，而程序却是以一个字节一个字节访问这段内存的，后来改成相应的命令：

bdb r 0x827e0000

也就是以单字节访问的方式设置数据断点，然后还是在发生读取这个数据时中断。

还有一个更重要的，断点设置必须在CPU停下来的时候才会起效，否则，即便表面上设置好了而且也没报错，但在跑的过程中却始终不会在断点中断的。这点其实很好理解，一个程序在跑，当然无法随意的去更新它的中断点，只有在暂停才有可能设中断点嘛。但是因为u-boot在命令提示下，很容易让人觉得目前本来就停止在那边，从而直接去BDI侧设置断点了。

暂停程序执行和恢复程序执行的命令分别是halt和go。在设完断点后并go后，当进入断点时，会在BDI侧出现提示说进到断点了。

4.GDB与BDI的连接

由于纯命令行的gdb调试起来不易使用，我们可以采用图形界面的gdb工具DDD。启动ddd的方式为

ddd --debugger arm_v5t_le-gdb uboot

其中--debugger后面跟的就是交叉gdb命令，uboot是带符号表的程序，是uboot.bin的4倍大小。在笔者的系统中由于所使用的编译器是mvista5的，而编译器命令中独独缺少这个arm_v5t_le-gdb，所以后来只能用mvista4l里面的arm_v5t_le-gdb代替，但是，这样做了以后，发现符号表和PC指针似乎总是对不上，所以，后来干脆连uboot的源代码都用mvista4的arm gcc编译了。启动后会出现图形界面，然后在控制台窗口中，你需要输入:

target remote 192.168.1.33:2001

其中，IP就是BDI的IP地址，后面的2001是固定端口。

这个命令可以被多次输入，在每次输入后她都会通过BDI重新去取新的PC地址以便正确的显示。

正常情况下，当输入此命令后，如果程序此时正处于断点下的话，就会load到断点对应的C代码位置，然后你就可以用ddd提供的图形界面调试拉。