remote debugging with kdevelop

[Vladimir Prus]

On Friday 14 April 2006 15:59, Alexander Neundorf wrote:
> Hi,

Hi Alexander,

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

It's svn+ssh://vprus@svn.kde.org/home/kde/branches/work/kdevelop-debugger-mi
but I would not advertise it as fully ready for use. Most functionality works, 
but there can be rough edges still.

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

Certainly, the current setup is pretty confusing.

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

On the MI branch, new command is issued only when the output from the previous 
one is parsed.

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

Yes, I think that can be a reasonable solution.

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

If there's is, I don't know it, and I've run into this problem already -- we 
have something called "nmgdb" ;-)

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

I'll take a look. Most probably KDevelop does not know when when you attach to 
remote program, it's already running.

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

This is likely to be fixed on MI branch. I'll check.

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

If members are structures, then gdb will print the structure completely, which 
indeed can be a problem. MI provides a method to avoid this, but that 
specific part of MI is ever more buggy and undocumented then the rest of it. 
I'm not sure when I get around to implement that more efficient method.

But: do you mean that "print *this" should be be issued at all?

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

It kills the current application.

> 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

You mean, that's not possible programmatically?

> -do load and continue again

That should be handled by:

   (gdb) source /home/alex/bdi2000ecosgdb.conf

What does "Verbindungsaufbau abgelehnt" mean?

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

So:
  1. You can't select files outside of the project
  2. You can't select function and jump to the source

Right?

> Not sure 
> how this could be improved.
>
> 10) With this JTAG debugger hardware breakpoints are used. 

Off-topic, but still: is this a limitation of this specific JTAG debugger, or 
they generally don't support software breakpoints. 


> When setting 
> more than 4 breakpoints, it complained "All hardware breakpoints already in
> use", but this wasn't visible for gdb. 

Did gdb emit any error? In MI branch (unlike prior versions of KDevelop), gdb 
error message are supposed to at least printed. The breakpoint would then 
stay in "pending" state, allowing you to remove some of the other 
breakpoints.

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

Need to think about this.

Thank you very much for feedback. I'm hoping that in near future KDevelop will 
be ideal IDE for embedded systems.

- Volodya