#2 Eclipse / GDB

Eclipse IDE is very popular to debug remote application. It uses the cross GDB client installed on the host workstation to connect to the remote GDB server. It requires that the remote target includes a GDB server that is reacheable either from a serial or ethernet connection. eCos provides several means to allow remote debugging, however, this article only present the use of an hardware debugger. Later article will cover eCos GDB stubs feature. The hardware debugger has a GDB server integrated and is used as an interface toward the target. This method is usually more efficient when bringing up new hardware platform. Using the built-in eCos debugging feature seems more suited for application level debugging and has some limitations.

Some of the well known debuggers are:
- Zylin ARM JTAG debugger [5]
- Abatron BDI BDM/JTAG debugger [7]
- PEEDI BDM/JTAG debugger [8]

In usual setup, the workstation is connected to the debugger via ethernet and the debugger to the remote target via the JTAG interface. Debugger can usually be configured via telnet and/or a web interface. The BDI debugger for instance also require a TFTP server accessible on the network to download the initialisation script and the CPU registers definition file.

I. RAM application debugging

This example requires 2 Eclipse plug-in to be installed, the C/C++ Development add-on and the embedded plug-in from Zylin [9]. A BDI debugger is used to interface a PowerPC based target. This example demonstrate a RAM application debugging. In order to load the application to the target external RAM, some minimal CPU registers initialisation must be performed. Two methods are possible. In the former, the CPU registers initialisation sequence is part of the BDI configuration script. This script is executed by the BDI probe after issuing a reset of the target. The second alternative is to compile a ROM or ROMRAM application in charge of setting up the CPU IOs. The ROM or ROMRAM application is programmed on the target FLASH or booting device. The later method is used in this example. The target FLASH is programmed with a ROMRAM application (Boot Loader)

Once the Eclipse plug-in are installed and the BDI configured and connected to the target, open the Debug perspective in Eclipse and create a new Debug configuration entry under the Zylin Embedded debug type. Use Cygwin or Native depending on your host machine. Give it a name (PPC in this case) and select the application to be debugged.

Move to the next tabulation (Debugger) and select the GDB debugger to be used. In this example, the path to the PowerPC debugger is entered.

The last step is to enter the initialisation sequence you wish GDB to execute when starting a debugging session. This is done under the Commands tabulation.

The initialisation steps in this example are:
- target remote : connect to the hardware debugger on port 2001
- mon reset : reset the target CPU
- mon ti : execute a single step
- mon go : run
- mon delay 2000 : let the CPU run for 2 seconds
- mon halt : stop the CPU
- load : load the application in RAM
- stepi : execute a single step in the loaded RAM application

All commands using the mon suffix are commands specific to the Hardare debugger. In this example, the GDB client is first connected to the server (integrated server into the debugger). The CPU is reset and released in order to execute the ROMRAM application present in FLASH. After 2 seconds, all CPU IOs configuration shall be completed. The CPU is halted and the RAM application is loaded. Debugging can start.

II. Here are some of the main GDB commands

GDB Commands
b main
Set breakpoint in the main function
b main.c:123
Set breakpoint in the main.c file at line 123
info b
Display breakpoints information
watch $r1==0xa0a0
Set watchpoint on register value (0xa0a0) hit
ena 1
Enable breakpoint # 1
d b 1
Delete breakpoint # 1
dis 1
Disable breakpoint # 1
Clear breakpoint at current line
clear function
Clear breakpoint at specified function
Let the CPU start executing instruction
Show the source code and line number
Single assembly step
Execute single instruction
Continue until next breakpoint
Print backtrace of all stack frames
Print backtrace of all stack frames
info locals
Print local variables of current stack frame
p n
Display content of a variable n
info regi
Display CPU registers value
disp /i $pc
Will display the current program counter after each step
Load application to memory
add-symbol-file F A
Load symbol file F at the address A
Detach debugger
p /x &(__bss_end)
Display end address of the un-initialized data segment section
p /x &(__bss_start)
Display start address of the un-initialized data segment section
p /x &(_stext)
p /x &(_etext)
Type cast memory
(struct TYPE *) Addr
set debug remote
Can be used to monitor the exchange of GDB packets
set logging on
Can be use to log all GDB output to a log file for further debugging