[Bug gdb/29989] New: PowerPC, gdb fails to stop at printf call

[Bug gdb/29989] New: PowerPC, gdb fails to stop at printf call

[cel at us dot ibm.com]

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

            Bug ID: 29989
           Summary: PowerPC, gdb fails to stop at printf call
           Product: gdb
           Version: 12.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: cel at us dot ibm.com
  Target Milestone: ---

The following gdb test cases fail similarly on PowerPC.

gdb.base/annota1.exp
gdb.base/annota3.exp
gdb.server/sysroot.exp

Lets take annota1.exp as an example.  

I run the test with the command:  make check
RUNTESTFLAGS='GDB=/home/carll/bin/gdb gdb.base/annota1.exp '

The log file contents:
...
PASS: gdb.base/annota1.exp: break printf
continue

post-prompt
Continuing.

starting

frames-invalid
value is 7
my_array[2] is 3

exited 0
[Inferior 1 (process 1853544) exited normally]

thread-exited,id="1",group-id="i1"

stopped

pre-prompt
(gdb) 
prompt
FAIL: gdb.base/annota1.exp: continue to printf
...

----------------------
I think it is a little more informative to actually run the test by hand.

I cd to the location of the test binary: 
gdb/testsuite/outputs/gdb.base/annota1

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

(gdb) run
Starting program:
...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 1, main ()
    at .../binutils-gdb-printf/gdb/testsuite/gdb.base/annota1.c:15
15        int my_array[3] = { 1, 2, 3 };  /* break main */

(gdb) break printf
Downloading source file
/usr/src/debug/glibc-2.35-17.fc36.ppc64le/stdio-common/printf.c...
Breakpoint 2 at 0x7ffff7a7cb58: file printf.c, line 28.

(gdb) list
20        signal (SIGUSR1, handle_USR1);
21      #endif
22      
23        printf ("value is %d\n", value);
24        printf ("my_array[2] is %d\n", my_array[2]);

(gdb) break 23
Breakpoint 3 at 0x100007f4: file
.../binutils-gdb-printf/gdb/testsuite/gdb.base/annota1.c, line 23.

(gdb) c
Continuing.

Breakpoint 3, main ()
    at .../binutils-gdb-printf/gdb/testsuite/gdb.base/annota1.c:23
23        printf ("value is %d\n", value);

(gdb) c
Continuing.
value is 7
my_array[2] is 3
[Inferior 1 (process 1854022) exited normally]

So we can see that it didnt' stop at the printf call.

Rerun but this time stop at line 23 and then do a step.

Breakpoint 3, main ()
    at .../binutils-gdb-printf/gdb/testsuite/gdb.base/annota1.c:23
23        printf ("value is %d\n", value);

(gdb) step
0x00007ffff7a94a48 in ___ieee128_printf (format=0x10000920 "value is %d\n")
    at ../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c:24
24      {

We can see that execution stopped in file ieee128-printf.c but gdb set the
breakpoint in file printf.c, line 28.



Per a suggestion that I was given that the issue maybe with the DWARF, I dumped
the dwarf for annota1.

objd readelf --debug-dump annota1 > annota1.dwarf

The file has the following intersting info:
    <af>   DW_AT_external    : 1
    <af>   DW_AT_location    : 9 byte block: 3 38 0 2 10 0 0 0 0       
(DW_OP_addr: 10020038)
 <1><b9>: Abbrev Number: 10 (DW_TAG_subprogram)
    <ba>   DW_AT_external    : 1
    <ba>   DW_AT_name        : (indirect string, offset: 0xd5): printf
    <be>   DW_AT_decl_file   : 2
    <bf>   DW_AT_decl_line   : 24
    <c0>   DW_AT_decl_column : 1
    <c1>   DW_AT_linkage_name: (indirect string, offset: 0xe2): __printfieee128
    <c5>   DW_AT_prototyped  : 1
    <c5>   DW_AT_type        : <0x64>

The thought is that gdb should be using the DW_AT_linkage_name to find the
correct function to set the break point.

I have put print statements into gdb/dwarf2/read.c at the various 
locations where DW_AT_linkage_name exists to see if I see gdb process the DWARF
entry for the __printfieee128.  Specifically:

        case DW_AT_linkage_name:
        case DW_AT_MIPS_linkage_name:
          /* Note that both forms of linkage name might appear.  We             
             assume they will be the same, and we only store the last           
             one we see.  */
          if (*linkage_name == nullptr)
            *linkage_name = attr.as_string ();
          printf("CARLL, scan attributes, case DW_AT_linkage_name %s\n",
                 *linkage_name);
          break;

in cooked_indexer::scan_attributes.  I have been poking around but so far, I
have not been able to find any evidence that the dwarf for annota1 gets read,
specifically gdb processes the DW_AT_linkage_name for __printfieee128.  

Not sure if I am off in the weeds trying to figure out what the issue is or
not.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29989] PowerPC, gdb fails to stop at printf call

[cel at us dot ibm.com]

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

