建立嵌入式gdb调试环境

建立嵌入式gdb调试环境

一.下载gdb-7.1.tar.gz源代码
phil@ubuntu-embedded:~/gdb-7.1$ wget http://ftp.gnu.org/gnu/gdb/gdb-7.1.tar.gz

二．编译 GDB
#tar zxvf gdb-7.1.tar.gz

2.1 编译GDB Client
phil@ubuntu-embedded:~/gdb-7.1$ cd gdb-7.1/
phil@ubuntu-embedded:~/gdb-7.1$ ./configure --target=arm-linux --prerix=`pwd`/rls
phil@ubuntu-embedded:~/gdb-7.1$ make
phil@ubuntu-embedded:~/gdb-7.1$ make install
phil@ubuntu-embedded:~/gdb-7.1$ ls rls/bin/
arm-linux-gdbarm-linux-gdbtuiarm-linux-run
phil@ubuntu-embedded:~/gdb-7.1$ file rls/bin/arm-linux-gdb
rls/bin/arm-linux-gdb: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

2.2 编译GDB Server
#cd ./gdb/gdbserver
#./configure --target=arm-linux --host=arm-linux

三．实战调试
1．编辑文件
# vi gdbtest.c
#include <stdio.h>

int
func(int n){
int sum=0, i;
for (i=0; i<n; i++){
sum += i;
}
return sum;
}

int
main(void)
{
int i;
long result = 0;
for (i=0; i<=100; i++){
result += i;
}

printf("result[1-100] = %d /n", result);
printf("resutl[1-225] = %d /n", func(255));

return 0;
}
# arm-linux-gcc -g gdbtest.c -o gdbtest // 交叉编译
2.下载文件到目标板: gdbtest和gdbserver
假设 host pc ip:192.168.1.45
board ip:192.168.1.180
将文件拷贝到目标板上：
先将gdbtest和gdbserver两个文件拷贝到主机的/tftpboot目录下
在目标板的Linux中运行：
#mount 192.168.1.108:/tftpboot /mnt/nfs
#cd /mnt/nfs
#ls
看是否有gdbtest和gdbserver两个文件。
3.运行调试
client board：
#./gdbserver 192.168.1.45:1234 gdbtest// 目标板上运行gdbtest 监听端口1234

host pc：
#cd /usr/local/arm-gdb/bin/
#copy gdbtest /usr/local/arm-gdb/bin/ // 将前面编译的文件gdbtest拷贝到此目录
#./arm-linux-gdb gdbtest
(gdb)target remote 192.168.1.180:1234 // 连接到开发板 成功后就可以进行调试
(gdb)list or l
(gdb)break func
(gdb)break 22
(gdb)info br
(gdb)continue or c//记住这里不是用run, 因为程序已在Target Board上面由gdbserver启动了。结果输出是在Target Board端

(gdb)next or n
(gdb)print or presult
(gdb) finish// 跳出func函数
(gdb) next
(gdb) quit
建立连接后进行gdb远程调试和gdb本地调试方法相同

说明:
1)目标机上的被调试程序gdbtest, 与主机上的程序gdbtest, 是相同的程序, 但位置不一样,并非是用网络共享的同一个位置的同一个文件, 一个在目标机上 ,一个在主机上, 没有关系.

Remote cross-target debugging with GDB and GDBserver

In theory, GDB, the GNU debugger, can ease the chore of debugging applications running on a Linux-based embedded system. In practice, setting up GDB for this task is a bit of a challenge; it takes some work, and there are some technical hurdles to overcome. However, the benefits of having a way to methodically debug a program instead of guessing what's wrong with it far outweigh the effort involved. Here are some tips for easing the difficulties.
Rather than run a full-blown instance of GDB on the target platform, you can use GDBserver, a program that lets you run GDB on a different machine than the one on which your program is running. The advantage of using GDBserver is that it needs just a fraction of the target resources that GDB consumes, because it implements only the low-level functionality of the debugger -- namely setting breakpoints and accessing the target processor registers and read/write application memory. GDBserver takes control of the application being debugged, then waits for instructions from a remote instance of GDB running on a development workstation.
Typically, the development workstation has a different processor (say, an i686 class processor) than the target platform (which may be ARM, PowerPC, or something else). This means you can't simply use the GDB executable that's installed on the workstation -- you want a cross-targetdebugger. In other words, you have to custom-build GDB from source code.

