[PATCH]: Re: gdb.base/pending.exp failures

[Jeff Johnston]

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  <jjohnstn@redhat.com>

         * 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.
> 
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pendfix.patch
URL: <http://sourceware.org/pipermail/gdb/attachments/20040205/7cbd0bd9/attachment.ksh>