Re: gdb does not stop at printf for ppc

Re: gdb does not stop at printf for ppc

[Peter Bergner via Gdb]

Adding Carl, Mike, Segher and Surya to the CC for their input, so I'm
leaving Sachin's entire question for them to see.

I'm also CCing the libc-alpha and GDB lists for wider exposure, since
this is an actual BUG.  My reply is at the end of Sachin's questions.


On 9/25/25 2:47 AM, Sachin Monga wrote:
> Hi Stewards
> 
> 
> Summary:
> 
> There is a test case in GDB where printf is getting converted into 
> __printfieee128 when program is compiled with "--no-builtin" flag.
> The program is working fine on a machine with glibc 2.34, but not on 
> another machine where glibc 2.40 is installed.
> 
> 
> Test program:
> $ cat test.c
> #include <stdio.h>
> 
> int
> main ()
> {
>    printf ("Hello World!\n");
>    return 0;
> }
> 
> GDB operation:
> 1. Load the binary
> 2. Break main
> 3. Run
> 4. Once program stops at main, then Break printf
> 5. Continue
> 
> Expected ouput: GDB should stop at printf function
> 
> Actual Output on Machine1(with glibc 2.34) : GDB stop at printf symbol
> 
> Actual Output on Machine2(with glibc 2.40) : GDB does NOT stop at printf 
> symbol
> 
> 
> Analysis:
> Glibc debug package with source is required. Once it is installed.
> Then program is working fine with glibc 2.34, but not where glibc 2.40 
> is installed.
> 
> 
> 1. Install debug info package for glibc
> sudo dnf debuginfo-install glibc
> 
> Machine1: glibc packages
> $ rpm -q glibc glibc-debuginfo glibc-debugsource
> glibc-2.34-168.el9_6.23.ppc64le
> glibc-debuginfo-2.34-168.el9_6.23.ppc64le
> glibc-debugsource-2.34-168.el9_6.23.ppc64le
> 
> 
> 
> Machine2: glibc 2.40 packages
> $ rpm -q glibc glibc-debuginfo glibc-debugsource
> glibc-2.40-28.fc41.ppc64le
> glibc-debuginfo-2.40-28.fc41.ppc64le
> glibc-debugsource-2.40-28.fc41.ppc64le
> ~/GDB/latest_gdb/print$
> 
> 
> I execute additional program to check behaviour in both the machine
> 
> $] cat test_print_map.c
> #include <stdio.h>
> 
> int main(void) {
>      printf("Hello World!\n");
> 
>      // Print address of printf and its ieee128 variant
>      printf("Address of printf:        %p\n", (void*)printf);
> #ifdef __GLIBC__
>      extern int __printfieee128(const char *, ...);
>      printf("Address of __printfieee128: %p\n", (void*)__printfieee128);
> #endif
> 
>      return 0;
> }
> 
> Compilation
> gcc -O0 -g -o test_print_map test_print_map.c --no-builtin
> 
> 
> Machine 2 (with glibc 2.40)
> $ ./test_printf_map
> Hello World!
> Address of printf:        0x7fff806870c0  <---- Same address
> Address of __printfieee128: 0x7fff806870c0        <------ Same address
> Abhay@ltcd97-lp3:~/GDB/latest_gdb/print$
> 
> 
> Machine1 (with glibc 2.34)
> $ ./test_printf_map
> Hello World!
> Address of printf:        0x20002a066980  <-------- Different address
> Address of __printfieee128: 0x20002a082e80     <-------- Different address
> [abhay@kubota print]$
> 
> 
> Based on above output, my assumption are (may be it is not 100% true):
> Here, the compiler + linker decide how to bind the symbol:
> 
> In glibc 2.40 :
> printf is just a strong alias to __printfieee128, so both resolve to the 
> same address at link time.
> 
> In glibc 2.34 :
> printf lives at a different symbol table entry than __printfieee128.
> May be two different definitions or pointing to IO_printf(). I am not sure.
> 
> 
> So the query is why gdb is not able to stop at printf symbol where glibc 
> 2.40 is installed ? Is this a bug in glibc or I am missing something ?
> 
> 
> Regards:
> Sachin.


