-
-
手机阅读
第一种方案是在目标操作系统和调试器内分别加入某些功能模块，二者互通信息来进行调试。上述问题可通过以下途径解决：
调试器与被调试程序的通信
调试器与目标操作系统通过指定通信端口（串口、网卡、并口）遵循远程调试协议进行通信（远程调试协议详见http://rtos.ict.ac.cn/rtos/debugger/）。
被调试程序产生异常及时通知调试器
目标操作系统的所有异常处理最终都要转向通信模块，告知调试器当前的异常号；调试器据此向用户显示被调试程序产生了哪一类异常。
调试器控制、访问被调试程序
调试器的这类请求实际上都将转换成对被调试程序的地址空间或目标平台的某些寄存器的访问，目标操作系统接收到这样的请求可以直接处理。对于没有虚拟存储概念的简单的嵌入式操作系统而言，完成这些任务十分容易。
调试器识别有关被调试程序的多任务信息并控制某一特定任务
由目标操作系统提供相关接口。目标系统根据调试器发送的关于多任务的请求，调用该接口提供相应信息或针对某一特定任务进行控制，并返回信息给调试器。
调试器处理与目标硬件平台相关的信息
第2条所述调试器应能根据异常号识别目标平台产生异常的类型也属于这一范畴，这类工作完全可以由调试器独立完成。支持多种目标平台正是GNU GDB的一大特色。
综上所述，这一方案需要目标操作系统提供支持远程调试协议的通信模块（包括简单的设备驱动）和多任务调试接口，并改写异常处理的有关部分。另外目标操作系统还需要定义一个设置断点的函数；因为有的硬件平台提供能产生特定调试陷阱异常（debug trap）的断点指令以支持调试（如X86的INT 3），而另一些机器没有类似的指令，就用任意一条不能被解释执行的非法（保留）指令代替。目标操作系统添加的这些模块统称为"插桩"（见下图），驻留于ROM中则称为ROM monitor。通用操作系统也有具备这类模块的：编译运行于Alpha、Sparc或PowerPC平台的LINUX内核时若将kgdb开关打开，就相当于加入了插桩。