This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: impossible to resolve symbols in same binary loaded twice with dlmopen
On Tue, Jul 20, 2010 at 9:38 PM, Tom Tromey <tromey@redhat.com> wrote:
> Mathieu> I do not believe that gdb can do this and I could file a bug but it's
> Mathieu> probably going to be hard to fix (beyond my own abilities).
>
> Yeah, that is ok -- please file it anyway.
http://sourceware.org/bugzilla/show_bug.cgi?id=11839
> Actually I am curious about failures even with your loader.
>
> Can you set breakpoints on all instances of a function? ÂDoes printing a
> global variable defined in a dlmopen()d .so always work properly? ÂI
> would guess that you could construct a case where it does not, something
> like:
ahhh. Good point. It works nicely for _static_ variables, but not for
global variables (which I never use).
> File x.c defines a function, file y.c defines a global. ÂCompile into a
> shared library. ÂHave the main program dlmopen the library twice and
> call the function in each one. ÂThen, step into each instance of the
> function and print the address of the global.
(gdb) b main
Breakpoint 1 at 0x400602: file test.c, line 14.
(gdb) r
Starting program: /home/mathieu/code/elf-loader/t
Breakpoint 1, main (argc=1, argv=0x7fffffffe128) at test.c:14
14 void *a = dlmopen (LM_ID_NEWLM, "./libtest.so", RTLD_LAZY);
(gdb) n
15 void *b = dlmopen (LM_ID_NEWLM, "./libtest.so", RTLD_LAZY);
(gdb)
17 call (a, "foo");
(gdb) info sharedlibrary
>From To Syms Read Shared Object Library
0x00007ffff7de8a50 0x00007ffff7df824f Yes ./ldso
0x00007ffff7be6ad0 0x00007ffff7be6cef Yes ./libvdl.so
0x00000037fa81e860 0x00000037fa9262fc Yes (*) /lib64/libc.so.6
0x00007ffff79e52e4 0x00007ffff79e52fa Yes ././libtest.so
0x00007ffff77e42e4 0x00007ffff77e42fa Yes ././libtest.so
(*): Shared library is missing debugging information.
(gdb) b foo
Breakpoint 2 at 0x7ffff79e52e8: file libtest.c, line 5. (2 locations)
(gdb) c
Continuing.
Breakpoint 2, foo () at libtest.c:5
5 return 0;
(gdb) p &g_global
$4 = (int *) 0x7ffff7be543c
(gdb) p &g_static
$5 = (int *) 0x7ffff7be5438
(gdb) c
Continuing.
Breakpoint 2, foo () at libtest.c:5
5 return 0;
(gdb) p &g_global
$6 = (int *) 0x7ffff7be543c
(gdb) p &g_static
$7 = (int *) 0x7ffff79e4438
(gdb)
> The reason I think this will fail is that I am not sure that gdb will do
> the symbol search properly. ÂI suspect it will always find the first
> instance of the global, not the one in the current objfile.
>
> Maybe I'm wrong about this, though :-)
Indeed. Shall I file a bug ? Maybe you can also give me a hint on
where I can fix it ? It might be a nice change from writing the
thesis.
> Anyway, AFAICT, your patch won't break anything, and it is a step in the
> right direction. ÂSo, please check it in.
I don't have commit rights, and, really, it's better for you if I don't :)
Mathieu
--
Mathieu Lacage <mathieu.lacage@gmail.com>