Use of cross-compilation gdb,gdbserver+gdb under Linux and debug core files via GDB

Cross-compiling GDB and Gdbserver

1. Download GDB:
For:
http://ftp.gnu.org/gnu/gdb/
As a general idea, the latest version is the better, so download this version of 7.2. Of course, everything is not absolute.
Let's take gdb-7.2.tar.bz2 this file as an example.
2. Decompression:

$ tar jxvf gdb-7.2.tar.bz2

Note: Little tricks: Linux under the general compression file suffix. tar.bz2 and. tar.gz, which have two or three options for extracting commands that are consistent:

XF (v), the former plus the J option, the latter plus the z option.

3. Enter the directory

$ cd gdb-7.2/

4. Configuration

$./configure--target=arm-linux--program-prefix=arm-linux---prefix=/usr/local/arm-gdb

Note :--target=arm-linux means that the target platform is the Linux kernel running on the ARM architecture ;--program-prefix=arm-linux- is the prefix of the generated executable file. For example, Arm-linux-gdb,--prefix is the directory where the generated executables are installed, and this directory needs to be selected according to the actual situation. If the directory does not exist, it will be created automatically, of course, with sufficient permissions.

5, compile, install

$ make

$ make Install

Fortunately, three subdirectories are generated in the directory specified by--prefix: Bin, lib, share, and the arm-linux-gdb we need is in the bin directory.
If you accidentally look at its size, you will find it is 14MB that big! Oh, my God! Why does it take up so much space? It doesn't matter, we can lose weight for it. That's right! is to use the Strip command!

$ strip Arm-linux-gdb-o arm-linux-gdb-stripped
$ ls-lh
Total 33M

-rwxr-xr-x 1 latelee root 14M 12-14 16:16 arm-linux-gdb

-rwxr-xr-x 1 latelee root 3.1M 12-14 16:25 arm-linux-gdb-stripped

Can see, strip after the file size only 3.1MB, slimming effect is obvious! If you advertise, it's absolutely persuasive.
This file is the cross-debugger that we run on the host after remote debugging: Executing on the host, debugging is the code of another architecture. However, it is not enough to have a debugger for the host. You also need to run a gdbserver on the target board. How did this stuff come about?

1, in just that gdb extracted after the directory: gdb-7.2, enter./gdb/gdbserver subdirectory

Gdbserver

1. CD gdb/gdbserver/

2, configuration:./configure--target=arm-hismall-linux--host=arm-hismall-linux --prefix=/mnt/hgfs/vmshare/ gdbserver7.41/

(again, Target and host are your cross compilers, prefix are installed directories)

  

3. Compiling: Make cc=make cc=arm-hismall-linux-gcc

error occurred:

linux-arm-low.c:in function ' arm_stopped_by_watchpoint ':

linux-arm-low.c:642:error: ' Ptrace_getsiginfo ' undeclared (

first use of this function)

Linux-arm-low.c:642:error: (each undeclared identifier was reported only once

linux-arm-low.c:642:error:for Each function it appears in.)

 

Workaround: Here is a hint that there is no ptrace_getsiginfo this thing, here search Ptrace_getsiginfo path for the header file specified by-I and cross-compiler

 

chain, we might as well go to the cross-compiler tool chain to find out:

cd/usr/local/arm/3.4.5/

grep "Ptrace_getsiginfo" *-nr

find the following information:

arm-linux/sys-include/linux/ptrace.h:27: #define PTRACE_GETSIGINFO 0x4202

arm-linux/include/linux/ptrace.h:27: #define PTRACE_GETSIGINFO 0x4202

distributed/arm-linux/sys-include/linux/ptrace.h:27: #define PTRACE_GETSIGINFO 0x4202

distributed/arm-linux/include/linux/ptrace.h:27: #define PTRACE_GETSIGINFO 0x4202

description Ptrace_getsiginfo is defined in the cross-compiler toolchain: linux/ptrace.h file, then the header file may not be included.