--- Comment #1 from Carl E Love <cel at us dot ibm.com> ---
I was given a suggestion of trying rbreak printf.  When I run this command I
get asked      Make breakpoint pending on future shared library load? (y or
[n]) 
after answering the question a buzillion times you eventually get back to the
gdb prompt.

<function, no debug info> 00000020.plt_call._dl_fatal_printf@@GLIBC_PRIVATE;
Breakpoint 1062 at 0x7ffff7bdb9b4
<function, no debug info> _dl_fatal_printf@plt;
(gdb) 
(gdb) 
(gdb) c
Continuing.

Breakpoint 157, 0x00000000100005a0 in
0000001b.plt_call.__printfieee128@@GLIBC_2.32 ()

not sure exactly where we are but if we do a few step commands we then see

(gdb) s
Single stepping until exit from function __printfieee128@plt,
which has no line number information.

(gdb) s
Single stepping until exit from function __glink_PLTresolve,
which has no line number information.
___ieee128_printf (format=0x10000920 "value is %d\n")
    at ../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c:24
24      {

(gdb) list
19      #include <stdarg.h>
20      #include <libio/libioP.h>
21      
22      extern int
23      ___ieee128_printf (const char *format, ...)
24      {
25        va_list ap;
26        int done;
27      
28        va_start (ap, format);

not sure what all this means yet but thought is was interesting.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29989] PowerPC, gdb fails to stop at printf call

[cel at us dot ibm.com]

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

Carl E Love <cel at us dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |will_schmidt at vnet dot ibm.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29989] PowerPC, gdb fails to stop at printf call

[cel at linux dot ibm.com]

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

--- Comment #2 from Carl E Love <cel at linux dot ibm.com> ---
The issue occurs with the Fedora 38 release.

The issue does not occur with Ubuntu 22.04.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29989] PowerPC, gdb fails to stop at printf call

[cel at linux dot ibm.com]

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

--- Comment #3 from Carl E Love <cel at linux dot ibm.com> ---
This issue occurs with Fedora 38.

The issue does not occur with Ubuntu 22.04.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29989] PowerPC, gdb fails to stop at printf call

[sam at gentoo dot org]

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

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29989] PowerPC, gdb fails to stop at printf call

[cel at linux dot ibm.com]

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

--- Comment #4 from Carl E Love <cel at linux dot ibm.com> ---
Digging into the issue further, the issue is not limited to the printf function
but all of the symbols for the IEEE 128-bit floating point functions that are
redirected in glibc.  

PowerPC supports the IBM 128-bit floating point format and the IEEE 128-bit
floating point format.  The IEEE 128 bit support redirects the various function
calls to the ieee128 versions of the functions.  For example, the printf
function gets linked to the __printfieee128 function at linking time.   Gdb is
not aware of the ​__printfieee128 symbol was redirected from the original
printf symbol so it only sets a breakpoint in the standard printf function. 
GDB fails to break in the redirected printf function.  The printf function is
just one of about 200 IEEE128 bit functions that get remapped for PowerPC.

Ulrich and I have looked at fixing this in gdb by creating hidden symbols for
printf that points to the __printfieee128 function.  Although it is possible to
do, in general it is really messy/hard to do because because of the naming
scheme that was used. The original function was mapped to an ieee128 bit
function with one of the following mappings:

  foo    ->    __fooieee128
  fool   ->    __fooieee128
  foo    ->    __newnameieee128
  foo_r  ->    __fooieee128_r

In GDB, you have to do the reverse mapping from to determine what the original
function name "foo" so you can create a hidden symbol for "foo" that points to
the IEEE 128 bit symbol "__fooiiieee128".  We have tried to come up with a
simple reverse mapping algorithm, but since __fooieee128 can map back to either
foo or fool you have to search the entire list of mappings to determine what
the original name was.  Note, there are also some existing symbol names with
ieee128 in them that are not the result of redirecting function foo to its IEEE
128 equivalent function.  These also cannot be eliminated without going thru
the list of known symbol names that have been redirected.  

A proof of concept patch in gdb which takes the symbol and searches the list of
200+ redirected function names to determine the original symbol name was done
and works.  The issue is maintaining the list of 200+ function mappings in gdb
is fragile and not considered an acceptable solution.

The feeling is the right thing to do is to have glibc emit a local symbol in
the library binary, i.e. printf that points to the redirected symbol, i.e.
__printfieee128.  When the user types "break printf" GDB will set a breakpoint
in the original printf function and in the __printfieee128 function via the
local printf symbol in the glibc library.  

Basically, have glibc create the hidden symbol for each of the 200 or so
redirected functions rather than having gdb create the hidden symbol as was
done in the proof of concept patch.  The advantage of having glibc add the
local symbol to the library binary is it already knows what symbols are being
redirected and gdb doesn't have to maintain a list of mappings.  

The new redirected symbols need to be dynamic symbols in case only the stripped
binary is available.

-- 
You are receiving this mail because:
You are on the CC list for the bug.