Help with break in printf function

Help with break in printf function

[Carl Love]

GDB developers:

I have a few tests that fail on PowerPC that I could use some help to fix in gdb. The issue is you set a breakpoint in the printf function but gdb does not find/stop at the breakpoint.  I think it might have something to do with the fact that the system has support for IEEE 128-bit floating point numbers.

Initially I set a breakpoint in in printf and main for the test program
gdb/testsuite/gdb.base/annota1.c.


(gdb) break printf
Function "printf" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (printf) pending.

gdb) break main
Breakpoint 2 at 0x10000788: file /.../binutils-gdb-printf/gdb/testsuite/gdb.base/annota1.c, line 15.

Then run to main

(gdb) r
Starting program: /home/carll/GDB/build-printf/gdb/testsuite/outputs/gdb.base/annota1/annota1 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 2, main ())
    at /.../binutils-gdb-printf/gdb/testsuite/gdb.base/annota1.c:15

I then single step to the print statement in main.


gdb) s
23	  printf ("value is %d\n", value);
(gdb) s
Downloading source file /usr/src/debug/glibc-2.37-16.fc38.ppc64le/stdio-common/../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
___ieee128_printf (format=0x100008f0 "value is %d\n")                                                    
    at ../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c:29
29	  done = __vfprintf_internal (stdout, format, ap,
 
I can see that it stepped into an ieee128-printf.c file. But when I print out the location of the breakpoints

(gdb) maint info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00007ffff7a6f8b8 in __printf at printf.c:28 inf 1
1.1                         y   0x00007ffff7a6f8b8 in __printf at printf.c:28 inf 1
2       breakpoint     keep y   0x0000000010000788 in main 
                                                   at /.../gdb/testsuite/gdb.base/annota1.c:15 inf 1

I see the breakpoint is set in a different file printf.c.

So, it would seem that GDB doesn't know that the test is compiled to use the print routine in ieee128-printf.c?
I am guessing the issue has to do with gdb reading the binary to determine what files/functions the program uses.  Not sure where/how GDB parses the binary to figure out where the library functions are located.  I am guessing gdb is not getting the correct function/file information from the binary.  If anyone has any ideas on how to go about debugging/fixing the issue, the help would be greatly appreciated.  Thanks.

                                  Carl 

Re: Help with break in printf function

[Andreas Schwab]

On Jan 26 2024, Carl Love wrote:

> I then single step to the print statement in main.
>
>
> gdb) s
> 23	  printf ("value is %d\n", value);
> (gdb) s
> Downloading source file /usr/src/debug/glibc-2.37-16.fc38.ppc64le/stdio-common/../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c
> ___ieee128_printf (format=0x100008f0 "value is %d\n")                                                    
>     at ../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c:29
> 29	  done = __vfprintf_internal (stdout, format, ap,
>  
> I can see that it stepped into an ieee128-printf.c file. But when I print out the location of the breakpoints
>
> (gdb) maint info breakpoints
> Num     Type           Disp Enb Address            What
> 1       breakpoint     keep y   0x00007ffff7a6f8b8 in __printf at printf.c:28 inf 1
> 1.1                         y   0x00007ffff7a6f8b8 in __printf at printf.c:28 inf 1
> 2       breakpoint     keep y   0x0000000010000788 in main 
>                                                    at /.../gdb/testsuite/gdb.base/annota1.c:15 inf 1
>
> I see the breakpoint is set in a different file printf.c.

That's because nothing in the program actually calls the printf
function, it calls ___ieee128_printf instead.  The function in printf.c
implements the pre-ieee128 printf function, and due to compiler magic
the printf call in the source is rewritten to __ieee128_printf.

> So, it would seem that GDB doesn't know that the test is compiled to use the print routine in ieee128-printf.c?

Probably GDB needs to implement some magic to know that printf and
__ieee128_printf are somewhat related.  Similar issues exist with
__isoc99_ and __isoc23_ prefixed symbols for all architectures.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Help with break in printf function

[Carl Love]

Andreas:

On 1/27/24 01:24, Andreas Schwab wrote:
>> So, it would seem that GDB doesn't know that the test is compiled to use the print routine in ieee128-printf.c?
> Probably GDB needs to implement some magic to know that printf and
> __ieee128_printf are somewhat related.  Similar issues exist with
> __isoc99_ and __isoc23_ prefixed symbols for all architectures.

Yes, I was guessing there something going on in the compiler with regards to the ieee128-printf which GDB needs to know about.  The GDB dwarf info

 Relocation section '.rela.plt' at offset 0x498 contains 4 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000010020010  000100000015 R_PPC64_JMP_SLOT  0000000000000000 __libc_start_main@GLIBC_2.34 + 0
000010020018  000300000015 R_PPC64_JMP_SLOT  0000000000000000 signal@GLIBC_2.17 + 0
000010020020  000400000015 R_PPC64_JMP_SLOT  0000000000000000 __printfieee128@GLIBC_2.32 + 0
000010020028  000500000015 R_PPC64_JMP_SLOT  0000000000000000 __gmon_start__ + 0

has the printfieee128 function listed.  I was trying to figure out where/how GDB processes the
DWARF information.  The first thing. we would need to have a check when reading the sym name to flag that the string __printfieee128@GLIBC* was seen.  Then implement the magic, as you said, to associate it with the printf function to have the breakpoint changed from printf to _printfieee128@GLIBC.  I have no idea how to go about doing that???
Any ideas how one might try to do that?  

                       Carl 

Re: Help with break in printf function

[Tom Tromey]

>>>>> "Carl" == Carl Love <cel@linux.ibm.com> writes:

Carl> Yes, I was guessing there something going on in the compiler with
Carl> regards to the ieee128-printf which GDB needs to know about.  The
Carl> GDB dwarf info

Carl>  Relocation section '.rela.plt' at offset 0x498 contains 4 entries:
Carl>   Offset          Info           Type           Sym. Value    Sym. Name + Addend
Carl> 000010020010  000100000015 R_PPC64_JMP_SLOT  0000000000000000 __libc_start_main@GLIBC_2.34 + 0
Carl> 000010020018  000300000015 R_PPC64_JMP_SLOT  0000000000000000 signal@GLIBC_2.17 + 0
Carl> 000010020020  000400000015 R_PPC64_JMP_SLOT  0000000000000000 __printfieee128@GLIBC_2.32 + 0
Carl> 000010020028  000500000015 R_PPC64_JMP_SLOT  0000000000000000 __gmon_start__ + 0

Carl> has the printfieee128 function listed.

This looks like ELF symbols, not DWARF.

Carl> I was trying to figure out where/how GDB processes the DWARF
Carl> information.  The first thing. we would need to have a check when
Carl> reading the sym name to flag that the string
Carl> __printfieee128@GLIBC* was seen.  Then implement the magic, as you
Carl> said, to associate it with the printf function to have the
Carl> breakpoint changed from printf to _printfieee128@GLIBC.  I have no
Carl> idea how to go about doing that???  Any ideas how one might try to
Carl> do that?

I guess I wonder what the other issues might be though.  For instance,
if "printf" is actually "__printfieee128", then is there some setting
that might cause "printf" to call some other function?

Anyway, in DWARF it is fine to have multiple symbols with the same name
that point to different addresses; or multiple symbols with different
names pointing to the same address.

So you could arrange (somehow) for "printf" to point to __ieee128_printf
as well as whatever else.  Then "break printf" in gdb would set a
breakpoint at all of them.

Tom