This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch/rfa] Allow breakpoing to be added after inferior has started
- From: Randolph Chung <randolph at tausq dot org>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sun, 6 Jun 2004 20:04:13 -0700
- Subject: Re: [patch/rfa] Allow breakpoing to be added after inferior has started
- References: <20040522023133.GG7207@tausq.org> <40B38DC8.30601@gnu.org> <20040525183043.GH7207@tausq.org>
- Reply-to: Randolph Chung <randolph at tausq dot org>
Ping? Comments? Can i check this in?
thanks,
randolph
In reference to a message from Randolph Chung, dated May 25:
> > 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/
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/