Re: Using dlopen and remote debugging

Re: Using dlopen and remote debugging

[Steve Kreyer]

Unfortunately your response did not receive my email service provider til now. I had to read it over the gdb mailing list archives.
Thank you so much for this patch you've suggested there! I've searched nearly 2 days for a solution about this issue, now it works!

Thanks,
Steve


-----Ursprüngliche Nachricht-----
Von: <steve.kreyer@web.de>
Gesendet: 25.02.08 15:23:27
An:  "Dr. Rolf Jansen" <rj@surtec.com>
CC: gdb@sourceware.org
Betreff: Re: Using dlopen and remote debugging


Hi Daniel, hello Rolf,

first, thanks for your answers, but I am afraid Daniel is right. "info shared" says:
  (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) info shared
  No shared libraries loaded at this time.

Is there anything else I can do to debug this library using the gdb sh port?

Thanks and regards,
Steve

-----Ursprüngliche Nachricht-----
Von: "Daniel Jacobowitz" <drow@false.org>
Gesendet: 25.02.08 14:30:52
An: Steve Kreyer <steve.kreyer@web.de>
CC: gdb@sourceware.org
Betreff: Re: Using dlopen and remote debugging


On Mon, Feb 25, 2008 at 01:04:12PM +0100, Steve Kreyer wrote:
>   Breakpoint 1, main () at test2.c:12
>   12 lib_handle = dlopen("/libtest.so", RTLD_NOW);
>   (gdb) n

At this point, what does info shared say?

The SH Linux port of GDB is not well-cared-for.  I suspect it is
missing shared library support entirely.

-- 
Daniel Jacobowitz
CodeSourcery



_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! 
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114




_____________________________________________________________________
Unbegrenzter Speicherplatz für Ihr E-Mail Postfach? Jetzt aktivieren!
http://www.digitaledienste.web.de/freemail/club/lp/?lp=7

Re: Using dlopen and remote debugging

[Daniel Jacobowitz]

On Mon, Feb 25, 2008 at 05:29:33PM +0100, Steve Kreyer wrote:
> Unfortunately your response did not receive my email service
> provider til now. I had to read it over the gdb mailing list
> archives.  Thank you so much for this patch you've suggested there!
> I've searched nearly 2 days for a solution about this issue, now it
> works!

Thanks for testing.  I've checked it in.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Using dlopen and remote debugging

[steve.kreyer]

Hi Daniel, hello Rolf,

first, thanks for your answers, but I am afraid Daniel is right. "info shared" says:
  (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) info shared
  No shared libraries loaded at this time.

Is there anything else I can do to debug this library using the gdb sh port?

Thanks and regards,
Steve

-----Ursprüngliche Nachricht-----
Von: "Daniel Jacobowitz" <drow@false.org>
Gesendet: 25.02.08 14:30:52
An: Steve Kreyer <steve.kreyer@web.de>
CC: gdb@sourceware.org
Betreff: Re: Using dlopen and remote debugging


On Mon, Feb 25, 2008 at 01:04:12PM +0100, Steve Kreyer wrote:
>   Breakpoint 1, main () at test2.c:12
>   12 lib_handle = dlopen("/libtest.so", RTLD_NOW);
>   (gdb) n

At this point, what does info shared say?

The SH Linux port of GDB is not well-cared-for.  I suspect it is
missing shared library support entirely.

-- 
Daniel Jacobowitz
CodeSourcery



_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! 
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114

Re: Using dlopen and remote debugging

[Daniel Jacobowitz]

On Mon, Feb 25, 2008 at 03:21:36PM +0100, steve.kreyer@web.de wrote:
> Is there anything else I can do to debug this library using the gdb sh port?

Well, you could try this untested patch...

The sh-linux-tdep.c parts bring it in line with other Linux ports, but
are not specifically important for your problem.  The configure.tgt
parts fix the fact that "sh4-linux-uclibc" was not recognized as a
Linux system.

-- 
Daniel Jacobowitz
CodeSourcery

2008-02-25  Daniel Jacobowitz  <dan@codesourcery.com>

	* configure.tgt (sh-*-linux*): Match sh*.  Add glibc-tdep.o.
	* sh-linux-tdep.c (sh_linux_init_abi): Use glibc_skip_solib_resolver
	and svr4_fetch_objfile_link_map.
	* Makefile.in (sh-linux-tdep.o): Update.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.984
diff -u -p -r1.984 Makefile.in
--- Makefile.in	20 Feb 2008 15:45:20 -0000	1.984
+++ Makefile.in	25 Feb 2008 14:31:23 -0000
@@ -2703,7 +2703,7 @@ shnbsd-tdep.o: shnbsd-tdep.c $(defs_h) $
 	$(shnbsd_tdep_h) $(solib_svr4_h)
 sh-stub.o: sh-stub.c
 sh-linux-tdep.o: sh-linux-tdep.c $(defs_h) $(osabi_h) $(solib_svr4_h) \
