Re: impossible to resolve symbols in same binary loaded twice with dlmopen

[Mathieu Lacage <mathieu.lacage@gmail.com>]

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>