Program image not relocated if it's a solib already loaded by dlopen()

[Simo Melenius <smelenius at nvidia dot com>]

I have an interesting corner case I would like to discuss in depth. Please 
point me to some other mailing list such as gdb-patches if this is too 
developer-heavy. Let's go:

Quick question: is the use case described below even supposed to work?


I have an arm-eabi-linux platform where I use gdb and gdbserver.

I have a program ``foo'' that uses dlopen() to load ``libfoo.so'' which 
contains a function symbol ``foobar''. The program ``foo'' will first load 
the library, wait for some time to let me attach gdbserver, and will then 
call that function.

Assume I'm developing ``libfoo.so'' and am not particularly interested in 
``foo'' itself. So, I start ``foo'', attach gdbserver to it, and invoke 
gdb on the host platform as follows:

   $ arm-eabi-gdb libfoo.so

Then I appropriately use ``target remote'' to connect to the gdbserver and 
issue:

   (gdb) break foobar
   Breakpoint 1 at 0x3a0: file libfoo.c, line 7.
   (gdb) continue
   Continuing.
   Warning:
   Cannot insert breakpoint 1.
   Error accessing memory address 0x3a0: Input/output error.

Based on the low breakpoint pc address, gdb uses the section 
offsets directly from ``libfoo.so'' without ever relocating them against 
the base address where ``libfoo.so'' was actually loaded. I can verify 
this by disassembling the contents of ``libfoo.so'' and looking at the 
offset where gdb wanted to install the breakpoint.

It seems that in some cases gdb treats the program argument a bit 
differently than other images.

In the above case, the corresponding "struct objfile" for the program 
image seems to be constructed before gdb connects to the inferior and 
probes its solib list. When it does that, the objfile for ``libfoo.so'' 
isn't updated appropriately and the non-relocated offsets remain in 
effect.

However, if I invoke gdb as:

   $ arm-eabi-gdb foo

everything works. Then gdb just finds ``libfoo.so'' in the inferior's 
so_list and reads its live address as usual.

It also works if I attach gdbserver to ``foo'' _before_ ``libfoo.so'' is 
loaded: gdb correctly notices that ``libfoo.so'' isn't loaded yet and the 
breakpoint is just made a pending one and is resolved when dlopen() is 
called and the library is loaded.

While this can be worked around, should it work the first way, too?

If it should work, I would appreciate some help in constructing a patch. I 
know what's wrong but I haven't got a clear picture of what would be the 
right way to fix this.


kind regards,
Simo

--
  Simo Melenius, NVIDIA Corporation, smelenius@nvidia.com, http://eu.nvidia.com