remote debugging with kdevelop

Fri Apr 14 14:01:08 UTC 2006

Hi,

yesterday I had the chance to do some remote debugging with kdevelop.
Some words about the environment:
we are using an ARM processor which runs the eCos operating system 
( http://ecos.sourceware.org ). eCos applications are linked together with 
the operating system and all libraries to one executable image.
I used an Abatron BDI2000 JTAG debugger (http://www.abatron.ch/ ). We avoid 
using dynamic memory allocation, so we end up with a bunch of global static 
C++ objects, which have everything else as members. Compiler is gcc 3.4.
I used kdevelop from the 3.4 branch as of wednesday.

So, short summary: it works, has some issues and one bug but is usable without 
real problems.

Should I have used the MI branch ? Where is this branch located ?

For remote debugging I have to tell gdb where to debug:

target remote bdi2000:2001

bdi2000 is the "host name" of the JTAG debugger, 2001 is obviously the port. 
( There are also other ways for remote debugging possible, e.g. over a serial 
line:
target remote /dev/ttyS0
set remotebaud 115200 )

After that the executable has to be transferred to the target:
load

This can take quite some time, i.e. more than 1 minute. With the normal gdb 
interface there is no progress information, with the machine interface gdb 
reports progress information.

I did this by setting up a gdb script which contained just these two line 
target remote bdi2000:2001
load
and entered this as the "Run gdb script" in the debugger config dialog.
Putting it at the first position "Config gdb script" didn't work, kdevelol the 
issued a "run" which doesn't work for eCos applications.

So, here are several things which can be improved:
1) explicit support for remote debugging, i.e. specifing the method (TCP/IP, 
serial,, ...) and the required parameters (host name and port, device and 
baudrate)

2) very important: explicit support for "load", i.e. providing feedback. With 
the script as I did it I saw in the gdb console the two commands:
load
...
backtrace
...

and the only sign that there was something going on was the LED of the JTAG 
debugger. It would be nice if the "backtrace" wouldn't be issued before the 
previous command hasn't finished.

3) using three scripts for "Remote debugging" in the debugger config dialog it 
is possible to get everything working, but it feels a bit strange to have to 
create these script files externally and them select them there.
Maybe it would be a better idea to have three multi-line-edits there which can 
be used to enter these scripts and which will then be saved automatically and 
given transparently to gdb, so that the user doesn't have to deal with the 
files directly.

So much about how to get it running.

4) The config entry "Directory where gdb resides" is a bit strange. I use 
"arm-elf-gdb", and it would have felt much more natural to just 
select /usr/local/bin/arm-elf-gdb there, but instead I had to create a 
symlink from /opt/ecos/bin/gdb to /usr/local/bin/arm-elf-gdb
Is there a special reason why there is only a directory to chose instead of 
the actual gdb executable ?

5) Starting the program is done using the "continue" command for eCos 
applications. With the simple script given above I could simply select 
"Continue" and it worked. But somewhere there must be a "Run" hardcoded in 
kdevelop.

6) The bug: "Interrupt" didn't work correctly.
it interrupted execution, but kdevelop didn't realize this:

(gdb) info args  
this = (Cyg_Flag * const) 0xe7af38 
init = 0 
(gdb) info local  
No locals. 
(gdb) continue  

Program received signal SIGSTOP, Stopped (signal). 
0x50011e60 in ?? ()

That's what I saw in the gdb console window. But after that still only "Stop" 
and "Interrupt" where enabled in the kdevelop GUI.
Doing this manually in gdb, i.e. pressing ctrl-c, produced the same output, 
execution stopped, and I could enter "continue" to continue.

7) "print *this" can be very slow.
As I mentioned, I have a bunch a big global objects, which have basically 
everything else of the firmware application as members. When watching the 
variables "print *this" was issued from time to time. When debugging locally 
this is probably to problem, but doing this remotely can take very long, more 
than 30 seconds for some objects.
I'm not sure if anything can be done to improve the situation. It seems that 
"print *this" recursively gets all data from all members of the object.
Can this be also done non-recursive ? Maybe with the MI interface ?

8) Restart doesn't work.
That's what kdevelop did:

(gdb) info local  
No symbol table info available. 
(gdb) frame 0  
#0  0x50011e78 in ?? () 
(gdb) kill  
(gdb) tty /dev/pts/29  
(gdb) source /home/alex/bdi2000ecosgdb.conf  
/home/alex/bdi2000ecosgdb.conf:2: Error in sourced command file: 
bdi2000:2001: Verbindungsaufbau abgelehnt. 
(gdb) backtrace  
No stack. 
(gdb) info args  
(gdb) info local  
No frame selected. 
No frame selected.

I don't know exactly what "kill" in gdb does. 
For my scenario (remote debugging an eCos application), the only way to really 
restart the application would be:
-send a "reset" command to the JTAG debugger (i.e. not gdb), which is out of 
scope for kdevelop
-do load and continue again
So, maybe this is not really feasible for kdevelop.

9) With Insight (the Tcl/Tk GUI for gdb) it is possible to select any of the 
source files of the project, and also directly jump to the functions. This is 
probably done using debug information from the ELF file. With kdevelop only 
files part of the project can be directly accessed. Not sure how this could 
be improved.

10) With this JTAG debugger hardware breakpoints are used. When setting more 
than 4 breakpoints, it complained "All hardware breakpoints already in use", 
but this wasn't visible for gdb. I don't know if there is a way to help the 
user a bit in this regard (like a Checkbox "debugger uses hardware 
breakpoints" and a combobox for the maximal number of breakpoints, where you 
would get a warning if you have more than these active at once, but this 
might a bit obscure).

So, that's all I found so far. As you can see, most are not really 
complictated issues, and it worked better than when I tried to do this with 
Eclipse, which just complained that the selected ELF-file is no executable 
and then just refused to start debugging.

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net