From: Randolph Chung <randolph@tausq.org>
To: Andrew Cagney <cagney@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfa] Allow breakpoing to be added after inferior has started
Date: Tue, 25 May 2004 18:30:00 -0000 [thread overview]
Message-ID: <20040525183043.GH7207@tausq.org> (raw)
In-Reply-To: <40B38DC8.30601@gnu.org>
> This is sounding a lot like PIE (position independant executable): where
> it isn't possible to determine a breakpoint's true (re-located) location
> until after the inferior has started.
>
> Can you describe the problem in more detail?
sure.
let's say you want to put a breakpoint on "printf" from a dynamically
linked executable. on x86 printf resolves to a dynamic symbol in the
executable that points to the plt slot, and the code contains a jmp
through the plt to printf(). gdb currently puts a breakpoint in the plt.
all this can be resolved before the shared libraries are loaded.
on architectures that uses function descriptors, the strategy is
different.
for example, on hppa, a small stub (import stub) is generated
which loads 2 words from the plt (gp, ip), sets the gp and jumps to the
ip loaded from the plt. the ip points to a plt stub to trigger fixup()
on the first call. the dynamic symbol in the executable has no reference
to the plt slot; the plt slot address is encoded directly into the stub
that is loading the plt (i believe ia64 works in the same way), and
there is no reference from the dynamic symbol entry to the stub
location. as a result, before shared libraries are loaded there is no
(easy) way to put a breakpoint on all calls to a shared library
function. only after shared libraries are loaded will you be able to
resolve printf to the actual entry point in the shared lib and put a
breakpoint there (which is what gdb does automatically):
(gdb) b printf
Function "printf" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (printf) pending.
(gdb) run
Starting program: /home/randolph/dtest
Breakpoint 2 at 0x40556934
Pending breakpoint "printf" resolved
Breakpoint 2, 0x40556934 in printf () from /lib/libc.so.6
as an aside, this is also why ltrace doesn't work on many
architectures.... it assumes you can put a breakpoint into the plt by
following the dynamic symbol information.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
next prev parent reply other threads:[~2004-05-25 18:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-22 2:31 Randolph Chung
2004-05-25 18:17 ` Andrew Cagney
2004-05-25 18:30 ` Randolph Chung [this message]
2004-06-07 3:04 ` Randolph Chung
2004-06-07 15:20 ` Daniel Jacobowitz
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=20040525183043.GH7207@tausq.org \
--to=randolph@tausq.org \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
/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