From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2E7363858D33; Mon, 16 Jan 2023 10:43:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2E7363858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1673865821; bh=MGuYV7X8xVVblUdC2xe4fGPytRWOGIR+tV8DTefVGYc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eCEAjI22BCKnO1NPKZG938y4GOhFto1RndDvEDDFw4O8bi6mNXjfSb8EEYXtE1R0w Mkb8rPC0qXg3xkiygerJl5YpOjSmIQv9AFSqFvzBaDQSX87Ar3Qwcle3Ngxn4fIUgx UUajFo9vzNqR245RjpxeERP+ilngHnLQRwEfllY4= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug record/29721] [gdb, record, aarch64] FAIL: gdb.reverse/solib-precsave.exp: reverse-next third shr1 Date: Mon, 16 Jan 2023 10:43:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: record 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: Message-ID: In-Reply-To: References: 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=3D29721 --- Comment #16 from Tom de Vries --- First sign of trouble: ... [infrun] bpstat_check_breakpoint_conditions: incorrect frame {stack=3D0xfffffffff320,code=3D0x0000fffff7f9d594,!special} not {stack=3D0xfffffffff330,code=3D0x0000fffff7f9d594,!special}, not stopping ... Using additional_flags=3D-fasynchronous-unwind-tables works around this. On x86_64, using additional_flags=3D-fno-asynchronous-unwind-tables to drop= the cfi info, the problem doesn't trigger. With x86_64, we have: ... 000000000000050a : 50a: 55 push %rbp 50b: 48 89 e5 mov %rsp,%rbp 50e: 48 89 7d f8 mov %rdi,-0x8(%rbp) 512: 90 nop 513: 5d pop %rbp 514: c3 ret ... and at the first insn: ... 1: /x $pc =3D 0x7ffff7ff150a 2: /x $sp =3D 0x7fffffffdad8 3: /x $rbp =3D 0x7fffffffdaf0 (gdb) info frame Stack level 0, frame at 0x7fffffffdae0: rip =3D 0x7ffff7ff150a in shr1; saved rip =3D 0x4005df called by frame at 0x7fffffffdb00 Arglist at 0x7fffffffdad0, args:=20 Locals at 0x7fffffffdad0, Previous frame's sp is 0x7fffffffdae0 Saved registers: rip at 0x7fffffffdad8 ... and at the last insn: ... 1: /x $pc =3D 0x7ffff7ff1514 2: /x $sp =3D 0x7fffffffdad8 3: /x $rbp =3D 0x7fffffffdaf0 (gdb) info frame Stack level 0, frame at 0x7fffffffdae0: rip =3D 0x7ffff7ff1514 in shr1; saved rip =3D 0x4005df called by frame at 0x7fffffffdb00 Arglist at 0x7fffffffdaf0, args:=20 Locals at 0x7fffffffdaf0, Previous frame's sp is 0x7fffffffdae0 Saved registers: rip at 0x7fffffffdad8 ... the same frame address (as well as the same $sp and $fp). On aarch64 (with additional_flags=3D-fno-omit-frame-pointer additional_flags=3D-mno-omit-leaf-frame-pointer added, to have more compara= ble code), we have: ... 0000000000000594 : 594: a9be7bfd stp x29, x30, [sp, #-32]! 598: 910003fd mov x29, sp 59c: f9000fa0 str x0, [x29, #24] 5a0: d503201f nop 5a4: a8c27bfd ldp x29, x30, [sp], #32 5a8: d65f03c0 ret ... and at the first insn: ... 1: /x $pc =3D 0xfffff7f9d594 2: /x $sp =3D 0xfffffffff320 3: /x $x29 =3D 0xfffffffff320 (gdb) info frame Stack level 0, frame at 0xfffffffff320: pc =3D 0xfffff7f9d594 in shr1; saved pc =3D 0x400718 called by frame at 0xfffffffff340 Arglist at 0xfffffffff320, args:=20 Locals at 0xfffffffff320, Previous frame's sp is 0xfffffffff320 ... and at the last insn: ... 1: /x $pc =3D 0xfffff7f9d5a8 2: /x $sp =3D 0xfffffffff320 3: /x $x29 =3D 0xfffffffff320 (gdb) info frame Stack level 0, frame at 0xfffffffff340: pc =3D 0xfffff7f9d5a8 in shr1; saved pc =3D 0xfffff7d68fa0 called by frame at 0xfffffffff490 Arglist at 0xfffffffff320, args:=20 Locals at 0xfffffffff320, Previous frame's sp is 0xfffffffff340 Saved registers: x29 at 0xfffffffff320, x30 at 0xfffffffff328 ... so a different frame address (while having the same $sp and $fp). --=20 You are receiving this mail because: You are on the CC list for the bug.=