我们一般会使用rtems在source builder生成的工具链里面rtems自带的gdb，arm-rtems4.11-gdb用法跟arm-none-eabi-gdb是一样的。debug的方法可以参考这篇博客
https://blog.csdn.net/zhengyangliu123/article/details/54934719
但是debug依旧不顺利，进入debug过后总是卡死在semobtain.c的一个判断函数里面，更奇怪的是，这个判断函数里面也没有任何循环逻辑。
经过一个中午的乱找和迷茫，我突然发现一个问题，当我debug的时候，会输出.bss .data .text的下载地址，stm32的.text的下载地址都是0x08000000打头的，可是这次是从0x0打头，我决定查看map来看flash地址，可是惊奇地发现rtems居然不生成map文件！？一般只要我们在gcc后面加上相应的参数就行了，可是rtems的gcc是自己的写的，由于不是很清楚rtems这部分内容，所以也不知道怎么下手。这时我想到.text的地址是在链接文件里面写的，所以我们需要找到链接文件。一般链接文件都是ld结尾的，可是居然搜不出来！！什么鬼！链接文件这东西一定有的，我打开了bsp/arm/stm32f4下一个个目录寻找，最后找到了个很可能是的东西，linkcmds.stm32f4。打开一看，发现
MEMORY {
RAM_INT : ORIGIN = 0x20000000, LENGTH = 128k
ROM_INT : ORIGIN = 0x00000000, LENGTH = 1M
}ROM_INT地址居然是0x0！！！！！果断改成0x08000000，然后把整个rtems重新编译，然后进行debug，成功了！！！加了断点过后然后运行，果然停在了正确的位置上！这是正确时在gdb模式下load的结果，之前这个lma都是0x0打头的
这个bug我已经提交给rtems的开发者了，希望大家以后就不用改了。
ps：有些朋友可能会说，为什么地址错误这么大的错误别的人用的时候都没问题，是这样的，我们烧写的时候是用st-flash write 0x08000000 hello.bin，这里会写上地址，但是我们debug的过程，没有任何一个步骤写了地址，这时会从从exe文件中获取地址，是链接的时候写好的地址。而且网上也没人用stm32f4进入调试模式吧。