Re: [patch/rfa] Allow breakpoing to be added after inferior has started

[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/