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

["cel at us dot ibm.com" <sourceware-bugzilla@sourceware.org>]

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.