Building GDB

The following example uses a 7450 PowerPC as the target processor.
Before you begin, you need a communication interface between the PC running GDB and the target platform: either a serial link or, preferably, an Ethernet network connection. You also need a cross-target toolchain: a GNU C compiler (together with a C run-time library and binary utilities, a.k.a. binutils) that runs on the development workstation and generates executables for the target processor. You will build two sets of binaries from the GDB source code:
§ cross-target -- where the host is the development workstation and the target is the target processor
§ native -- where both host and target are the target processor
First download the GDB source code compressed archive, and unpack it:

mkdir -p ~/work/cross/gdb/downloads

cd ~/work/cross/gdb/downloads

wget http://ftp.gnu.org/gnu/gdb/gdb-6.7.1.tar.bz2[/code] 
cd ..

tar xvjf downloads/gdb-6.7.1.tar.bz2

The GDB source package uses the GNU build system, where generating binaries is usually just a few commands away (
./configure ; make ; make install
). But in our case it's a bit tricky: we intend to build binaries for two different host processors, and install the binaries at different locations. So we'll build the binaries in their own directories, instead of the directory into which we unpacked the source package. Furthermore, we'll use the configure script's command-line options to specify the target and host processors, and the installation directory prefix.
To build the cross-target binaries, specify the target architecture with the 
--target
 option. The architecture identifier (here 
powerpc-7450-linux-gnu
) is the prefix of all the cross-toolchain binaries (here the cross compiler binary is 
powerpc-7450-linux-gnu-gcc
).
mkdir -p ~/work/cross/gdb/build/host_x86

cd ~/work/cross/gdb/build/host_x86

../../gdb-6.7.1/configure --prefix=/opt/gdb/powerpc-7450-linux-gnu/cross --target=powerpc-7450-linux-gnu

make

make install

Building the target-native binaries is trickier. For one thing you need to specify the host architecture (same as the target architecture 
powerpc-7450-linux-gnu
). Another issue is missing libraries -- some libraries may not be available in the cross-toolchain, and must be built before you try to build a target-native GDB. This example shows how to succeed when you find a target-native 
termcap
 library is missing (cross building is somewhat different here -- use 
./configure --help
 when in doubt):
cd ~/work/cross/gdb/downloads

wget ftp://ftp.gnu.org/gnu/termcap/termcap-1.3.1.tar.gz[/code] 
cd ..

tar xvzf downloads/termcap-1.3.1.tar.gz

mkdir -p ~/work/cross/gdb/build/termcap

cd ~/work/cross/gdb/build/termcap


export CC=powerpc-7450-linux-gnu-gcc

export RANLIB=powerpc-7450-linux-gnu-ranlib

../../termcap-1.3.1/configure --host=powerpc-7450-linux-gnu --prefix=$HOME/work/cross/termcap

make

make install

One last issue to consider is whether the binaries should be statically linked. This is required if the target platform is missing some of the shared libraries that GDB and GDBserver depend on for normal operation, but the resulting executables are much larger than dynamically linked ones. You can specify static linking by adding the option 
-static
 to the 
LDFLAGS
 environment variable before running 
configure
. Any additional library should also be specified in both 
LDFLAGS
 and 
CPPFLAGS
, as follows:
export LDFLAGS="-static -L$HOME/work/cross/termcap/lib"

export CPPFLAGS="-I$HOME/work/cross/termcap/include"

../../gdb-6.7.1/configure --prefix=/opt/gdb/powerpc-7450-linux-gnu/native --host=powerpc-7450-linux-gnu --target=powerpc-7450-linux-gnu

make

make install

The GNU linker will issue some warnings during the build process. Using some functions (for instance dlopen, gethostbyname, and a few more) in statically linked applications requires at runtime the shared libraries from the GNU C runtime library version used for linking. You may have to install these libraries on the target platform.
Once you've generated the GDBserver executable, copy it to the target platform. You can save some storage space by stripping all the debug information from it first, using the 
powerpc-7450-linux-gnu-strip
 utility.
Adapting the build procedure for a different target processor should only be a matter of using a different architecture identifier.
Usage
To facilitate debugging, you must compile an application with debug information by providing the 
-g
 command line option to the compiler/linker. The resulting executable file may be too big to fit into the storage space available on the target platform, so before moving it there you can strip the debug information from a copy of it using 
