remote debugging with kdevelop

Fri Apr 14 17:27:09 UTC 2006

On Friday 14 April 2006 14:41, you wrote:
> 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.

This sounds very good :-)

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

In my case the remote program wasn't already running. But I have to use 
"continue" instead of "run" to start it.
This is probably different compared to remote debugging another linux box.

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

This would be nice to have :-)

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

If I open the class in the variable view then it certainly has to be issued. 

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

In which way does it kill it ?
In my case it's impossible to kill it using a signal. 

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

Without a specific plugin for that JTAG debugger, yes.

> > -do load and continue again
>
> That should be handled by:
>
>    (gdb) source /home/alex/bdi2000ecosgdb.conf
>
> What does "Verbindungsaufbau abgelehnt" mean?

"Connection refused".

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

Insight has the nice feature that it recognizes all source files from the ELF 
file, and can navigate directly there. This doesn't match with the 
project-implementation in kdevelop, which only cares about the files 
belonging to the project.
Aynway, it's only a minor issue.

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

It's a limitiation of the combination of debugger and processor, I think.

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

I didn't see any :-/
I only saw the error message in the output of the JTAG debugger terminal (i.e. 
not gdb).

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

/me too :-)

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