From mboxrd@z Thu Jan 1 00:00:00 1970 From: Randolph Chung To: Andrew Cagney 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 Message-id: <20040525183043.GH7207@tausq.org> References: <20040522023133.GG7207@tausq.org> <40B38DC8.30601@gnu.org> X-SW-Source: 2004-05/msg00714.html > 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/