powerpc-7450-linux-gnu-strip
, and place the stripped copy on the target platform. The stripped version is to be run with GDBserver on the target platform, and the non-stripped copy is to be loaded into GDB on the development workstation.
Remote debugging is rather straightforward: on the target platform, launch the application with GDBserver, while specifying the host and port for listening to an incoming TCP connection:
gdbserver HOST:PORT PROG [ARGS ...]

On the development workstation, launch the cross-target GDB:
powerpc-7450-linux-gnu-gdb PROG

Be sure to specify the non-stripped executable. At the GDB console, type:
target remote HOST:PORT

break main

continue

These commands will connect GDB to the GDBserver running on the target platform, set a breakpoint at the start of the program, and let it run until it reaches that first breakpoint.
You can also attach GDBserver to a process that's already running:
gdbserver HOST:PORT --attach PID

The process is then stopped, and you can then debug it with a remote GDB.
GDB commands work as expected while debugging a remote application, with a few exceptions -- most notably, the 
run
 command isn't used, since the program is already running when you start the debug session. Another quirk is that if the program is allowed to continue until it exits, then the remote GDBserver will exit too, and the remote session will terminate.
Setting up a working remote debugging environment may seem like too much of hassle to some -- "after all, nothing beats a well placed 
printf
." But with GDB you can both trace and modify code and data flow, and otherwise analyse the behaviour of your code, without explicitly changing any of it. It doesn't magically solve bugs, but it sure helps.
 


Using the 
gdbserver
 program
gdbserver
 is a control program for Unix-like systems, which allows you to connect your program with a remote GDB via 
target remote
---but without linking in the usual debugging stub.

gdbserver
 is not a complete replacement for the debugging stubs, because it requires essentially the same operating-system facilities that GDB itself does. In fact, a system that can run 
gdbserver
 to connect to a remote GDB could also run GDB locally! 
gdbserver
 is sometimes useful nevertheless, because it is a much smaller program than GDB itself. It is also easier to port than all of GDB, so you may be able to get started more quickly on a new system by using 
gdbserver
. Finally, if you develop code for real-time systems, you may find that the tradeoffs involved in real-time operation make it more convenient to do as much development work as possible on another system, for example by cross-compiling. You can use 
gdbserver
 to make a similar choice for debugging.

GDB and 
gdbserver
 communicate via either a serial line or a TCP connection, using the standard GDB remote serial protocol.

On the target machine,
you need to have a copy of the program you want to debug. 
gdbserver
 does not need your program's symbol table, so you can strip the program if necessary to save space. GDB on the host system does all the symbol handling.
To use the server, you must tell it how to communicate with GDB; the name of your program; and the arguments for your program. The syntax is:
target> gdbserver comm program [ args ... ]

comm is either a device name (to use a serial line) or a TCP hostname and portnumber. For example, to debug Emacs with the argument `foo.txt' and communicate with GDB over the serial port`/dev/com1':
target> gdbserver /dev/com1 emacs foo.txt

gdbserver
 waits passively for the host GDB to communicate with it.
To use a TCP connection instead of a serial line:
target> gdbserver host:2345 emacs foo.txt

The only difference from the previous example is the first argument, specifying that you are communicating with the host GDB via TCP. The `host:2345' argument means that 
gdbserver
 is to expect a TCP connection from machine `host' to local TCP port 2345. (Currently, the `host' part is ignored.) You can choose any number you want for the port number as long as it does not conflict with any TCP ports already in use on the target system (for example, 
23
 is reserved for 
telnet
).(3) You must use the same port number with the host GDB 
target remote
 command.
On the GDB host machine,
you need an unstripped copy of your program, since GDB needs symbols and debugging information. Start up GDB as usual, using the name of the local copy of your program as the first argument. (You may also need the `--baud' option if the serial line is running at anything other than 9600 bps.) After that, use 
target remote
 to establish communications with 
gdbserver
. Its argument is either a device name (usually a serial device, like `/dev/ttyb'), or a TCP port descriptor in the form host
:
PORT. For example:
(gdb) target remote /dev/ttyb

communicates with the server via serial line `/dev/ttyb', and
(gdb) target remote the-target:2345

communicates via a TCP connection to port 2345 on host `the-target'. For TCP connections, you must start up 
gdbserver
 prior to using the 
target remote
 command. Otherwise you may get an error whose text depends on the host system, but which usually looks something like `Connection refused'.