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

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Mathieu" == Mathieu Lacage <mathieu.lacage@gmail.com> writes:

Tom> into it too much since I wasn't aware of anybody really using dlmopen.
Tom> If gdb cannot do this, please file a bug report.

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.

Tom> Once you have this patch, does it really work? ÂIt seems like it would
Tom> work ok for some things, like backtraces, but not other things. ÂE.g.,
Tom> does symbol lookup work properly in the dlmopen case? ÂI would imagine
Tom> that it does or does not depending on the ordering of objfiles in gdb's
Tom> internal list.

Mathieu> If you use the libc loader and run the test program I attached to the
Mathieu> bug report, you will see that it's indeed impossible to put a
Mathieu> breakpoint or print the address of a function located in a binary
Mathieu> loaded with dlmopen [...]

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:

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.

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

Anyway, AFAICT, your patch won't break anything, and it is a step in the
right direction.  So, please check it in.

Tom