Re: Using dlopen and remote debugging

["Dr. Rolf Jansen" <rj@surtec.com>]

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 !=  
'/'; q--);
      strcpy (p, q+1);
      free (name);

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.

Best regards

Rolf Jansen


Am 25.02.2008 um 09:04 schrieb Steve Kreyer:
> Hi,
>
> 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.
>  (gdb) c
>  Continuing.
>
>  Breakpoint 1, main () at test2.c:12
>  12 lib_handle = dlopen("/libtest.so", RTLD_NOW);
>  (gdb) n
>  13 foop = dlsym(lib_handle, "foo");
>  (gdb) n
>  15 erg = foop(1, 2);
>  (gdb) p foo
>  No symbol "foo" in current context.
>
> The source code:
> test2.c:
>  #include <dlfcn.h>
>  #include <stdio.h>
>
>  typedef int (*funcp)(int, int);
>
>  int main()
>  {
>    void *lib_handle;
>    funcp foop;
>    int erg;
>
>    lib_handle = dlopen("/libtest.so", RTLD_NOW);
>    foop = dlsym(lib_handle, "foo");
>
>    erg = foop(1, 2);
>    printf("%d\n", erg);
>
>    dlclose(lib_handle);
>
>    return 0;
>  }
> libtest.c:
>  #include <stdio.h>
>
>  int foo(int a, int b)
>  {
>    int erg;
>
>    erg = a + b;
>    return erg;
>  }
>
> Can someone give me a hint on this issue?
>
> TIA,
> Steve
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
>
>