There is actually a GLIBC bugzilla about this and it's not just printf,
but all IEEE 128-bit floating point functions.  I've assigned it to you now! :-)
I don't remember if the solution in Carl's last comment was actually decided
to be the correct way to "fix" this though:

  https://sourceware.org/bugzilla/show_bug.cgi?id=29989


My guess is the difference between your two systems, is that the newer
system's gcc was built with --with-long-double-format=ieee which causes
gcc to enable -mabi=ieeelongdouble by default, meaning "long double"
is equal to IEEE128 instead of the older -mabi=ibmlongdouble usage,
where "long double" is equal to the IBM128/IBM double-double format.
With -mabi=ibmlongdouble, calls to printf() are directed at the printf
symbol in glibc.  With -mabi=ieeelongdouble, gcc remaps printf() calls
to the __printfieee128 symbol in glibc.  I don't think symbol versioning
would have helped here, since we have to handle calls to both the old
and new printf symbols.  I'll let Mike correct me if I'm wrong. :-)

Obviously, we don't want to make users have to say "break __printfieee128"
in gdb, but rather "break printf" should set breakpoints on both printf and
__printfieee128.  The best way to accomplish that though...I'm not sure
we decided that.  Ie, can we fix this in GLIBC or add a workaround in GDB?

Mike, Segher, Carl, Surya or anyone else, anything else to add?

Peter

Re: gdb does not stop at printf for ppc

[Adhemerval Zanella Netto via Gdb]

On 01/10/25 01:03, Peter Bergner via Libc-help wrote:
> Adding Carl, Mike, Segher and Surya to the CC for their input, so I'm
> leaving Sachin's entire question for them to see.
> 
> I'm also CCing the libc-alpha and GDB lists for wider exposure, since
> this is an actual BUG.  My reply is at the end of Sachin's questions.
> 
> 
> On 9/25/25 2:47 AM, Sachin Monga wrote:
>> Hi Stewards
>>
>>
>> Summary:
>>
>> There is a test case in GDB where printf is getting converted into 
>> __printfieee128 when program is compiled with "--no-builtin" flag.
>> The program is working fine on a machine with glibc 2.34, but not on 
>> another machine where glibc 2.40 is installed.
>>
>>
>> Test program:
>> $ cat test.c
>> #include <stdio.h>
>>
>> int
>> main ()
>> {
>>    printf ("Hello World!\n");
>>    return 0;
>> }
>>
>> GDB operation:
>> 1. Load the binary
>> 2. Break main
>> 3. Run
>> 4. Once program stops at main, then Break printf
>> 5. Continue
>>
>> Expected ouput: GDB should stop at printf function
>>
>> Actual Output on Machine1(with glibc 2.34) : GDB stop at printf symbol
>>
>> Actual Output on Machine2(with glibc 2.40) : GDB does NOT stop at printf 
>> symbol
>>
>>
>> Analysis:
>> Glibc debug package with source is required. Once it is installed.
>> Then program is working fine with glibc 2.34, but not where glibc 2.40 
>> is installed.
>>
>>
>> 1. Install debug info package for glibc
>> sudo dnf debuginfo-install glibc
>>
>> Machine1: glibc packages
>> $ rpm -q glibc glibc-debuginfo glibc-debugsource
>> glibc-2.34-168.el9_6.23.ppc64le
>> glibc-debuginfo-2.34-168.el9_6.23.ppc64le
>> glibc-debugsource-2.34-168.el9_6.23.ppc64le
>>
>>
>>
>> Machine2: glibc 2.40 packages
>> $ rpm -q glibc glibc-debuginfo glibc-debugsource
>> glibc-2.40-28.fc41.ppc64le
>> glibc-debuginfo-2.40-28.fc41.ppc64le
>> glibc-debugsource-2.40-28.fc41.ppc64le
>> ~/GDB/latest_gdb/print$
>>
>>
>> I execute additional program to check behaviour in both the machine
>>
>> $] cat test_print_map.c
>> #include <stdio.h>
>>
>> int main(void) {
>>      printf("Hello World!\n");
>>
>>      // Print address of printf and its ieee128 variant
>>      printf("Address of printf:        %p\n", (void*)printf);
>> #ifdef __GLIBC__
>>      extern int __printfieee128(const char *, ...);
>>      printf("Address of __printfieee128: %p\n", (void*)__printfieee128);
>> #endif
>>
>>      return 0;
>> }
>>
>> Compilation
>> gcc -O0 -g -o test_print_map test_print_map.c --no-builtin
>>
>>
>> Machine 2 (with glibc 2.40)
>> $ ./test_printf_map
>> Hello World!
>> Address of printf:        0x7fff806870c0  <---- Same address
>> Address of __printfieee128: 0x7fff806870c0        <------ Same address
>> Abhay@ltcd97-lp3:~/GDB/latest_gdb/print$
>>
>>
>> Machine1 (with glibc 2.34)
>> $ ./test_printf_map
>> Hello World!
>> Address of printf:        0x20002a066980  <-------- Different address
>> Address of __printfieee128: 0x20002a082e80     <-------- Different address
>> [abhay@kubota print]$
>>
>>
>> Based on above output, my assumption are (may be it is not 100% true):
>> Here, the compiler + linker decide how to bind the symbol:
>>
>> In glibc 2.40 :
>> printf is just a strong alias to __printfieee128, so both resolve to the 
>> same address at link time.
>>
>> In glibc 2.34 :
>> printf lives at a different symbol table entry than __printfieee128.
>> May be two different definitions or pointing to IO_printf(). I am not sure.
>>
>>
>> So the query is why gdb is not able to stop at printf symbol where glibc 
>> 2.40 is installed ? Is this a bug in glibc or I am missing something ?
>>
>>
>> Regards:
>> Sachin.
> 
> 
> There is actually a GLIBC bugzilla about this and it's not just printf,
> but all IEEE 128-bit floating point functions.  I've assigned it to you now! :-)
> I don't remember if the solution in Carl's last comment was actually decided
> to be the correct way to "fix" this though:
> 
>   https://sourceware.org/bugzilla/show_bug.cgi?id=29989
> 
> 
> My guess is the difference between your two systems, is that the newer
> system's gcc was built with --with-long-double-format=ieee which causes
> gcc to enable -mabi=ieeelongdouble by default, meaning "long double"
> is equal to IEEE128 instead of the older -mabi=ibmlongdouble usage,
> where "long double" is equal to the IBM128/IBM double-double format.
> With -mabi=ibmlongdouble, calls to printf() are directed at the printf
> symbol in glibc.  With -mabi=ieeelongdouble, gcc remaps printf() calls
> to the __printfieee128 symbol in glibc.  I don't think symbol versioning
> would have helped here, since we have to handle calls to both the old
> and new printf symbols.  I'll let Mike correct me if I'm wrong. :-)
> 
> Obviously, we don't want to make users have to say "break __printfieee128"
> in gdb, but rather "break printf" should set breakpoints on both printf and
> __printfieee128.  The best way to accomplish that though...I'm not sure
> we decided that.  Ie, can we fix this in GLIBC or add a workaround in GDB?
> 
> Mike, Segher, Carl, Surya or anyone else, anything else to add?
> 
> Peter

