From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 694C63858D20; Thu, 12 Jan 2023 01:05:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 694C63858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1673485547; bh=wG0orD11zbqm0Cli8PQzwaK3HHBtPjS7f1mGTG4ymHo=; h=From:To:Subject:Date:From; b=hmQc2PtNvYUsT9lhmKnlJ2LCmTEPioy30hRdXtVlJCIIUGtqxdjXpqWKoVkoGEA+l A7LuCSg7umazrH61pxxlrrJO1F/sMS8Xx4ReqcfDx59qtBnOpFEWNOBrO7wfj0/3Oa yAmX2b/sMuUbJb5ZmvWcvsnY5rgBG37anJQZVX50= From: "cel at us dot ibm.com" To: gdb-prs@sourceware.org Subject: [Bug gdb/29989] New: PowerPC, gdb fails to stop at printf call Date: Thu, 12 Jan 2023 01:05:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 12.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cel at us dot ibm.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29989 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.=20=20 I run the test with the command: make check RUNTESTFLAGS=3D'GDB=3D/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=3D"1",group-id=3D"i1" stopped pre-prompt (gdb)=20 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:=20 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=20 [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] =3D { 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=20=20=20=20=20=20 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=3D0x10000920 "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 du= mped the dwarf for annota1. objd readelf --debug-dump annota1 > annota1.dwarf The file has the following intersting info: DW_AT_external : 1 DW_AT_location : 9 byte block: 3 38 0 2 10 0 0 0 0=20=20=20= =20=20=20=20 (DW_OP_addr: 10020038) <1>: Abbrev Number: 10 (DW_TAG_subprogram) DW_AT_external : 1 DW_AT_name : (indirect string, offset: 0xd5): printf DW_AT_decl_file : 2 DW_AT_decl_line : 24 DW_AT_decl_column : 1 DW_AT_linkage_name: (indirect string, offset: 0xe2): __printfiee= e128 DW_AT_prototyped : 1 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=20 locations where DW_AT_linkage_name exists to see if I see gdb process the D= WARF 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=20=20= =20=20=20=20=20=20=20=20=20=20=20 assume they will be the same, and we only store the last=20=20= =20=20=20=20=20=20=20=20=20 one we see. */ if (*linkage_name =3D=3D nullptr) *linkage_name =3D 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 rea= d, specifically gdb processes the DW_AT_linkage_name for __printfieee128.=20=20 Not sure if I am off in the weeds trying to figure out what the issue is or not. --=20 You are receiving this mail because: You are on the CC list for the bug.=