GDB uses the details of Zou Shu (Syzou), Southwest Jiaotong University provides graduate students to provide
1. Better We will learn to use GDB to debug embedded systems connected to PCs with PCs through the serial line. GDB can debug a variety of programs, including C, C , Java, Pascal, Foran, and some other languages. Includes the assembly language of all microprocessors supported by the GNU. Among all the rumorable properties of GDB, it is worth noting that when the platform (host host) running GDB is connected to the target board by serial port (or network connection, or other means) (application) The program runs on the board), and GDB can debug the application to debug the application. This feature is not only useful to transplant the GNU tool to a new operating system or microprocessor, it is also very useful for designers developed by the embedded system of the chip that GNU already supported. When GDB is properly integrated into an embedded system, its remote debugging function allows designers to debug program code step by step, set breakpoints, verify memory, and exchange information with the target. GDB exchange information with the target board is quite strong, better than most commercial debug kernels, and even functionality is equivalent to some low-end emulators. 2. GDB functions when debugging a remote target device when debugging a remote target device, relying on a debug stub to complete its function. Debug STUB is a small piece of code in an embedded system, which provides a medium between the host machine and the debugged application running GDB. GDB and debug STUB communicate via GDB serial protocol. The GDB serial protocol is a message-based ASCII code protocol that includes commands such as read and write memory, query registers, running programs. Because most embedded system designers have written their own stubs in order to make specific hardware features in their hands. So we need to understand the GDB serial communication protocol. Behind we will introduce. In order to set breakpoints, GDB uses memory readback commands, without harming the original instruction with a trap command or other similar opcode (assuming, the debugged application is in RAM, of course, if STUB There is a good performance, the hardware is also good, this condition is not a must) instead, so that when executing this command, the control can be transferred to the debug stub hand. At this time, the debug STUB task is to transfer the current scene to GDB (via a remote serial communication protocol), then receive commands from the GDB, which tells Stub's next step. For explanation, the following code is a Trap exception handler of the Hitachi SH-2 processor: / * Store the value of the current register to the stack * // * then call GDB_EXCEPTION. * / Asm (". Global _GDB_EXCEPTION_32_GDB_EXCEPTION_32: / * Press the stack pointer and R14 into the stack * / mov.l r15, @ -r15mov.l r14, @ -r15 / * When performing a trap abnormality, SH2 automatically puts the PC and SR in the stack * // * so we The stack pointer value we give GDB must be adjusted to explain this special data * // * in other words, before the trap is executed, GDB wants to look at the value of the stack pointer, * // * instead of the trap is executed Time value.
* // * So, subtract 8 * // * (PC and SR is 4 bytes from our SP value) * / mov.l @ (4, r15), R14ADD # 8 R14Mov.l R14, @ (4, r15) / * Press the other register value into the stack * / Mov.l R13, @ -r15mov.l r11, @ -r15mov.l r10, @ -r15mov.l r9, @ -r15mov.l r8, @ -r15mov.l r6, @ -r15mov.l r5, @ -r15mov.l r4, @ -r15mov.l r3, @ - R15MOV.L R2, @ -r15mov.l r1, @ -r15mov.l r0, @ -r15sts.l macl, @ -r15sts.l machine, @ -r15stc VBR, R7STC GBR, R6STS PR, R5 / * Call GDB_EXCEPTION, To make it anomalies = 32 * / mov.l _GDB_EXCEPTION_TARGET, R1JMP @ R1MOV # 32, R4 .align 2_GDB_EXCEPTION_TARGN 2_GDB_EXCEPTION_TARGET: .LONG _GDB_EXCEPTION "); / * Below is a sample from debug stub to a control of an application to an application ( For Hitachi SH2) * // * If you write in a C language, then the prototype of this statement is: * // * void gdb_return_from_exception (gdb_sh2_register_t registers); * // * All, we can use GDB_EXCEPTION_NN to press the register into the stack Way * // * Popked it from the stack. However, usually returns a pointer to our return stack pointer. * // * So if we copy the PC and SR to return to the pointer, we will return to the R15 * / Lost PC and SR.
* / Asm ( "global _gdb_return_from_exception_gdb_return_from_exception:. / * Restore certain registers * / lds r4, prldc r5, gbrldc r6, vbrlds r7, machlds.l @ r15 , maclmov.l @ r15 , r0mov.l @ r15 , r1mov.l @ R15 , R2Mov.L @ R15 , R3Mov.L @ R15 , R4Mov.L @ R15 , R6Mov.L @ R15 , R7Mov.l @ r15 , R9Mov.l @ r15 , R9MOV.L @ R15 , R10Mov.l @ R15 , R11Mov.L @ R15 , R12 / * pop up PC and SR to the stack * / mov.l @ (8, R15), R14Mov.L @ (16, R15), R13MOV. L R13, @ -r14mov.l @ (12, r15), R13Mov.l R13, @ -r14 / * completed the work of recovery registers * / Mov.l @ R15 , R13Mov.l @ R15 , R14Mov.l @ R15, R15 / * Adjust the stack of the application to illustrate the PC, SR * / Add # -8, R15 / * ... Return to the application * / RTENOP "); when the processor encounters a trap instruction (this instruction is made by When GDB is set, it is used, which makes the instruction cause the processor's current scene to turn to a function called GDB_EXCEPTION (). Finally, the target calls the GDB_RETURN_FROM_EXCEPTION () function that restores the processor's scene and handles the control to the application. The step command of the remote serial protocol is slightly more challenging, especially when the target processor does not provide a "tracking bit" or similar function. In these cases, the only alternative is to let Stub disassemble the instructions to be executed. This will know where the program will be executed next. Fortunately, in the source code of GDB, it also provides suggestions on how to implement these closer commands. For Hitachi SH-2 chip, the use of function dosstep () is described in the GDB / SH-stub.c file. For other kinds of chips, the name of the function is similar, please see file GDB / I386-Stub.c And GDB / M68k-stub.c3. Other functions of GDB can also solve the values of any C expressions entered in the console, including expressions including functional functions that have a function function of the far end. We can enter the following command: Print foo (sh_sci [current_sci] -> smr.brg) GDB will pass the value of MR.BRG to Foo () and report its return value. Of course, GDB can also disassemble code. As long as it is possible, it can also provide equivalent symbol information for the required data. For example, GDB outputs the following: JMP 0x401010
The language is independent of the target processor, so the application can be reused when the application is ported from one target processor to another processor. Finally, GDB also provides a function of tracking points, which can record information of a running program, while the data as much as possible will collect data. Trace points require special debug stubs to implement. 4. A typical GDB session process now we have explored the generic feature of GDB, now let's take a look at the execution of GDB. A typical GDB debug session process is given below. In this process, GDB initializes communication between the same running debug stub, then downloads the program, sets breakpoints, and runs the program. When you encounter a breakpoint, debug STUB notifies GDB, GDB then displays its source code line to the user. Next, the user displays a variable, and the approach executes an instruction and then introduces the GDB. Note that the content you see when you are using GDB is not shown below. The user see is a terminal, and the content displayed is the source code written in English, the variables to be displayed, and the like. However, the script shown below illustrates the content that occurs behind the scene when the user is typed. A typical GDB session process describes the above diagram, the left column shows part of the GDB console. Type commands and monitor data here. The right one column shows a communication message between the host and the embedded device using the GDB remote serial protocol. Some interpretation information is in square brackets. If you want to know the meaning of this information, see the Appendix GDB Remote Serial Protocol section. 5. GDB debugging STUB source code Although remote software debugging has a property dependence, it is still possible to create a highly portable debug stub, which can be reused between different embedded processor chips, and desired Minimum modification. Some people have tried this work. If you are interested, you can go online to consult the relevant information. For example http://sourceforge.net/projects/gdbstubs. The processor-specific code is included in the file name associated with the processor, such as GDB_SH2 * .c. We can download related files (for example, GDB_M68K * .c) for our specific processor, then replaced the relevant content on our machine. 6. Regarding the renovation of GDB to solve the specific problem considering GDB uses a modular architecture to implement, then it can be directly processed directly to certain features that are not suitable for us. For example, if our products have only one communication port, and it is not a GDB communication protocol, then the GDB can be modified, so that the debugger's information is matched to our product package already used. Similarly, if our products do not have a serial port, while some other communication interfaces (such as CAN ports), we can strengthen the remote communication function of GDB to accommodate the port. We can also modify the GDB's way to make it more compatible with our embedded applications. For example, if we are using TRAPA # 32 to do some work-independent work, we can change the operand that GDB used to set breakpoints, or we can use GDB to generate a new message tells us the target board. The function of the instruction tracking or enables the breakpoint within the chip to generate hardware. The file GDB / Remote.c contains the implementation process of the remote serial protocol of GDB. How is the modular implementation of GDB allow us to quickly transform it to accommodate specific debugging objectives, this file is a good starting point. Other documents, such as GDB / Remote-HMS.C and GDB / Remote-E7000.c, which supports the module-based structure to support debuggers, such as Hitachi, Motorola, etc.