we went to Gdbserver under the linux-arm-low.c inside a look, not well, only: #include <sys/ptrace.h> and not: #include

 

<linux/ptrace.h>, then add in the linux-arm-low.c file :#include < Linux/ptrace.h>, compile again: Make CC=/USR/LOCAL/ARM/3.4.5/BIN/ARM-LINUX-GCC

Success!

32-bit, ARM platform, dynamic link, not strip.
Again, we also reduce its volume:

# Arm-hismall-linux-strip Gdbserver

[[email protected] gdbserver]# ls gdbserver-l

-rwxrwxrwx 1 root root 498279 2012-12-30 06:21 gdbserver

[[email protected] gdbserver]# ls gdbserver-l

-rwxrwxrwx 1 root root 209048 2012-12-30 06:53 gdbserver

Slimming effect is also so obvious!
Note that you must use the cross version of strip, which is the strip tool that you cross the compiler with, mine is Arm-hismall-linux-strip.

[[email protected] gdbserver]# file Gdbserver

gdbserver:elf 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), stripped

Here we generate two heavyweight files:arm-linux-gdb and gdbserver. Their version is consistent, which is very important. We need to download the Gdbserver to the Development Board, which can be done in a variety of ways, including but not limited to NFS. This program needs to be run in the Development Board when debugging. The Arm-linux-gdb debugger is also executed in the host.

Gdb+gdbserver the Use

Starting the Gdbserver on the target system is actually starting gdbserverunder HyperTerminal or minicom . Here gdbserver is placed in the shared directory of the host's NFS settings /home/zzl, which is mounted under the target board /work . The host IP is 192.168.1.1, the target board IP is 192.168.1.33

Super Terminal or minicom

[[Email Protected]]cd/work

[Email protected]]./gdbserver 192.168.1.1:1234 Hello

The prompt appears:
Process/work/hello created:pid=69
Listening on port 1234

Then switch to the host console and run

[[email protected]] Arm-softfloat-linux-gnu-gdb Hello

(GDB) Target remote 192.168.2.33:1234

The prompt appears:
Remote Debugging using 192.168.1.33:1234
[New Thread 80]
[Switching to Thread 80]
0x40002a90 in?? ()
At the same time under minicom prompt:
Remote Debugging from Host 192.168.2.100
(GDB)
When the connection is successful, you can enter various gdb commands such as list,continue,next,step, break And so on the program debugging.

Debugging a core file using GDB

$ gdb--core=core.9128
GNU gdb Asianux (6.0POST-0.20040223.17.1AX)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU general public License, and you are
Welcome to change it and/or distribute copies of it under certain.
Type "Show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "Show warranty" for details.
This GDB is configured as "I386-asianux-linux-gnu".
Core is generated by './a.out '.
Program terminated with signal one, segmentation fault.
#0 0x08048373 in?? ()
(GDB) bt
#0 0x08048373 in?? ()
#1 0xbfffd8f8 in?? ()
#2 0x0804839e in?? ()
#3 0xb74cc6b3 in?? ()
#4 0x00000000 in?? ()

At this time with BT can not see BackTrace, that is, call stack, originally GDB does not know where the symbolic information. Let's tell it:

(gdb) file./a.out
Reading symbols from./a.out...done.
Using host libthread_db Library "/lib/tls/libthread_db.so.1".
(GDB) bt
#0 0x08048373 in Sub () at Foo.c:17
#1 0x08048359 in Main () at Foo.c:8

At this time the backtrace came out.

(GDB) L
8 Sub ();
9 return 0;
10}
11
A static void sub (void)
13 {
int *p = NULL;
15
16
printf ("%d", *p);
(GDB)

for GDBServer problems that Arise

1. the packet error problem occurs when debugging GDBServer.

The main is the virtual machine and the target machine network connection to go through windows, data containment is easy to lose. The Linux system is back to normal.

Use of cross-compilation gdb,gdbserver+gdb under Linux and debug core files via GDB