This is the mail archive of the
mailing list for the GDB project.
Re: Using dlopen and remote debugging
- From: "Dr. Rolf Jansen" <rj at surtec dot com>
- To: Steve Kreyer <steve dot kreyer at web dot de>
- Cc: gdb at sourceware dot org
- Date: Mon, 25 Feb 2008 10:03:09 -0300
- Subject: Re: Using dlopen and remote debugging
- References: <firstname.lastname@example.org>
I had a similar problem.
The problem is that gdbserver reports the full path of the loaded
dynamic libraries to gdb, and if you do not exactly take care for
this, then most probably this will be different. If both machines run
the same OS, then you can resolve this by putting the respective
library at both machines at exactly the same absolut path. You might
want to play around with static link files.
In my case this was impossible. The remote machine happened to run
Windows XP and the host Mac OS X. I found no way to let Mac OS X
understand a full path like "C:\path\to\my\exe\and\dll. I needed to
patch gdbserver. In the latest CVS version I changed server.c
beginning at line 528 to:
char *name, *q;
strcpy (p, " <library name=\"");
p = p + strlen (p);
name = xml_escape_text (dll->name);
for (q = name + strlen(name); q >= name && *q != '\\' && *q !=
strcpy (p, q+1);
This removes the path from the .dll-name before reporting it to gdb.
Of course this is a quick hack and with that I need to place the
dynamic libraries into the executable directory.
Optimal would be if gdbserver could report back a relative path by
using cannonical path separators, and let the host gdb assemble a
valid path at the host from it.
Am 25.02.2008 um 09:04 schrieb Steve Kreyer:
I have the following problem: I would like to debug a program on a
remote target. This program loads a shared library with the dlopen
call, but if the library is loaded, gdb on host-side doesn't find
the appropriate debugging symbols of this library.
I've also tried to make use of the solib-search-path and solib-
absolute-path settings but without success. Both, the application
and the library, which is loaded via dlopen, are compiled using the -
g switch of gcc.
I've issued the following steps:
On target side:
$ gdbserver foo:1234 a.out
On host side:
$ sh4-linux-uclibc-gcc -g test2.c -ldl -Wall
$ sh4-linux-uclibc-gcc -g -shared libtest.c -o libtest.so
$ /opt/sh4-linux-uclibc/bin/sh4-linux-uclibc-gdb a.out
(gdb) set solib-search-path /home/skreyer
(gdb) target remote 192.168.1.201:1234
Remote debugging using 192.168.1.201:1234
(gdb) b main
Breakpoint 1 at 0x400608: file test2.c, line 12.
Breakpoint 1, main () at test2.c:12
12 lib_handle = dlopen("/libtest.so", RTLD_NOW);
13 foop = dlsym(lib_handle, "foo");
15 erg = foop(1, 2);
(gdb) p foo
No symbol "foo" in current context.
The source code:
typedef int (*funcp)(int, int);
lib_handle = dlopen("/libtest.so", RTLD_NOW);
foop = dlsym(lib_handle, "foo");
erg = foop(1, 2);
int foo(int a, int b)
erg = a + b;
Can someone give me a hint on this issue?
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!