I have just checked in the accompanying patch which takes Daniel's suggestion of indirectly calling pendfunc1 from the main program. I have tested it on both ia64-linux and i686-linux. -- Jeff J. 2004-02-04 Jeff Johnston * gdb.base/pendshr.c (pendfunc): New function that calls pendfunc1. * gdb.base/pending.c: Call pendfunc instead of pendfunc1. Jeff Johnston wrote: > Daniel Jacobowitz wrote: > >> Just a note of probable-cause: Jeff, on which platforms did you test >> this testcase? I bet it wasn't i386-linux. >> >> > > You're right. I tested ia64, not i386. > >> On Wed, Feb 04, 2004 at 04:01:21PM -0800, David Carlton wrote: >> >> >>> (gdb) break pendfunc1 >>> >>> Breakpoint 1 at 0x804839c >>> >>> (gdb) FAIL: gdb.base/pending.exp: set pending breakpoint >>> >> >> >> This function is in a shared library that hasn't been loaded yet. >> However, on i386-linux (and many other platforms), the call will go >> through a PLT entry, and the entry in the application's symbol table >> will appear as an SHN_UNDEF symbol with a non-zero address pointing at >> the PLT entry. GDB will re-resolve the breakpoint after shared >> libraries have been loaded. This is already-existing functionality. >> >> If you don't want to use dlopen in the test, try setting breakpoints on >> a function not called directly from the executable (i.e. called from >> within the library). >> >> >> > Thanks for the explanation. > >