Main Page | Recent changes | Edit this page | Page history

Printable version | Disclaimers | Privacy policy

Not logged in
Log in | Help
 

Cross debugging

From KDevelop

After some approaches I got a setup for cross debugging my application via ethernet. Here are the steps:

1. Step:
prepare a file named e.g. "prepare_target.gdb". This gdbscript is run when gdb starts up.
The contents of this file are:
-----------------
#set remotebreak 1
set $connected=0
shell sleep 1       #this is to give the gdbserver on the target a chance to load?
target remote TARGET_PC:PORT
set $connected=1
#other gdb init stuff goes here
#set solib-absolute-prefix .....
continue # optional... (But KDevelop(3.1.2) behaved badly - out of sync with gdb, so I left it out)
--------------------
Hereby stands TARGET_PC for the IP-Address (or public name) of your target-PC and PORT 
(e.g. 4444) for the port the two computers are communicating with each other.

2. Step:
Include in KDevelop the following line in "project-project 
settings-debug-run gdb-script": /DIR/prepare_target.gdb. (Hereby stands 
DIR for the local directory where your file prepare_target.gdb is 
located). Furthermore you have to make sure, that no entrys are in the 
line "debugging-shell" on that "project-project settings-debug-run 
gdb-script"-page!

3. Step:
I have written a small shell-script on the target-pc which is copying 
the respective project-file and starts the gdbserver. It is looking like:
----------------
#!/bin/bash
dir_target=/home/XXX/     # directory on the target-PC
dir_devPC=work/YYY/       # directory on the develop-PC
File=#$1
remote_target=USER@TARGET_PC   # user on the target-PC, TARGET_PC: IP-address
dev_pc=DEV_PC             # DEV_PC: IP-address or public name of development PC
port=4444                 # example for port
File2copy=USER@$dev_pc:$dir_devPC$File
echo "copying '$File2copy' to $remote_target as '$File'"
scp $File2copy $File
# start gdbserver
gdbserver $dev_pc:$port $File
echo "Finished remote.sh ...."
----------------
I hope the shell-script is self-explaining. Again you can find here the 
specified port like in the first file.
To get rid of the needed password when using scp you can synchronize the two PCs 
(with the respecting users) by using 'ssh-keygen' (see man-page for further details).

4. Step:
How to work with it? I do first making my project, than starting the 
shell-script on the target, then starting the debugger under KDevelop. 
It is not always working perfect (e.g. the behavior when watching 
breakpoints is sometimes strange) but at least it works!
I hope this will help you with your problem.

The strange behaviour can happen if you compile with -O2 optimization (possibly -O ?)
You can also use ssh to launch the gdbserver on the target, however I had trouble 
with this because all the output was redirected to my ssh session and the keyboard 
on the target didn't work (was using Qt Embedded)

With best regards,
Thomas Feuerle
and
Marc :)

PS: More info can be found on http://groups-beta.google.com/group/comp.os.linux.embedded/msg/c3245a344f01fe1f?q=remote+debug+kdevelop&hl=en&lr=&ie=UTF-8&rnum=3 and http://www.kdevelop.org/phorum5/read.php?2,23503

Once this page is complete and detailed it will become part of the user manual, so please help us improve it.



Some tricks and school-boy errors I ran into:

Note that kdevelop (3.1.2) starts gdb with some extra arguments, most significantly -nx which prevents the usual .gdbinit startup file from being processed. You can replicate its contents in the above prepare_target.gdb script.
Another trick which really stumped me (embarrasingly) is that I could never see the GDB output as KDevelop launched it. The GDB tool button on the bottom toolbar is dynamically added, but the toolbar doesn't resize unless you play around with the main window size. Once I could see the tool button - and thus the output, it was easy enough to figure why stuff wasn't loading properly.

I ran into a problem that I had my system-standard shared libraries, but also had a few shared libraries from the program that I was writing that I didn't want to have to mirror the directory structure for. What I essentially wanted was to be able to set multiple solib-absolute-prefix es, which, AFAIK, can't be done.
The workaround is to have no absolute prefix and several search paths, that we give the full path name for:

set solib-absolute-prefix /dev/null/     
set solib-search-path /home/tools/i386-linux/lib/:/home/blah/project/lib/


Note here that the search paths are separated by a colon ':' and we need to add the lib/ on the end. Note also that it goes against advice on the gdb mailing lists by people who seem to know what they're going on about. But it works for me.

To use a cross debugger you can't explicitly specify the name of the GDB executable, so in the debugger options tab for Directory where gdb resides:

/home/tools/bin/i386-linux-

The example here is for a gdb executable called i386-linux-gdb in /home/tools/bin/. KDevelop adds blindly adds 'gdb').

Cheers,
Marc Reilly

Retrieved from "http://www.kdevelop.org/mediawiki/index.php/Cross_debugging"

This page has been accessed 10,855 times. This page was last modified 17:57, 29 June 2007. Content is available under GNU Free Documentation License 1.2.


[Main Page]
Main Page
Community portal
Current events
Recent changes
Help
Donations

Edit this page
Discuss this page
Page history
What links here
Related changes

Special pages
Bug reports