Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Simo Melenius <smelenius@nvidia.com>
To: gdb@sourceware.org
Subject: Program image not relocated if it's a solib already loaded by  dlopen()
Date: Fri, 16 Apr 2010 19:20:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.00.1004162219280.1072@geist> (raw)


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


             reply	other threads:[~2010-04-16 19:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-16 19:20 Simo Melenius [this message]
2010-04-19 14:22 ` Daniel Jacobowitz
2010-04-19 15:42   ` Simo Melenius

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.00.1004162219280.1072@geist \
    --to=smelenius@nvidia.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox