GDB remote debugging in Embedded Linux

GDB remote debugging in Embedded Linux
Abstract: The research and application of embedded Linux systems are becoming increasingly popular. Aiming at the problem of how to complete system debugging, this article introduces the gdb remote debugging function and its working mechanism. It mainly describes the use of GDB remote debugging technology in Embedded Linux systems. examples of debugging various programs
1 Introduction
Letter
Personal Digital Assistant, handheld computer set-top box, and other embedded products have become a hot spot in the market.
After achieving great success in the desktop system, Linux has gradually become a hotspot and widely used in embedded systems due to its easy customization and expansion of open source code, multi-hardware platform support and built-in network functions.
The system platform uses GDB (GNU
Debugger) powerful debugging capabilities developers can avoid using expensive simulator tools to track and Debug programs. Because of the limited hardware and software resources of embedded systems, it is generally impossible to build local systems.
The GDB debugging environment uses the advanced function of remote debugging to flexibly track and Debug programs running on the target platform on the host machine.
2. GDB remote debugging
GDB is a free debugging and debugging tool provided by GNU. It can be used for tracking and debugging C ++ Pascal and Fortran programs. In Embedded Linux systems, developers can conveniently use GDB on the host machine to remotely debugging method: One-step execution of the program code on the target platform sets the breakpoint to view the memory and exchange information with the target platform
Enable
Use GDB for remote debugging to run GDB on the host machine through a serial port or TCP connection and debugging plug-in running on the target machine stub to work collaboratively with the gdb standard Remote Serial protocol to achieve the target
Monitor and debug the system kernel and upper-layer applications on the machine stub is a piece of code in the embedded system as a medium between the host machine GDB and the target machine debugging program, and the gdb remote debugging structure exists.
1. Standard Remote Serial protocol for the gdb operating system of the host machine on the upper layer of the target machine of the stub Operating System
Figure 1 GDB remote debugging structure
To monitor and debug program hosts
GDB uses the memory read/write command in the serial protocol to replace the original command of the target program with a trap command to complete the breakpoint setting. When the target system executes the Trap Command, Stub can successfully obtain
In this case, the host GDB can track and debug the target machine program through stub. After debugging, Stub will send the current scenario to the host GDB and then receive its control command. Stub follows the command in the target
The system performs the corresponding action to implement debugging functions such as reading/writing memory, viewing register content, and displaying variable values in one step.
The GDB Remote Serial protocol is a message-based ASCII code protocol that defines the information for reading and writing data to control the program to be debugged and reports the status of the running program. These functions are related to stub on the target machine. function implementation, while the host is remote by the gdb source file. the function code in C completes the protocol exchange data format as follows:
$ <DATA> # [chksum]
Here, <DATA> is an ASCII hexadecimal string [chksum] is a byte hexadecimal checksum. When the message is sent, the receiver responds as follows:
+ The received data is verified correctly and the receiver is ready to receive the next data packet.
-Incorrect received data validation. The sender must resend the data packet.
There are two ways to debug stub to respond to the gdb data of the Host: if the message is correctly transmitted, the response data is returned or OK. Otherwise, the error code defined by the target platform is returned and the GDB Console reports to the user <DATA> complete definitions of operation commands and status information for remote debugging are provided. For more information, see
GDB refer to the gdb Remote Serial protocol section in info-14 of the document.
3 remote debugging practices
Far
The local debugging environment consists of the host machine GDB and the target machine debugging stub. The local machine environment is relatively simple to implement the remote debugging function through the serial port or TCP connection using the gdb standard Remote Serial protocol.
If you have a system environment that can run GDB, you can select a better Linux release version. However, you must note that developers cannot directly use GDB in the release version for remote debugging.
The source file package of GDB makes a simple configuration for a specific target platform and reassembles the chain to obtain the corresponding GDB
Host> Cd/tmp/gdb-5.2.1
Host>./configure -- target = ......
Host> make
Host> CP/tmp/gdb-5.2.1/GDB/usr/bin
Its
In the configure command, the target parameter specifies the type of the target machine. developers can obtain the parameter value from the gdb instruction document based on the target platform, so that the remote debugging environment of the host is established.
Well, the rest is the implementation of stub on the target machine. In specific environments, the implementation and usage of the target stub are related to the hardware platform and application scenarios. Currently, there are three remote calls in the embedded Linux system.
The test method is applicable to the ROM for debugging in different scenarios.
Monitor the existence of stub remote debugging on the target machine by using kgdb to debug the system kernel and by using gdbserver to debug the user space program.
Different forms, while their design ideas and implementation methods are roughly the same
3.1 Use Rom monitor to debug the Target Program
Status of the embedded Linux system before the kernel runs
In general, the ROM monitor is used to load, run, and debug the program. The system is powered on and includes the ROM of stub for remote debugging.
Monitor first obtains system control to initialize important resources and peripherals such as CPU memory interruption serial port network, and then downloads and runs and monitors the target code, including kernel loading and guidance.
The most common redbootred hat embedded debug and
Bootstrap is a powerful system pilot debugging and management tool, which includes the complete implementation of the gdb remote debugging stub serial port and Ethernet port driver TCP/IP protocol.
An instance session for downloading and debugging the target program armboot with Redboot before the start of the target system and flash device management and other functions of the kernel run is as follows
Press '$' At the prompt when Redboot runs on the target board to enter the stub debugging status.
Arm ECOs // some Redboot boot Information
Redboot (TM) debug environment-built 15:49:04, Mar 27 2002
Copyright (c) 2000, Red Hat, Inc .......
Redboot> // press '$' to enter the stub debugging status.
Redboot> entering debug mode using GDB and stubs
Download and debug the program by running GDB on the host machine
[Root @ host armboot-1.1.0] # GDB armboot
Gnu gdb 5.2.1 // part of GDB startup information
Copyright 2002 Free Software Foundation, Inc.
Configured as "-- Host = i686-pc-linux-gnu -- target = arm-PXA-Linux-GNU "...
(GDB) set remotebaud 115200 // sets the serial port baud rate
(GDB) target remote/dev/ttys0 // connect to the target machine through serial port 1
Remote debugging using/dev/ttys0
0x0000e2b8 in ?? ()
(GDB) Load // download the target code to the memory of the target machine
Loading section. Text, size 0xbef8 LMA 0xa3000000
Loading section. rodata, size 0x2f84 LMA 0xa300bef8
Loading section. Data, size 0xd24 LMA 0xa300ee7c
Start address 0xa3000000, load size 64416
Transfer Rate: 85888 bits/sec, 298 Bytes/write.
(GDB) List serial. C: 75 // view the source code
70 */
71 void serial_init (bd_t * BD)
72 {
73 const char * baudrate;
74
75 if (baudrate = getenv (BD, "baudrate "))! = 0)
76 BD-> bi_baudrate = simple_strtoul (baudrate, null, 10 );
77
78 serial_setbrg (BD, BD-> bi_baudrate );
79}
(GDB) Break 75 // sets the breakpoint
Breakpoint 1 at 0xa300b964: file serial. C, line 75.
(GDB) Continue // run the target program to the breakpoint
Continuing.
Breakpoint 1, serial_init (BD = 0xa30312e4) at serial. C: 75
75 if (baudrate = getenv (BD, "baudrate "))! = 0)
(GDB) display baudrate // display the current value of the variable baudrate
1: baudrate = 0xa30312e4 ""
(GDB) Next // trace the value of the baudrate variable
76 BD-> bi_baudrate = simple_strtoul (baudrate, null, 10 );
1: baudrate = 0xa300f392 "115200"
(GDB)
Developers can rely on the powerful debugging and monitoring functions provided by GDB to track programs running on the target board in real time and clearly view the status of the target board resources used by the program, such as the CPU register memory value.
3.2 use kgdb to debug the system kernel
System
The system kernel is closely related to the hardware system. Therefore, the implementation of stub debugging may also vary with the specific target platform, and some open-source communities and development teams of different embedded Linux have targeted most popular targets.
Platform for Linux kernel remote debugging stub is implemented and released in the form of source code patches. Developers only need to properly link and patch the kernel to debug the kernel code flexibly on the PC platform Linux
Well-known kgdbremote kernel by kernel developers
Debugger is the implementation form. This method is also used in the Deepak of montavista in Embedded Linux systems.
The kernel debugging patch developed by Saxena can be used to debug the Linux Kernel on the iop3xxadi and IXP platforms.
The general scenarios of do_fork () kernel functions are as follows:
(GDB) set remotebaud 115200 // sets the serial port baud rate
(GDB) target remote/dev/ttys0 // connect to the remote target through serial port 1
Remote debugging using/dev/ttys0
......
(GDB) Continue // The connection is successful and start the kernel.
Continuing.
Memory clock: 99.53 MHz (* 27) // kernel startup information
Run mode clock: 99.53 MHz (* 1)
......
VFS: mounted root (NFS filesystem ).
Freeing init memory: 76 K
Program received signal sigtrap, // interrupt kernel running to set breakpoints
Trace/breakpoint trap.
......
(GDB) List fork. C: 622 // view the kernel source code
617 p-> did_exec = 0;
618 p-> swappable = 0;
619 p-> state = task_uninterruptible;
620
621 copy_flags (clone_flags, P );
622 p-> pid = get_pid (clone_flags );
623
624 p-> run_list.next = NULL;
625 p-> run_list.prev = NULL;
626
(GDB) Break 622 // sets the breakpoint
Breakpoint 1 at 0xc01_d50: file fork. C, line 622.
(GDB) Continue // resume the kernel running until the breakpoint
Continuing.
Breakpoint 1, do_fork (clone_flags = 17, stack_start = 3221223548, regs = 0xc7153fc4, stack_size = 0) at fork. C: 622
622 p-> pid = get_pid (clone_flags );
(GDB) display P-> PID // DISPLAY variable p-> current PID Value
1: p-> pid = 1152
(GDB) next 3 // trace the changes of Variable P-> PID after the get_pid () function returns
624 p-> run_list.next = NULL;
1: p-> pid = 1181
(GDB) delete 1 // delete a breakpoint
(GDB) Continue // resume kernel running
Continuing.
The debugging functions of GDB are rich and powerful. In the preceding example, only one of the simplest application developers in the system kernel debugging of GDB can use the many functions provided by GDB to perform powerful tracking debugging on the kernel.
3.3 Use gdbserver to debug user space programs
In Linux
Based on the normal operation of the kernel, gdbserver is used as the remote debugging stub implementation. developers can use GDB on the host machine to conveniently monitor the running of user space programs on the target machine.
Gdbserver is the remote debugging stub provided by GDB for user programs. It has good portability and can be cross-compiled to multiple target platforms for running. Because the operating system supports its implementation
The general debugging of stub is much simpler, but the goal of remote debugging of user programs is that it is used. The following describes the remote debugging of the host GDB and the target machine gdbserver in TCP mode.
In the MiniGUI helloworld program session process, 192.195.150.140 is the host machine 192.195.150.164.
Target machine
[Root @ l2x target] # gdbserver 192.195.150.140: 2345 mginit
Process mginit created: pid = 72 // wait for the host to connect
Host
[Root @ l2x host] # GDB mginit
...... // GDB version configuration information
(GDB) target remote 192.195.150.164: 2345 // TCP connection to the target machine
Remote debugging using 192.195.150.164: 2345
0x40002a90 in ?? () // Connection successful
Target machine
Remote debugging from host 192.195.150.140 // the host is successfully connected.
Host
(GDB) Break mginit. C: 73 // sets the breakpoint
Breakpoint 1 at 0x8bfc: file mginit. C, Line 73.
(GDB) Continue // run the program to set the breakpoint
Continuing.
Breakpoint 1, miniguimain (ARGs = 1, Arg = 0xbffffe14) at mginit. C: 73
73 hmainwnd = createmainwindow (& createinfo );
(GDB) display createinfo // view the variable
1: createinfo = {dwstyle = 671088640, spcaption = 0x8cd8 "Hello, world! ",... }
(GDB) C // run until the end of the program
Continuing.

