From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 606B7385D0FC; Wed, 26 Oct 2022 14:36:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 606B7385D0FC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1666794985; bh=Vifp2wS2+X5MFBrxL1cp8Tj9qBHsFs3jkOaI5fHoij4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Mrq7NclRfJS1h+oLJ5t2PkRKvZx9MQnf0OiL4E/yNlB+4r9Ilft8WjiJDuGBci5DB vOyfQoRN+4b6vKPEW6n6CC8QULo3Ruz3l8XlUkJQ5BPcUmbPR/QyIDp62TTbrk9bZv 8OnzYuOgwF5MFWvJIezInTk26hPGFXHLIjcHMUPQ= From: "blarsen at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug record/29721] [gdb, record, aarch64] FAIL: gdb.reverse/solib-precsave.exp: reverse-next third shr1 Date: Wed, 26 Oct 2022 14:36:24 +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: blarsen at redhat dot com 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 #4 from B. Larsen --- This looks like a completely different issue to what I found. Looking at until 46 main () at /home/tdevries/gdb/src/gdb/testsuite/gdb.reverse/solib-reverse.c= :46 46 return 0; /* end part one */ (gdb) PASS: gdb.reverse/solib-precsave.exp: forward to end part one reverse-next No more reverse-execution history. main () at /home/tdevries/gdb/src/gdb/testsuite/gdb.reverse/solib-reverse.c= :27 27 char* cptr =3D "String 1"; It looks to be the reason I made my patch that changes frame-id calculations for amd64 epilogue unwinder. Essentially, an incorrect frame-id was set as = the owner of the step-resume breakpoint used by reverse-next, GDB never "hit" t= hat breakpoint and went back to the start of the execution history. Is gdb.base/unwind-on-each-insn.exp passing for you? --=20 You are receiving this mail because: You are on the CC list for the bug.=