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
next 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