How to debug embedded software in VIM

introduction

GNU provides a complete set of tool chains for free, providing complete support for the development and debugging of embedded Linux programs. Its powerful gdb debugging tool can easily track and debug programs on embedded platforms; and the powerful VIM editor under Linux can not only easily call make files to compile codes, but also easily become an efficient code editing environment through script configuration.

1 gdb debugging mode for embedded software

Many non-Linux embedded systems have been using gdb and gdb stub to remotely "cross debug" the target board; however, because the Linux kernel implements the ptrace() system call, gdb stub is not needed when debugging embedded applications, and the gdb server provided by the gdb suite is used to debug embedded applications on the target board. There are two main ways for the gdb server gdbserver on the target board to communicate with the gdb debugger on the host: "cross serial connection" using serial port communication and "TCP/IP" connection using network port. In view of the convenience of the PC side and the limited serial port resources, especially the current laptops do not even have serial ports, so most of them use TCP/IP, that is, the PC host and the target board are directly connected through a network cable or the PC and the target board communicate through a router or hub to form a local area network. This debugging mode is shown in Figure 1.

2 Debugging embedded software in VIM

We know that although gdb is powerful, its debugging process is not intuitive because it is based on command line operations. In addition, the debugging environment under Windows integrates debugging and code editing. When a bug occurs, the source code can be easily modified. In comparison, gdb is somewhat inferior in this respect. Since VIM and gdb are so powerful, completely free, and completely suitable for the special development mode of embedded systems, is there a way to combine the two? Yes, that is vimgdb.

vimgdb is a patch that provides an optional feature for VIM. It can provide complete gdb debugger support in the VIM editor, such as setting breakpoints, viewing variable values, gdb command completion, etc., and these operations can be displayed intuitively in VIM. The following describes the specific process of implementing embedded software debugging in VIM.

2.1 System environment and software package versions used

PC operating system: Ubuntu 8.10.

PC compiler: GNU gcc4.3.1.

Figure 1 TCP/IP connected embedded software debugging mode

PC debugger: GNU gdb6.8.

Target board Linux kernel: 2.6.13.

Target board CPU: S3C2440 (ARM9 architecture).

Cross compiler: armlinuxgcc3.4.1.

Cross debugger: self-compiled GNU gdb6.8.

Target board gdb server: self-compiled GNU gdbserver6.8.

Cross-platform development tool path: ~/buildtools/armlinux, and the system path variable has been set.

Test code and program path: ~/test, including program code test.c and Makefile.

The software package storage path used is: ~/down.

Software packages used: VIM editor source code vim7.1.tar.bz2, vimgdb711.13.tar.gz, GNU gdb source code gdb6.8.tar.bz2.

2.2 Apply vimgdb patch to VIM source code and compile and install

① Run the following command to decompress the VIM source code and vimgdb patch file, and patch the VIM source code:

cd ~/down

tar jxvf vim7.1.tar.bz2

tar zxvf vimgdb711.13.tar.gz

patch d vim71 backup p0 < vimgdb/vim71.diff

② Run the following command to compile and install the VIM compiler:

cd ~/down/vim71/src

make

make install

After executing the above operations, VIM will be installed in the /usr/local path. If you want to change the installation path, you can open the 862 line installation path option of the ~/down/vim71/src/Makefile file and modify it before the above compilation and installation. If VIM is installed in the /usr path, change 862 #prefix = $(HOME) to 862 prefix = /usr.

③ Install the vimgdb runtime file and run the following command:

cd ~/down/vimgdb

tar zxfv vimgdb_runtime.tgz C /usr/share/vim/vimfiles

2.3 Building gdb components for cross-debugging embedded software

① Compile the embedded gdb debugger server gdbserver and run the following command:

cd ~/down/gdb6.8/gdb/gdbserver

./cONfigure??host=armlinux ??target=armlinux

CC=armlinuxgcc make

Copy the gdbserver in the current directory to the /bin directory of the target board file system for cross debugging.

② Compile and install the cross debugger gdb, and run the following command:

cd ~/down/gdb6.8

./configure ??target=armlinux ??prefix=/home/popeye/buildtools/armlinux/

