[结题报告]”实现 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,如果有问题就再慢慢改吧



你可能感兴趣的:(开源夏令营)