Program exited normally. // The program Exits normally.
Target machine
Child exited with retcode = 0 // The program runs and returns
Child exited with status = 14 // program exit status
Gdbserver exiting. // end of joint debugging
In
During the development of embedded system upper-layer applications, the software and hardware environments of the host machine and the target machine are more or less different. Therefore, the program that developers simulate on the host machine cannot run well on the target platform. application
The preceding remote debugging method reduces the dependency on simulated debugging on the host. It is as convenient as debugging local programs to directly monitor and Debug programs running on the target platform remotely, thus improving the development quality. and
It is particularly worth mentioning that this method is very convenient for debugging embedded GUI systems. The host machine runs the debugger and the target machine runs the GUI system to be debugged.
Each console processes input and output without interfering with each other. It communicates through a serial port or TCP to debug the GUI system. This debugging tool and synchronous interaction between the graphic system and developers are implemented in the standalone debugging environment.
Currently, it is troublesome not only to use virtual graphics devices to support input and output of graphics systems, but also to use qvfb in the Qt graphics library as a virtual framebuffer and to use debugging tools and graphics systems.
Cross-device interaction requires the use of xterm and other terminal tools to build and debug the debugging environment. The specific implementation is cumbersome, but the effect is not as good as remote debugging.
4 Conclusion
Embedded
In Linux system development, GNU tool chain is a good choice. It not only provides good support for a variety of popular embedded processors, but also allows developers to use it for free, which greatly reduces system development costs.
GDB in the chain is used for remote debugging to adapt to the special debugging requirements of the embedded system. It has been widely used in actual development. We have implemented embedded Linux on an ARM Series Experimental Development Board.
In the system, the gdb remote debugging method described in this article is used to complete the debugging of user space code on the basis of the Code kernel code kernel before the kernel runs. The system development efficiency has been improved.