From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5DFD03858C52; Tue, 26 Jul 2022 08:25:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5DFD03858C52 From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints Date: Tue, 26 Jul 2022 08:25:46 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: tdep X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW 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 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2022 08:25:47 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29409 Bug ID: 29409 Summary: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: tdep Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- I. With aarch64, I see: ... FAIL: gdb.opt/inline-small-func.exp: info breakpoints ... In more detail we have: ... (gdb) info breakpoints^M Num Type Disp Enb Address What^M 2 breakpoint keep y 0x00000000004005ec in callee at inline-small-func.c:23^M (gdb) FAIL: gdb.opt/inline-small-func.exp: info breakpoints ... while "at inline-small-func.h:20" is expected. This passes for x86_64. The test-case mentions problems around prologue analysis as the possible culprit: ... # This test simply compiles with optimization and checks that GDB can=20=20= =20=20=20=20=20=20=20=20=20 # do something suitable with the compiled binary. Problems with this=20=20= =20=20=20=20=20=20=20=20=20 # test are most likely to occur when GDB asks the target specific code=20= =20=20=20=20=20=20=20=20=20 # to skip the prologue (gdbarch_skip_prologue). Some targets make use=20= =20=20=20=20=20=20=20=20=20 # of skip_prologue_using_sal, which should be fine, however, some=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 # targets make a poor attempt to duplicate parts of=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 # skip_prologue_using_sal, these targets could easily fail this test.=20=20= =20=20=20=20=20=20=20=20=20 # This is not (necessarily) a problem with this test, but could=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 # indicate a weakness with the target in question.=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 ... So let's compare behaviour between x86_64 and aarch64. II. For x86_64, we have insns: ... 00000000004004a7
: 4004a7: c7 05 77 0b 20 00 00 movl $0x0,0x200b77(%rip) # 601028 4004ae: 00 00 00 4004b1: b8 00 00 00 00 mov $0x0,%eax 4004b6: c3 ret ... and lines: ... CU: inline-small-func.c: File name Line number Starting address View Stmt inline-small-func.c 20 0x4004a7 x inline-small-func.h: inline-small-func.h 20 0x4004a7 1 x inline-small-func.c: inline-small-func.c 23 0x4004b1 x inline-small-func.c - 0x4004b7 ... gdbarch_skip_prologue is only ever called with address 0x4004a7, and returns the same. In more detail, in amd64_skip_prologue we do skip_prologue_using_sal using func_addr 0x4004a7 and get: ... (gdb) p /x post_prologue_pc $7 =3D 0x4004b1 ... However, this line info reliability test fails: ... /* LLVM backend (Clang/Flang) always emits a line note before the=20= =20=20=20=20=20=20=20=20 prologue and another one after. We trust clang and newer Intel=20= =20=20=20=20=20=20=20 compilers to emit usable line notes. */ if (post_prologue_pc && (cust !=3D NULL && cust->producer () !=3D nullptr && (producer_is_llvm (cust->producer ()) || producer_is_icc_ge_19 (cust->producer ())))) return std::max (start_pc, post_prologue_pc); ... so we fall back to amd64_analyze_prologue, which returns 0x4004a7, and the = we bail out due to cache.frameless_p: ... if (cache.frameless_p) return start_pc; ... III. For aarch64, we have insns: ... 00000000004005e4
: 4005e4: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17> 4005e8: b900281f str wzr, [x0, #40] 4005ec: 52800000 mov w0, #0x0 // = #0 4005f0: d65f03c0 ret ... and lines: ... CU: inline-small-func.c: File name Line number Starting address View S= tmt inline-small-func.c 20 0x4005e4 = x inline-small-func.h: inline-small-func.h 20 0x4005e4 1 = x inline-small-func.c: inline-small-func.c 23 0x4005ec = x inline-small-func.c - 0x4005f4 ... Again, gdbarch_skip_prologue is only ever called with the main address: 0x4005e4, but it returns 0x4005ec. In more detail, in aarch64_skip_prologue we do skip_prologue_using_sal using func_addr 0x4005e4 and get: ... (gdb) p /x post_prologue_pc $6 =3D 0x4005ec ... There's no reliability test, and we return post_prologue_pc: ... if (post_prologue_pc !=3D 0) return std::max (pc, post_prologue_pc); ... --=20 You are receiving this mail because: You are on the CC list for the bug.=