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 in the stack * / mov.l R15, @ -r15mov.l r14, @ -r15
/ * When a trap exception is executed, SH2 automatically places PC and SR into stack * // * so we must adjust our stack pointer value to GDB, 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 being executed the current value. * // * So, subtract 8 * // * (PC and SR is 4 bytes from the SP value just pressing the stack) * /
Mov.l @ (4, r15), R14ADD # 8, R14Mov.L R14, @ (4, R15)
/ * Pressing other register values * / Mov.l R13, @ -r15mov.l R12, @ -r15mov.l r10, @ -r15mov.l r9, @ -r15mov.l r8 @ -r15mov.l r7, @ -r15mov.l r6, @ -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 / * calls GDB_EXCEPTION, makes it anomalous value = 32 * / mov.l _GDB_EXCEPTION_TARGET , R1JMP @ R1MOV # 32, R4
.align 2_gdb_exception_target: .long _gdb_exception ");
/ * Below is a sample (for Hitachi SH2) * // * If Hitachi SH2) is returned from debug stub (for Hitachi SH2) * // * If you write in a C language, then the prototype of this statement is: * // * Void GDB_RETURN_FROM_EXCEPTION (GDB_SH2_REGISTERS_T Registers * // * All in all, we can use GDB_EXCEPTION_NN to press the register into the stack in the same way * // * to pop up from the stack. However, usually returns a pointer to our return stack pointer different. * // * So if we pop up R15 before copying the PC and SR, we will return to * / lose the 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 , r5mov.l @ r15 , r7mov.l @ r15 , r8mov.l @ r15 , r9mov.l @ r15 , r10mov.l @ R15 , R11MOV. L @ r15 , r12
/ * Popked PC and SR to the stack of the application * / Mov.l @ (8, R15), R14Mov.L @ (16, R15), R13Mov.L R13, @ -r14mov.l @ (12, r15) , R13Mov.l R13, @ -R14
/ * Complete 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 Application * / RTENOP ");
When the processor encounters a Trap instruction (this command is set by GDB, it is used for breakpoints), the instruction causes the current scene of the processor 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 uses the following output:
JMP 0x401010
Tell us, the displayed address is equal to the address of 80 bytes from the starting address of the function main (). GDB can display remote serial debugging information between its own and debugged targets, or you can record this information into the log file. These features are useful for we debug a new STUB, understand how Stub is using a remote serial protocol to implement the user's demand for data, program memory, system calls, etc. GDB has a scripting language that allows automatic settings and detection to the target. 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.
Description of a typical GDB session process
In the above figure, 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. 7. Summary GDB's adaptability to debug targets (including the use of memory, communication medium, etc.) make it often a unique choice for debugging of the target board. This is especially true that the unparalleled embedded product based on IP is taking into account the Single chip high integration. Today, the complexity of embedded equipment is increasing, and the choice of technologies for choice is increasing when conducting new design, and it is more difficult to find a commercial development product. The use of GNU tools will be a good choice. The GNU tool supports the support of various popular embedded processors that when we are using the development tools that we will do not support us in the next design, we can reduce the new development tools. Danger.
