Implementation of GDB remote debugging in Embedded Linux

Article Title: Implementation of GDB remote debugging in embedded Linux. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

The remote debugging environment consists of the host machine GDB and the target machine debugging stub. The two are connected through the serial port or TCP. Use the GDB standard serial protocol to work collaboratively to monitor and debug the system kernel and upper-layer applications on the target machine. Debugging stub is a piece of code in the embedded system, which exists as a medium between the local host GDB and the target machine debugging program.

Currently, there are three main remote debugging methods in the embedded Linux system, which are suitable for debugging in different scenarios: use ROM Monitor to debug the target program, use KGDB to debug the system kernel, and use gdbserver to debug the user space program. The main difference between the three debugging methods is that the existence of stub for remote debugging on the target machine is different, while the design idea and implementation method are roughly the same.

The most common practice is to debug applications. Debugging is performed using gdb + gdbserver. In many cases, users need to debug an application repeatedly, especially complex programs. The GDB method is used for debugging. Due to limited embedded system resources, debugging on the target system is generally not allowed. gdb + gdbserver is usually used for debugging. Gdbserver runs in the target system, while GDB runs on the host machine.

Line GDB debugging. The target system must include the gdbserver program, and the local host must also install the GDB program. Generally, there is a running GDB in the Linux release, but developers cannot directly use GDB in the release for remote debugging. Instead, they need to obtain the source code package of GDB, make a simple configuration for the arm platform and re-compile the corresponding GDB. The source code package of GDB can be downloaded from http: // ftp.cs.pu.edu.tw/linux/sourceware/gdb/releases/, and the latest version is gdb-6.4. Download to a directory, and download to your own user directory:/home/vicky.

After the download, go to the/home/vicky directory and configure the compilation steps as follows:

 

#tar jxvf gdb-6.4-tar-bz2#cd gdb-6.4#./configure --target=arm-linux --prefix=/usr/local/arm-gdb -v#make

This step may cause a problem, prompting a function (the specific function name does not remember) parse error, that is, an "}" is added before the unsigned side "}", you can use vi to enter that line and delete it.

 

# Make install # export PATH = $ PATH:/usr/local/arm-gdb enter the gdbserver Directory: #./configure -- target = arm-linux? Host = arm-linux # make CC =/usr/local/arm/2.95.3/bin/arm-linux-gcc (this step specifies the location of arm-linux-gcc)

If there is no error, generate the gdbserver executable file in the gdbserver directory, and burn it to the root file system partition of flash, or use nfs mount. You only need to ensure that gdbserver can run on the Development Board.

Next we can use gdb + gdbserver to debug the program on our development board. Running gdbserver on the target board is actually under the minicom of the host machine, and my RedHat Linux is installed under vmware. I did it after # mount 192.168.2.100: // tmp under minicom (here the-o nolock parameter can be left blank, but it is faster to execute this step without adding it ), hello and gdbserver are both located in the Linux root directory, and the host root directory is mounted to the/tmp directory of the Development Board.

To debug gdb, start the gdbserver service on the target system. Enter the following command in the directory where gdbserver is located:

 

(Under minicom) # cd/tmp #./gdbserver 192.168.2.100: 2345 hello

192.168.2.100 is the host machine IP address, and a debugging process is enabled on port 2345 of the target system. hello is the program to be debugged.

Prompt:

 

Process/tmp/hello created: pid = 80 Listening on port 2345 (another terminal) # cd/# export PATH = $ PATH: /usr/local/arm-gdb/bin # arm-linux-gdb hello (gdb) target remote 192.168.2.223: 2345 (192.168.2.223 is the IP address of the Development Board)

Prompt:

 

Remote debugging using 192.168.2.223: 2345 [New thread 80] [Switching to thread 80] 0x40002a90 in ?? () At the same time, the message "Remote debugging from host 192.168.2.100 (gdb)" is displayed under minicom)

After successful connection, you can enter various GDB commands such as list, run, next, step, and break to debug the program.

For the above methods, nfs mount and tftp can only be debugged on the host and downloaded to the Development Board for running. If there is an error, repeat this process, some programs can only be debugged on the Development Board. Therefore, the remote debugging method of gdbserver is adopted. I hope it will be useful for debugging programs!