[结题报告]”实现 RT-Thread 上的 GDB stub“总结

项目介绍及完成情况

GDB Stub 是 GDB 在进行远程调试的时候，在目标机上运行的一套代码，而这个项目所做的，就是实现 RT-Thread 上的 GDB Stub，使RT-Thread支持GDB的Remote Debugging，用来在没有仿真器(JTAG)的情况下调 试RT-Thread 内核和应用程序。

如果有在MAC,LINUX下开发过MCU的经历的话，多半会对OpenOCD有印象，OpenOCD是一个开源的JTAG上位机程序，OpenOCD提供了GDB接口，一边响应GDB protocol，一边直接通过JTAG对MCU直接操作。而GDB Stub大部分代码其实都和OpenOCD共同，只不过GDB Stub操作MCU不需要通过JTAG访问，而是直接执行在MCU内部的代码。

GDB Stub的PC端调试方法就是GDB的调试方法，使用细节可以参考大部分GDB教程。在MCU端需要为GDB Stub指定Serial设备。

因为本项目实现在嵌入式平台下，所以实现的细节都非常依赖底层的硬件，不同于GDB Server，不依赖系统提供的API接口，在项目中，大致使用了两套实现方式。

1.使用软件模拟的办法，实现设置断点，单步的功能。

2.依赖体系提供的寄存器，实现断点，单步。

代码也主要分两个部分。

1.GDB协议的处理。

2.功能实现细节。

当移植到不同平台的时候，只需要为该平台重写功能实现部分的代码就可以了，由于平台的差异过大，也没有做严格的特定的接口，怎么能跑怎么来把。

更多注意事项和具体代码分析在之前的报告都有所讲述。

个人感想总结

之前一直对嵌入式系统的调试细节很不理解，对我来说，调试MCU就是用JLINK，在IDE操作几个BUTTON，监视几个窗口而已，现在对调试有了更深的理解，对ARM有了更清楚的认识。还有就是文档阅读吧，之前开发MCU，最多也就是看user manual，写Stub让我很认真的看了ARM公司的文档，受益匪浅。

这次夏令营，是我第一次接触开源开发，也是第一次开发component的体验，总之，对我是一场很宝贵的经历吧，感谢导师给我的这次机会，也感谢CSDN提供的平台，谢谢~

遗留问题

1.软件实现的ARM版本没有对THUMB做支持，所以跑到THUMB的时候，执行STEP会不太正常。。

2.Cortex-M版本在跑的过程中，GDB可能会多次询问0xdeadbeaf的地址，若直接访问会导致HARD HALT，如果禁止其访问，有时候GDB会卡死，初步认定0xdeadbeaf是R3以上等寄存器未使用时初始值，GDB可能误认为是有用数据的地址。

关于合并

= =没什么经验。。。。如果导师测试没问题，就提交pull，如果有问题就再慢慢改吧