Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Andreas Schwab <schwab@suse.de>]

David Miller <davem@davemloft.net> writes:

> From: Daniel Jacobowitz <drow@false.org>
> Date: Tue, 13 May 2008 22:46:40 -0400
>
>> On Tue, May 13, 2008 at 06:10:50PM -0700, David Miller wrote:
>> > > What's different for SPARC in this regard from other targets?  Is it
>> > > lack of a PLT entry (or BFD synthetic symbol for said PLT entry)?
>> > 
>> > There is a PLT entry, and when I disassemble it it looks like
>> > "printf@plt".
>> > 
>> > But when I set a breakpoint it gets set on printf@GLIBC_2.0
>> > instead of the correct printf@@GLIBC_2.4
>> > 
>> > All of my other systems have one non-versioned printf symbol,
>> > so either that is the different or the ordering of the symbols.
>> 
>> Yes, this is probably an impact of the 128-bit long double transition.
>> GDB knows how to set multiple breakpoints on functions with debug
>> info, but not without debug info (a known issue).
>
> My case has full debugging information, or at least it should, via
> /usr/lib/debug/lib/ultra3/libc-2.6.1.so which is where I got those
> above symbols above from.

There is probably no symbol matching printf in the debugging
information.  That's how it looks like on ppc, where the two versions of
printf are just aliases of the internal names __printf and
__ndbl_printf.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."