remote debugging with kdevelop

[Roger Larsson]

On fredag 14 april 2006 13.59, Alexander Neundorf wrote:
> 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.

Great. I once implemented the remote debugger support for kdevelop...
Several years later I tried to use it - it was not obvious...

>
> 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 )
I would guess that serial will become more or less obsolete.

>
> After that the executable has to be transferred to the target:
> load
One of many ways... I guess the bdi can debug applications too.

>
> 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.
Ouch... You do not want to redo that to often...

>
> 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,
This is run only once when the host gdb is started

> 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)

I think that a wizard would be better. Generate the scripts but
let you edit to fit your environment exactly.
A wizard especially for bdi would be nice!

>
> 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.

I like this idea. (Maybe save these in the .kdevelop file too... Or save the 
filenames only, show their contenst - to keep things backward compatible)

>
>
> 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 ?
I do not remember. Your way is nicer. It is always possible to take the
dirname. "Debug shell"(? using swedish) is also a bit strange...
(I did this with a x86 target...)

>
> 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.

Hmm. Wrong gdb selected?
Eclipse has got support from a lot of embedded companies AND it does also
run on Windows - It will be a though competitor...

/RogerL