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

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

[Simo Melenius]

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

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

[Daniel Jacobowitz]

On Fri, Apr 16, 2010 at 10:20:39PM +0300, Simo Melenius wrote:
> 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

First of all, I assume this is an arm-linux-gnueabi GDB.  If it were
an ARM EABI gdb, you wouldn't get shared library support at all.  But
that may be your problem.

Secondly, don't do this.  If you want to debug libfoo.so, just make
sure GDB has search paths set up, and start GDB on the executable.
Otherwise, it can not find the load map.  No shared library support is
going to work properly in this case.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Simo Melenius]

On Mon, 19 Apr 2010, Daniel Jacobowitz wrote:

> First of all, I assume this is an arm-linux-gnueabi GDB.  If it were
> an ARM EABI gdb, you wouldn't get shared library support at all.  But
> that may be your problem.

Sorry for the confusion, gnueabi it is. And I have shared libraries, and I 
generally can debug them with gdb.

> Secondly, don't do this.  If you want to debug libfoo.so, just make
> sure GDB has search paths set up, and start GDB on the executable.
> Otherwise, it can not find the load map.  No shared library support is
> going to work properly in this case.

Thank you, this is exactly the kind of clarification I was looking for. 
Just wasn't sure of what gdb is supposed to support in the end.


kind regards,
Simo

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