【无标题】手机中转电脑

http://123.56.87.34:18080/api/gb_record/query/10000007091327102626/10000007091327102626?startTime=2024-02-26%2017:19:40&endTime=2024-02-26%2017:21:40

SIP服务器IP：123.56.87.34 

SIP服务器编号：44010200492000000001 

SIP服务器端口：5061 

SIP域：4401020049 

密码：jinherwvp

10000007091327102637  

https://developer.arm.com/documentation/ddi0308/d/Thumb-Instructions/Alphabetical-list-of-Thumb-instructions/BL--BLX--immediate-

https://developer.arm.com/documentation/ddi0344/k/programmers-model/thumb-2-instruction-set

9 第二个项目是Rt-Thread支持GDB-Server功能，项目的背景是在RT-Thread系统加载377 Linux SDK的过程中，由于ko和lib库的没有源码，因此造成跟踪问题困难，同时，在实际的377方案上也缺乏调试手段或工具，没有gdb。因此，在这样的情况下我们需要自己实现一个GDB调试器，它能够调试RT-Thread系统的内核；我们所实现的基本功能为：能够运行和停止内核程序，并观察和修改内存和寄存器的制，同时也能够动态地添加和删除断点来实现单步调试功能。更进一步，我们需要实现gdb的watch功能，也就是监控某个内存值是否发生变化。该项目的重难点在于调试器涉及的软硬件操作较多，比如异常处理，模式切换，状态保存以及指令解析等方面，且不可能有另一个调试器来跟踪开发过程中遇到的问题，同时网上关于调试器开发的资料很少，造成项目开发有一定的难度。

10 首先介绍一下整体的工作，对于gdb-stub模块作为调试器来讲，它是编入到内核之中的，它的内部实现也不会调用任何库函数，除了依赖于串口通信这个模块用于同用户进行交互。对于调试器的原理来讲，它是非常简单的，如上图所示，这是它的一个调试过程，我们

首先要做的是添加一个断点，添加断点的目的是为了让程序暂时停下来，断点添加的方式是将内核的正常指令替换为未定义指令，比如0xdefe，那么当处理器执行到断点位置时将会出发未定义异常，并跳转到未定义异常处理函数那儿；那么此时，我们可以将未定义处理函数改为gdb-stub模块的入口，从而让内核陷入到这个模块中从而进行查看内存，修改断点等操作，等调试完成之后，我们便可恢复断点位置的原始指令，并设置pc值让它重新执行该指令，在外界看来，就好像在断点位置调用了一次gdb-stub函数一样，这样就完成了一个调试过程。

11 虽然调试器的原理是很简单的，但在开发过程中有许多细节需要注意，同时也在以下这几个方面踩坑比较多：首先是对于调试前的准备，当处理器发生未定义异常时，并不是简单地跳转到未定义异常处理函数去执行，而是会先完成一些其他工作，比如正常代码是运行在SVC模式下的，未定义异常时会将处理器模式切换为UND模式，并且将SVC模式下的某些状态值储存到UND模式下的私有寄存器中；因此我们需要考虑到这种情况；其次，调试区代码是运行在SVC模式下，因此在进入调试区前也需要进行现场保护和恢复工作；最后，由于ARM处理器采用三级流水线操作，也就是取指，译码，执行它会异步执行，这就导致我们cpsr

寄存器的值不是发生异常时的pc时，重新执行断点原始指令时需要进行修正。

第二个细节是在调试的过程中，当我们需要在断点位置的下一个指令处打上新的断点以实现单步运行时，但是对于不同的指令来讲，

我们就需要根据当前指令类型和状态寄存器

12 在调试器的开发过程中，最主要的一个难点就是如何实现watch功能，对于它的实现网上资料很少，但理论上来讲应该可以通过以下三种方式来实现，第一种方式是我们组的张涛提出的通过MMU的机制来实现watch功能，它的原理是这样的，结合前面的MMU模块，我们可以将所观察变量的内存物理页属性为不可写，那么当有程序修改变量时就会触发访问异常从而进行调试区，但它的缺点是实现复杂，且MMU修改内存属性最小以page为单位，影响范围太大

第二种方式也是我们采取的方式，但是尚未成功。当时是在一篇博文中看到有个人喊到可以通过