Note that the value of prefix here must be filled in with an absolute path, and "~" cannot be used to replace the user path /home/popeye, otherwise it will prompt that the prefix path assignment is wrong. Then run:

make

During this process, the error shown in Figure 2 may occur.

The reason for this is that the warning option "Werror" is selected in the compilation rules. It will turn all warnings into errors, and the prompt information about the "getwd" function shows that the compiler should detect a "warning" instead of a real syntax error. Therefore, the compilation options need to be corrected:

cd ~/down/gdb6.8/gdb

gedit Makefile

Note that the Makefile here is generated after executing the above make command. The original code package does not contain this file. Modify line 145 of the file and remove the assignment of WERROR_CFLAGS, that is, change "145 WERROR_CFLAGS = Werror" to "145 WERROR_CFLAGS =". Then:

cd ~/down/gdb6.8

make

make install

Figure 2 Error message during make

Finally, enter ~/buildtools/armlinux/bin and find that the cross debugger armlinuxgdb already exists

2.4 Preparation for embedded software debugging in VIM

The usual practice in the embedded software development process is: First, compile and debug the program on the PC. If it runs normally on the PC, cross-compile. Then, port the software to the target board. If a bug occurs on the target board, debug it with the cross debugger armlinuxgdb.

In short, the debugging process of embedded software includes two parts: debugging on the PC and debugging on the embedded platform. In this process, both the debugger gdb on the PC and the cross debugger armlinuxgdb may be used, and the corresponding ones are the same source code program and two executable programs running on different platforms. At the same time, it involves the conversion of two debuggers, but vimgdb can only call the system command with the string "gdb".

Let's simplify this difficult problem:

① Edit the applicable Makefile to control the generation of executable programs corresponding to different platforms:

cd ~/test

Among them, test.c is the experimental code, Makefile is the compilation rule, and we simply write the content of Makefile as follows:

testpc:test.c

gcc g Wall o testpc test.c

testem:test.c

armlinuxgcc g Wall o testem test.C

When the "make testpc" command is executed, an executable program that can be run on a PC will be generated; executing "make testem" will generate an executable program that can be run on an embedded target board.

② Modify the shortcut key mapping script of vimgdb to easily switch between PC debugger and cross debugger in VIM.

First, since vimgdb can only call system commands with the string "gdb", do the following:

mv /usr/bin/gdb /usr/bin/gdbpc

cd ~/buildtools/armlinux/bin

ln s /usr/bin/gdbpc gdb

Since ~/buildtools/armlinux/bin has been added to the system path, after performing the above operations, at any time when you run the "gdb" command, the debugger actually running depends on the debugger to which gdb is connected here.

Next, edit the file /etc/vim/macros/gdb_mappings.vim. The main changes and additions are:

a. Add the debugger conversion function and set the conversion switch to the uppercase "E" key (Shift+E):

let s:emOS_k = 1

nmap E :call emOS()

function! s:emOS()

if s:emOS_k

let s:emOS_k = 0

exec ":!ln sf ~/buildtools/armlinux/bin/armlinuxgdb ~/buildtools/armlinux/bin/gdb"

echohl ErrorMsg

echo "NOW! Gdb is ready for Embedded System!!!"

echohl None

else

let s:emOS_k = 1

exec ":!ln sf /usr/bin/gdbpc ~/buildtools/armlinux/bin/gdb"

echohl ErrorMsg

echo "Gdb is ready for PC,, Now"

echohl None

endif

End function

b. Add the following code below the if s:gdb_k line:

nmap :bel 25vsplit gdbvariables

nunmap E

That is, after entering the debugging state, block the debugger conversion shortcut key E, and set the shortcut key F8 to display the variable value monitoring window.

c. Add the following code below the line let s:gdb_k = 1:

exec ":!ln sf /usr/bin/gdbpc ~/buildtools/armlinux/bin/gdb"

nmap E :call emOS()

That is, after exiting the debugging state, the gdb command is restored to the call of gdbpc, and the debugger switch function of "E" is restored.

d. Add the following statement in /etc/vim/vimrc:

run macros/gdb_mappings.vim

After starting vim, the shortcut key mapping for calling gdb will be started in vim.

As for other shortcut keys specifically set in gdb_mappings.vim, readers can analyze or set them by themselves.

