Re: [EXT] Re: gdb does not stop at printf for ppc

["Billie Alsup \(balsup\) via Gdb" <gdb@sourceware.org>]

I have a similar problem with other functions.  I discovered that the linker --wrap option no longer wraps what I was expecting.  For example, wrapping strtoul stopped working with a new glibc, as what was really being invoked was _isoc23_strtoul (and apparently the linker never sees the symbol strtoul).   I think it is related  to the use of asm in the REDIRECT macros for such functions, which I'm guessing is similar to how printf is being redirected in this thread.


extern unsigned long int __REDIRECT_NTH (strtoul,
                                         (const char *__restrict __nptr,
                                          char **__restrict __endptr,
                                          int __base), __isoc23_strtoul)
     __nonnull ((1));



________________________________________
From: Libc-help <libc-help-bounces~balsup=cisco.com@sourceware.org> on behalf of Peter Bergner via Libc-help <libc-help@sourceware.org>
Sent: Thursday, October 2, 2025 11:12 AM
To: Florian Weimer <fweimer@redhat.com>; Peter Bergner via Libc-help <libc-help@sourceware.org>
Cc: Michael Meissner <meissner@linux.ibm.com>; Carl Love <cel@linux.ibm.com>; libc-alpha@sourceware.org <libc-alpha@sourceware.org>; Segher Boessenkool <segher@kernel.crashing.org>; gdb@sourceware.org <gdb@sourceware.org>; Surya Kumari Jangala <jskumari@linux.ibm.com>
Subject: Re: [EXT] Re: gdb does not stop at printf for ppc
 
On 10/2/25 11:58 AM, Florian Weimer wrote:
> * Peter Bergner via Libc-help:
>
>> Ok, it's an even bigger problem than we thought.  I'm surprised no one
>> else has hit this before us.
>
> We've encountered it with fortification and IFUNC resolvers.  It used to
> be considered a user error.

Yeah, I don't think we can consider this a user error, since the user
called printf() and so should validly expect that "break printf" in gdb
should work.  It was only the shifty compiler that silently replaced
printf with __printfieee128 that broke everything! :-)



>> Ok, this is promising and yeah, is what Carl and Uli suggested.
>> That said, their comment from the bugzilla:
>>
>>     The new redirected symbols need to be dynamic symbols in case only
>>     the stripped binary is available.
>
> I'd recommend distributions do not strip .symtab on libc.so.6.  I don't
> think making this a dynamic symbol is worth it.  It would have to be a
> compatibility symbol under a separate symbol version, one for each
> variant alias (eight for POWER?).  This is quite a bit of complexity.

I'd be fine with that, if that is what everyone else thinks is best.
Worst case, a distro strips libc.so.6 and we're just back with the
current state of behavior.  Do we know what Debian/Ubuntu and Gentoo
do wrt strpping or not stripping libc.so.6?

I definitely don't like the idea of all of those compatibility symbols!


Peter