The target-side support for GDB includes a GDB class that communicates through some I/O channel with the host debugger, and sits in a thread. A seperate thread is used not only to keep the debugger off the stack of the threads being debugged, but also to allow the debugger to be interrupt driven and asynchronous. In theory, the debugger can stop a few interesting threads and leave others running, or can watch a live system and report back interesting events as they happen. The debugger mainly uses faults, including CPU trace faults, to control the threads being managed.
The support for GDB includes a single class that communicates with the host debugger. Patches come with uCR to allow the host GDB to communicate with this proxy. The programmer then just needs to add the proxy into the target to be debugged.
# include <gdb/GDB.h> class GDB; g++ ... -lgdb -lchips -lucr
The GDB proxy interface consists almost entirely of the single class GDB and its most interesting method GDB::go(). All the application programmer does is include a single instance of the class GDB in the program. (It is OK for the object to be static.) The application starts up all the threads of the program, including a thread for the gdb proxy, and in that thread calls the go() method. It generally works best to spawn all the application threads and run gdb in the main thread.