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

[Carl Love]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251002/74583b7d/attachment-0001.htm>