This is not only an issue for IBM float128 support, but rather for other places
that we use asm alias (for instance 64 bit time support on some 32 bits abis,
fortify support for some symbols that route to _chk variants, etc.).

And I think Carl's suggestion might work [1], with the following:

---
diff --git a/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c b/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
index 7b1640ceac..d567d98c68 100644
--- a/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
+++ b/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
@@ -33,3 +33,6 @@ ___ieee128_printf (const char *format, ...)
   return done;
 }
 strong_alias (___ieee128_printf, __printfieee128)
+
+asm (".local printf\n"
+     ".set printf, __printfieee128");
---

Breaking point at printf does work:

---
$ cat printf.c
#include <stdio.h>

int main (int argc, char *argv[])
{
  printf ("%La\n", 1.2345L);
}
$ powerpc64le-glibc-linux-gnu-gcc -mabi=ieeelongdouble printf.c -o printf
$ gdb -ex 'set breakpoint pending on' -ex 'b printf' -ex 'r' ./tst-printf-ieeelongdouble
[...]
Breakpoint 1.2, 0x00007ffff7c92528 in ___ieee128_printf (format=format@entry=0x100000d88 "%La\n") at ../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c:24
24      {
---

I don't think we have a better solution, attribute (alias) requires the
target symbol to be pre-defined (which would require to reestructure how
the long double alias as done); nor I think the compiler will be able to
easy synthesize it because afaiu this need to done at the TU of the
alternative implementation.

Do we have the concept of symbol aliases for DWARF?


[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29989#c4

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

[Peter Bergner via Gdb]

Fixing Carl's email.  It seems his old address doesn't work anymore.


>> On 9/25/25 2:47 AM, Sachin Monga wrote:
>>>
>>> There is a test case in GDB where printf is getting converted into 
>>> __printfieee128 when program is compiled with "--no-builtin" flag.
>>> The program is working fine on a machine with glibc 2.34, but not on 
>>> another machine where glibc 2.40 is installed.


> On 01/10/25 01:03, Peter Bergner via Libc-help wrote:
>>
>> There is actually a GLIBC bugzilla about this and it's not just printf,
>> but all IEEE 128-bit floating point functions.  I've assigned it to you now! :-)
>> I don't remember if the solution in Carl's last comment was actually decided
>> to be the correct way to "fix" this though:
>>
>>   https://sourceware.org/bugzilla/show_bug.cgi?id=29989


On 10/1/25 12:20 PM, Adhemerval Zanella Netto wrote:
> This is not only an issue for IBM float128 support, but rather for other places
> that we use asm alias (for instance 64 bit time support on some 32 bits abis,
> fortify support for some symbols that route to _chk variants, etc.).

Ok, it's an even bigger problem than we thought.  I'm surprised no one
else has hit this before us.




> And I think Carl's suggestion might work [1], with the following:
> 
> ---
> diff --git a/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c b/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
> index 7b1640ceac..d567d98c68 100644
> --- a/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
> +++ b/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
> @@ -33,3 +33,6 @@ ___ieee128_printf (const char *format, ...)
>    return done;
>  }
>  strong_alias (___ieee128_printf, __printfieee128)
> +
> +asm (".local printf\n"
> +     ".set printf, __printfieee128");
> ---
> 
> Breaking point at printf does work:
> 
> ---
> $ cat printf.c
> #include <stdio.h>
> 
> int main (int argc, char *argv[])
> {
>   printf ("%La\n", 1.2345L);
> }
> $ powerpc64le-glibc-linux-gnu-gcc -mabi=ieeelongdouble printf.c -o printf
> $ gdb -ex 'set breakpoint pending on' -ex 'b printf' -ex 'r' ./tst-printf-ieeelongdouble
> [...]
> Breakpoint 1.2, 0x00007ffff7c92528 in ___ieee128_printf (format=format@entry=0x100000d88 "%La\n") at ../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c:24
> 24      {
> ---
> 
> I don't think we have a better solution, attribute (alias) requires the
> target symbol to be pre-defined (which would require to reestructure how
> the long double alias as done); nor I think the compiler will be able to
> easy synthesize it because afaiu this need to done at the TU of the
> alternative implementation.

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.

Does your solution work if you strip your test case?


Peter

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

[Carl Love via Gdb]

Peter:

FYI, my IBM Linux email address is now cel@linux.ibm.com.  This is the preferred email for GDB, GCC, Linux communications.

My regular IBM email is carll@us.ibm.com does also work but is not ideal.

Thanks for keeping me in the loop.

                       Carl
________________________________
From: Peter Bergner <bergner@tenstorrent.com>
Sent: Thursday, October 2, 2025 8:57 AM
To: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>; Sachin Monga <smonga@linux.ibm.com>; libc-help@sourceware.org <libc-help@sourceware.org>; libc-alpha@sourceware.org <libc-alpha@sourceware.org>; gdb@sourceware.org <gdb@sourceware.org>
Cc: Segher Boessenkool <segher@kernel.crashing.org>; Michael Meissner <meissner@linux.ibm.com>; Surya Kumari Jangala <jskumari@linux.ibm.com>; Carl Love <carll@us.ibm.com>
Subject: [EXTERNAL] Re: [EXT] Re: gdb does not stop at printf for ppc

Fixing Carl's email.  It seems his old address doesn't work anymore.


>> On 9/25/25 2:47 AM, Sachin Monga wrote:
>>>
>>> There is a test case in GDB where printf is getting converted into
>>> __printfieee128 when program is compiled with "--no-builtin" flag.
>>> The program is working fine on a machine with glibc 2.34, but not on
>>> another machine where glibc 2.40 is installed.


> On 01/10/25 01:03, Peter Bergner via Libc-help wrote:
>>
>> There is actually a GLIBC bugzilla about this and it's not just printf,
>> but all IEEE 128-bit floating point functions.  I've assigned it to you now! :-)
>> I don't remember if the solution in Carl's last comment was actually decided
>> to be the correct way to "fix" this though:
>>
>>   https://sourceware.org/bugzilla/show_bug.cgi?id=29989 


On 10/1/25 12:20 PM, Adhemerval Zanella Netto wrote:
> This is not only an issue for IBM float128 support, but rather for other places
> that we use asm alias (for instance 64 bit time support on some 32 bits abis,
> fortify support for some symbols that route to _chk variants, etc.).

Ok, it's an even bigger problem than we thought.  I'm surprised no one
else has hit this before us.




> And I think Carl's suggestion might work [1], with the following:
>
> ---
> diff --git a/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c b/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
> index 7b1640ceac..d567d98c68 100644
> --- a/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
> +++ b/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
> @@ -33,3 +33,6 @@ ___ieee128_printf (const char *format, ...)
>    return done;
>  }
>  strong_alias (___ieee128_printf, __printfieee128)
> +
> +asm (".local printf\n"
> +     ".set printf, __printfieee128");
> ---
>
> Breaking point at printf does work:
>
> ---
> $ cat printf.c
> #include <stdio.h>
>
> int main (int argc, char *argv[])
> {
>   printf ("%La\n", 1.2345L);
> }
> $ powerpc64le-glibc-linux-gnu-gcc -mabi=ieeelongdouble printf.c -o printf
> $ gdb -ex 'set breakpoint pending on' -ex 'b printf' -ex 'r' ./tst-printf-ieeelongdouble
> [...]
> Breakpoint 1.2, 0x00007ffff7c92528 in ___ieee128_printf (format=format@entry=0x100000d88 "%La\n") at ../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c:24
> 24      {
> ---
>
> I don't think we have a better solution, attribute (alias) requires the
> target symbol to be pre-defined (which would require to reestructure how
> the long double alias as done); nor I think the compiler will be able to
> easy synthesize it because afaiu this need to done at the TU of the
> alternative implementation.

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.

Does your solution work if you strip your test case?


Peter

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

[Florian Weimer via Gdb]

* 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.

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

Thanks,
Florian

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

[Peter Bergner via Gdb]

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

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

[Billie Alsup (balsup) via Gdb]

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

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

[Peter Bergner via Gdb]

On 10/2/25 1:49 PM, Billie Alsup (balsup) wrote:
> 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.

Similar issues, but seem to have different causes.  In your case, it
looks like glibc is doing the redirection.  Maybe the REDIRECT macro
could use Adhemerval's suggestion?

Have you bisected where the behavior you're seeing changed?


In the printf case, glibc simultaneously supports both IBM128 and IEEE128
floating point formats and has separate printf functions for each format,
"printf" for IBM128 and "__printfieee128" for IEEE128.  It is up to the 
compiler to map any calls to printf() to the correct glibc printf function,
so it's the compiler, rather than glibc, that is doing the redirection.

It could be we solve the two problems using the same technique though.

Peter

Re: gdb does not stop at printf for ppc

[Tom Tromey]

>>>>> Adhemerval Zanella Netto via Gdb <gdb@sourceware.org> writes:

I didn't really follow this discussion, but:

> Do we have the concept of symbol aliases for DWARF?

Yes, DWARF can use DW_TAG_imported_declaration.  However gdb's support
for this is incomplete and you'd have to try it out to see if it's
sufficient for this purpose.

Tom

Re: gdb does not stop at printf for ppc

[Adhemerval Zanella Netto via Gdb]

On 03/10/25 16:43, Tom Tromey wrote:
>>>>>> Adhemerval Zanella Netto via Gdb <gdb@sourceware.org> writes:
> 
> I didn't really follow this discussion, but:
> 
>> Do we have the concept of symbol aliases for DWARF?
> 
> Yes, DWARF can use DW_TAG_imported_declaration.  However gdb's support
> for this is incomplete and you'd have to try it out to see if it's
> sufficient for this purpose.
> 
> Tom

Thanks for the information, but it seems that it can not be easily created
by the compiler on C code (typedef creates DW_TAG_typedef and asm function
aliases do not generate DWARF entries); and relying on a possible incomplete
is kinda fragile because we would like to support old gdb releases.

I think the local symbol aliases seems the best strategy.

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

[Peter Bergner via Gdb]

On 10/7/25 12:21 PM, Adhemerval Zanella Netto wrote:
> On 03/10/25 16:43, Tom Tromey wrote:
>> Yes, DWARF can use DW_TAG_imported_declaration.  However gdb's support
>> for this is incomplete and you'd have to try it out to see if it's
>> sufficient for this purpose.
> 
> Thanks for the information, but it seems that it can not be easily created
> by the compiler on C code (typedef creates DW_TAG_typedef and asm function
> aliases do not generate DWARF entries); and relying on a possible incomplete
> is kinda fragile because we would like to support old gdb releases.
> 
> I think the local symbol aliases seems the best strategy.


Ok, then I think we have a plan.  Sachin, how about you use Adhemerval's
local symbol alias solution and place it through some thorough testing?

Peter

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

[Sachin Monga via Gdb]

Thanks Adhemerval/Peter

Ok, I can try for the printf and test it.

Regards:
Sachin.

On Wed, Oct 15, 2025 at 8:05 PM Peter Bergner via Libc-help <
libc-help@sourceware.org> wrote:

> On 10/7/25 12:21 PM, Adhemerval Zanella Netto wrote:
> > On 03/10/25 16:43, Tom Tromey wrote:
> >> Yes, DWARF can use DW_TAG_imported_declaration.  However gdb's support
> >> for this is incomplete and you'd have to try it out to see if it's
> >> sufficient for this purpose.
> >
> > Thanks for the information, but it seems that it can not be easily
> created
> > by the compiler on C code (typedef creates DW_TAG_typedef and asm
> function
> > aliases do not generate DWARF entries); and relying on a possible
> incomplete
> > is kinda fragile because we would like to support old gdb releases.
> >
> > I think the local symbol aliases seems the best strategy.
>
>
> Ok, then I think we have a plan.  Sachin, how about you use Adhemerval's
> local symbol alias solution and place it through some thorough testing?
>
> Peter
>
>

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

[Sachin Monga via Gdb]

Hi Peter/All

 >diff --git a/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c 
b/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
 >index 7b1640ceac..d567d98c68 100644
 >--- a/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
 >+++ b/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
 >@@ -33,3 +33,6 @@ ___ieee128_printf (const char *format, ...)
  >  return done;
  >}
  >strong_alias (___ieee128_printf, __printfieee128)
 >+
 >+asm (".local printf\n"
 >+     ".set printf, __printfieee128");


> ZjQcmQRYFpfptBannerEnd
> Thanks Adhemerval/Peter
>
> Ok, I can try for the printf and test it.

I've tested the solution provided by Adhmerval and it worked well. No 
regressions found on test-suite also.

Also, it rules out the ieee ABI machine logic since 
"-mabi=ieeelongdouble" does not seem to have impact over the reported issue.


Next, my question to the community is that do I need to create aliasing 
for all the symbols as in the list prepared by Carl as discussed in the 
thread ?

For now, I need urgent solution for printf specifically. So, Is it ok to 
proceed and share this change for printf only ?


Regards:
Sachin.

Re: Re: gdb does not stop at printf for ppc

[Peter Bergner via Gdb]

On 11/4/25 10:00 PM, Sachin Monga wrote:
> I've tested the solution provided by Adhmerval and it worked well.
> No regressions found on test-suite also.

Excellent!



> Next, my question to the community is that do I need to create aliasing for
> all the symbols as in the list prepared by Carl as discussed in the thread ?
> 
> For now, I need urgent solution for printf specifically. So, Is it ok to
> proceed and share this change for printf only ?

I think it's fine to submit a patch for printf now and wait on the other
symbols later.  As Adhemerval mentioned, there are more symbols than just
the IEEE128 symbols that need fixing too, so this looks like it'll be a
multi-patch process to fix everything and I don't expect you to fix the
non-IEEE128 symbols.

That said, I think when fixing printf, we should fix the other printf like
functions at the same time, since they're related.  For example, fprintf,
etc.  There shouldn't be too many of those.

Peter