-	$(symtab_h)
+	$(symtab_h) $(glibc_tdep_h)
 sh-tdep.o: sh-tdep.c $(defs_h) $(frame_h) $(frame_base_h) $(frame_unwind_h) \
 	$(dwarf2_frame_h) $(symtab_h) $(gdbtypes_h) $(gdbcmd_h) $(gdbcore_h) \
 	$(value_h) $(dis_asm_h) $(inferior_h) $(gdb_string_h) \
Index: configure.tgt
===================================================================
RCS file: /cvs/src/src/gdb/configure.tgt,v
retrieving revision 1.200
diff -u -p -r1.200 configure.tgt
--- configure.tgt	11 Feb 2008 21:58:41 -0000	1.200
+++ configure.tgt	25 Feb 2008 14:31:23 -0000
@@ -367,11 +367,10 @@ score-*-*)
 	gdb_target_obs="score-tdep.o"
 	;;
 
-# FIXME should that be sh*-*-linux*, perhaps?
-sh-*-linux*)
+sh*-*-linux*)
 	# Target: GNU/Linux Super-H
 	gdb_target_obs="sh-tdep.o sh64-tdep.o sh-linux-tdep.o monitor.o \
-			dsrec.o solib.o solib-svr4.o symfile-mem.o"
+			dsrec.o solib.o solib-svr4.o symfile-mem.o glibc-tdep.o"
 	gdb_sim=../sim/sh/libsim.a
 	build_gdbserver=yes
 	;;
Index: sh-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sh-linux-tdep.c,v
retrieving revision 1.6
diff -u -p -r1.6 sh-linux-tdep.c
--- sh-linux-tdep.c	1 Jan 2008 22:53:12 -0000	1.6
+++ sh-linux-tdep.c	25 Feb 2008 14:31:23 -0000
@@ -23,6 +23,8 @@
 #include "solib-svr4.h"
 #include "symtab.h"
 
+#include "glibc-tdep.h"
+
 static void
 sh_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
 {
@@ -30,6 +32,10 @@ sh_linux_init_abi (struct gdbarch_info i
   set_gdbarch_skip_trampoline_code (gdbarch, find_solib_trampoline_target);
   set_solib_svr4_fetch_link_map_offsets
     (gdbarch, svr4_ilp32_fetch_link_map_offsets);
+  set_gdbarch_skip_solib_resolver (gdbarch, glibc_skip_solib_resolver);
+
+  set_gdbarch_fetch_tls_load_module_address (gdbarch,
+                                             svr4_fetch_objfile_link_map);
 }
 
 /* Provide a prototype to silence -Wmissing-prototypes.  */

Using dlopen and remote debugging

[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

Re: Using dlopen and remote debugging

[Dr. Rolf Jansen]

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

Re: Using dlopen and remote debugging

[Daniel Jacobowitz]

On Mon, Feb 25, 2008 at 10:03:09AM -0300, Dr. Rolf Jansen wrote:
> 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:

Then just set solib-search-path; GDB will look up the basenames.
There is an additional wrinkle involving path separators, since GDB
is likely to think that is bare filename and not a full path.  But it
should be fixed on the GDB side, not on the target side.  This one's
been discussed a few times recently.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Using dlopen and remote debugging

[Dr. Rolf Jansen]

Am 25.02.2008 um 10:31 schrieb Daniel Jacobowitz:

> On Mon, Feb 25, 2008 at 10:03:09AM -0300, Dr. Rolf Jansen wrote:
>
>> 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:
>
> Then just set solib-search-path; GDB will look up the basenames.

I did this to no avail.

> There is an additional wrinkle involving path separators, since GDB
> is likely to think that is bare filename and not a full path.

Yeah, as I said, the host gdb at the Mac does not understand the path  
semantics that is send from gdbserver at Windows.

> But it should be fixed on the GDB side, not on the target side.

I am comfortable with that - fix it however and whenever you want!  
Once it is fixed, I will abandon my quick hack. Until that I have a  
working solution.

> This one's been discussed a few times recently.

Discussions are good, solutions are better - even quick 'n dirty ones.

Rolf

Re: Using dlopen and remote debugging

[Daniel Jacobowitz]

On Mon, Feb 25, 2008 at 01:04:12PM +0100, Steve Kreyer wrote:
>   Breakpoint 1, main () at test2.c:12
>   12 lib_handle = dlopen("/libtest.so", RTLD_NOW);
>   (gdb) n

At this point, what does info shared say?

The SH Linux port of GDB is not well-cared-for.  I suspect it is
missing shared library support entirely.

-- 
Daniel Jacobowitz
CodeSourcery