This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]