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

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

[Randolph Chung]

The shlib-call.exp test fails on hppa (also ia64) because it tries to 
add a breakpoint before the inferior is started, so there's no where 
to put the breakpoint. gdb can handle this case if we allow pending 
breakpoints in the test.

this only works on x86 and some other architectures because they put
instructions into the plt; but some architectures put addresses in the
plt.

ok to commit?

randolph

2004-05-21  Randolph Chung  <tausq@debian.org>

	* gdb.base/shlib-call.exp: Allow breakpoint to be added after inferior
	has started.

Index: testsuite/gdb.base/shlib-call.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/shlib-call.exp,v
retrieving revision 1.8
diff -u -p -r1.8 shlib-call.exp
--- testsuite/gdb.base/shlib-call.exp	2 Feb 2004 21:14:33 -0000	1.8
+++ testsuite/gdb.base/shlib-call.exp	22 May 2004 02:18:34 -0000
@@ -291,17 +291,17 @@ send_gdb "set width 0\n" ; gdb_expect -r
 
 # PR's 16495, 18213
 # test that we can re-set breakpoints in shared libraries
-gdb_breakpoint "shr1"
+gdb_breakpoint "shr1" "allow-pending"
 
 # FIXME: should not send "run" explicitly.  Non-portable.
 
 if ![is_remote target] {
-  gdb_test "run" "Starting program:.*Breakpoint 1,.*" \
+  gdb_test "run" "Starting program:.*Breakpoint .,.*" \
 	"run to bp in shared library"
 
   gdb_test "cont" ".*Program exited normally..*"
 
-  gdb_test "run" "Starting program:.*Breakpoint 1,.*" \
+  gdb_test "run" "Starting program:.*Breakpoint .,.*" \
 	"re-run to bp in shared library (PR's 16495, 18213)"
 
   gdb_test "cont" ".*Program exited normally..*"
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

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

[Andrew Cagney]

The shlib-call.exp test fails on hppa (also ia64) because it tries to 
add a breakpoint before the inferior is started, so there's no where 
to put the breakpoint. gdb can handle this case if we allow pending 
breakpoints in the test.

this only works on x86 and some other architectures because they put
instructions into the plt; but some architectures put addresses in the
plt.
ok to commit?
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?

Andrew


2004-05-21  Randolph Chung  <tausq@debian.org>

	* gdb.base/shlib-call.exp: Allow breakpoint to be added after inferior
	has started.

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

[Randolph Chung]

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

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

[Randolph Chung]

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/

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

[Daniel Jacobowitz]

On Fri, May 21, 2004 at 07:31:33PM -0700, Randolph Chung wrote:
> The shlib-call.exp test fails on hppa (also ia64) because it tries to 
> add a breakpoint before the inferior is started, so there's no where 
> to put the breakpoint. gdb can handle this case if we allow pending 
> breakpoints in the test.
> 
> this only works on x86 and some other architectures because they put
> instructions into the plt; but some architectures put addresses in the
> plt.

This is a naming issue only.  Some architectures call the table of
addresses the PLT and have another fancy name for the stubs; other
architectures put the table of addresses in .got.plt in the GOT, and
call the stubs "PLT entries".  Your import stub serves the same purpose
as a PLT entry "normally" would.

This is why I was so confused by your explanation - PLT slots are
"normally" code :)

The difference on HPPA is that the undefined symbol for printf has a
value of 0 instead of a value pointing at the beginning of the import
stub.  Some other architectures do this also.  It's a generally
legitimate thing to do; if we worked really hard at it, we could
reconstruct the address of the import stub by grubbing around in the
text section, symbols, and relocations, but it would be quite
complicated.

> 
> ok to commit?
> 
> randolph
> 
> 2004-05-21  Randolph Chung  <tausq@debian.org>
> 
> 	* gdb.base/shlib-call.exp: Allow breakpoint to be added after inferior
> 	has started.

OK.

-- 
Daniel Jacobowitz