arm-gdb单核系统级调试

arm-gdb单核系统级调试

此次arm-gdb单核系统级调试一共用了3周。

前一周是进行hostshell、wdb、rse、mdl这四个库的开发。感觉不温不火，缓步前行的状态。主要解决一些小问题：

1. 消息的收发在sysDebug库里，需要把它编译出来给其他库用。

2. 消息的传输也分大小端，wdb当时就是遇到了这个问题。

3. 补充了arm的内存检测。

4. mdl库中，删除了rtpspawn的调用，因为系统还没有实现rtp。

第二周则主要是进行sysDebug的开发，主要做了：

1. 删除了任务级调试和rtp调试

2. 新增了获取arm的寄存器信息

3. 屏蔽多核调试相关的核间中断以及原子操作

4. 确定刷写内存的问题

5. 确定bkpt为断定指令

6. 完成上下文转换，把任务上下文转换为调试上下文的接口。

7. 查看arm的硬件压栈

8. 在prjConfig中加入调试相关代码，链接工具库到os。

9. 编写异常处理函数。查看异常调用流程，现在是暂时挂接到_func_excBaseHook，判断如果是指令预取异常就进入异常处理函数。BKPT是软件断点指令，属于指令预取异常。

第三周，则是遇到了难点，断点不稳定，无法单步，最终在周五晚上解决了。

1. 同时打两个断点的原因，无法调试的原因终于找到了，原来是在gdb7.2的情况下如果打了两个断点，那么，当它跑到第二个断点处，会先执行s命令来跳过前面的断点，然后再打上所有断点，再次执行c命令，最后才听到第二个断点处。

2. 重新编译升级了gdb7.10，该版本gdb可以指定armv7-linux，之前版本gdb7.2单步时发的是s命令，但该armv7-coretex a9却是没有单步位，所以应当使用的方式是打断点模拟单步位。

3. 打断点来模拟单步位，那么gdb自动打的断点怎么跳过呢？原因是gdb自动打的断点，第二次是不会再打上去的，所以也就跳过啦。。。你可以注意一下，入口函数处的断点也是gdb自动打的。后面也从未出现过。

4. 另外，打断点不稳定的原因也终于找到了。。。之前一直怀疑是网络的原因。主要怀疑如下：网卡驱动必须支持轮询模式，网络协议栈速率，printf是中断模式，必须使用printk轮询。最后发现，在进入异常处理函数中，必须关中断，然后处理完后再开中断。