The method of operation of the GDB Server is simply structured. The host debugger initiates the loading of the application, which is to be debugged, by sending this "load request" to the GDB Server. The GDB Server starts a new process and, before the start of the actual application, activates the system call "ptrace" in order to gain control of the application process. This system call ensures that the process is marked as "TRACED" and all signals occurring are forwarded to the parent process.

If now during the debug process any signal is sent to the application, the Linux kernel recognizes - by means of previously set flags - that this process is executing controlled (traced) and initiates the halt of the application. The signal, which was essentially determined for the application, is subsequently sent to the waiting GDB Server. The GDB Server can then process the signal or forward it to the process. With help of this technique, an analysis and debugging also at signal level is possible.

In addition to the debugging of signals, classic methods - such as step-in or step-over of functions, a single-step or the setting of breakpoints - are also possible. The basis for these methods are classic breakpoints; in other words, halting of the application when predetermined program positions are reached. Therefore, the GDB Server inserts at the applicable position in the code a break code, which when executed initiates a "SIGTRAP" signal.

With this signal, it is communicated to the GDB Server that the application was halted and the control is once again assigned to the GDB. Via further requests, the host PC can then, for example, readout the current register contents or retrieve information about the "call stack".

Additional features for embedded applications

In the system described, a modified GDB Server is used. In addition to the basic functions described, this GDB Server offers the user some interesting further options, specifically for the use in embedded systems. Some of the main features are:

* the JTAG interface can be used as communication channel for the application debugging

* application ELF files can be loaded from the host PC in the target system via Windows Share or Samba "Common Interface File System" (CIFS)

* the support of the debugging in "shared libraries" (*.so Files)

* the upload of ELF files via Ethernet or JTAG to the target system