2.5 Debugging embedded software in VIM

The following are the shortcut keys used for debugging embedded software on the target board: E is the debugger switch; F9 is to enter the debugging mode; F8 is to open the variable monitoring window; the space bar is to open the command line input window; the debugging mode is for the PC to input and output the embedded target board through the hyperterminal, and Ubuntu8.10 debugs the embedded software through TCP/IP; the PC Linux IP is 222.31.51.147; the target board IP is 222.31.51.180; the debugging connection port is 1234.

① Use VIM to open ~/test/test.c, run the command ":make testem", copy the generated testem file to the file system of the embedded platform, and run the command on the embedded platform, specifying the cross debugger address waiting for connection, the connection port, and the embedded program to be debugged:

gdbserver 222.31.51.147:1234 testem

The embedded terminal will display a prompt message similar to the following and enter the waiting state for connection:

Process testem created; pid = 801

Listening on port 1234

② Press the capital "E" key (Shift+E) and determine the selected debugger according to the prompt information at the bottom of the VIM window.

The prompt message is "NOW! Gdb is ready for Embedded System!!!" or "Gdb is ready for PC,, Now".

③ Press F9 and enter the command "file testem" in the command window that appears. The following debugging information will appear in another window in VIM:

GNU gdb 6.8

Copyright (C) 2008 Free Software Foundation, Inc.

…

This GDB was configured as "host=i686pclinuxgnu target=armlinux".

(gdb) file testem

Reading symbols from /home/popeye/test/testem…done.

(gdb)

It can be found that the cross debugger armlinuxgdb has been successfully called in VIM. All subsequent debugging commands are passed to the debugger by pressing the space bar first, calling the command window, entering the command, and pressing Enter.

Press the spacebar and enter the command in the command window to connect to the embedded target board:

target remote 222.31.51.180:1234

At this point, the debugging information window in VIM displays the following information:

(gdb) target remote 222.31.51.180:1234

Remote debugging using 222.31.51.180:1234

[New Thread 801]

0x40000dd0 in ?? () from /lib/ldlinux.so.2

(gdb)

And a prompt message appears on the embedded end:

ProcESS testem created; pid = 801

Listening on port 1234

Remote debugging from host 222.31.51.147

At this point, the connection between the PC cross debugger and the embedded software is complete. Now you can set actions such as breakpoints for program operation in VIM; the input and output of the embedded software needs to be completed on the embedded end. Here, first set breakpoints for the code through commands, then use the continue command to continue the program (note that run is not needed here, because when the debugger is connected to the embedded end, the debugged embedded software has already started running), and use the next command to implement step debugging of the program. The VIM during the debugging process is shown in Figure 3.

Figure 3 VIM is cross-debugging

The test code in the figure is to let the user input 5 numbers, and then output them after sorting. The corresponding input and output are reflected on the embedded end. Corresponding to Figure 3, the input action needs to be performed on the embedded end at this time:

Listening on port 1234

Remote debugging from host 222.31.51.147

Enter 10 numbers:

a[0]=25

a[1]=56

a[2]=……

From Figure 3, we can clearly see where the breakpoint is set and where the program is currently stepping. When the program runs to line 17 in Figure 3 for the first time, press F8 to open the variable value observation window, and then execute three commands "cr i", "cr j", and "cr a[i]" in succession. In this way, the value of the variable can be monitored in real time in the variable observation window, as shown in Figure 4.

Figure 4 VIM with real-time variable value monitoring window

This debugging mode provides support for all gdb command functions, and when a bug is found, you can terminate debugging through the q command, then press F9 to exit the debugging mode, and then continue to modify the source code.

As for the debugging of embedded software on the local PC before, the process is the same as debugging software running on embedded devices, except that there is only one remote connection process. So far, the debugging of embedded software in VIM has been realized.

3 Conclusion

The widespread application of embedded Linux systems has put forward higher requirements for the efficiency of embedded software development and debugging environments. The tool chain provided by GNU that supports cross-compilation and debugging is a good choice, especially the gdb debugging tool that fully meets the special needs of "cross-compilation" of embedded software; moreover, the powerful VIM editor can integrate the gdb debugger, thereby realizing the debugging function of embedded software in VIM.