From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 115E8385828D; Thu, 19 Jan 2023 17:30:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 115E8385828D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674149432; bh=VaQiN1KddI/US7ugnViu8hG1sOlji2NfzRlH9P4iG6w=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MkiH+G/wRZV9Z6iUlwyA4fVhUWdLPXnT+fOdJczeoLI3VtwagFk5/P5KNqIV7k0fg Zs7F4wr5skOzS57if1Y2cjZYuJfNjkvshDzRplHB83ZXChVDNHIGmTwpxQOUPJhBPF uBBPeZG0GHIoTqSVcTbe7dNfGUl2BWJsDfmcWTc8= 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: Thu, 19 Jan 2023 17:30:31 +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 #31 from Tom de Vries --- (In reply to B. Larsen from comment #30) > > Say we assume that they are equal if the target contains an epilogue un= winder, but if not, we're handling things more conservatively. This kind o= f fix could be backported to fix the regression that was introduced. >=20 > This sounds ok, but I wonder if "handling things more conservatively" will > regress > [record/16678](https://sourceware.org/bugzilla/show_bug.cgi?id=3D16678). = To > fix that bug I assumed that we knew the frame ID would be the same > throughout the whole function. If we can't rely on that, how are we suppo= sed > to detect a breakpoint being hit in a recursive call? Well, you've fixed that problem for a recursive function with debug info, a= nd for x86_64 without debug info (meaning, also using -fno-asynchronous-unwind-tables to make sure there's no cfi directives). On aarch64 though, I see: ... $ cat test.c extern int factorial (int x); int v; int main() { v =3D 1; factorial(5); return 0; } $ cat test2.c int factorial(int x) { if (x =3D=3D 1) return 1; int result =3D x * factorial(x-1); return result; } $ gcc test2.c -c ; gcc test.c test2.o -g $ gdb a.out Reading symbols from a.out... (gdb) start Temporary breakpoint 1 at 0x40056c: file test.c, line 4. Starting program: a.out=20 Temporary breakpoint 1, main () at test.c:4 4 v =3D 1; (gdb) record (gdb) next 5 factorial(5); (gdb) next 6 return 0; (gdb) reverse-next 0x00000000004005d4 in factorial () (gdb)=20 ... This is essentially the same problem as in this PR ... and I'm proposing th= at we fix it, in a target-independent fashion. I think the following cases can be distinguished: - cfi info present, assume frame ID's accurate, no special handling needed - cfi info not present, but target has an epilogue unwinder , assume frame ID's accurate, no special handling needed - cfi info not present, no epilogue unwinder. Special handling needed, but no need to worry about breaking handling of recursive function, because it's already broken, and the special handling intends to fix it. My naive idea on how to approach this was to instead of doing a step-resume breakpoint at the last insn and resume, do first a single step back, and th= en insert the step-resume breakpoint and resume. This will already fix the aarch64 case. There may be cases where this gives the wrong answer, but AF= AIU those cases are broken anyway. --=20 You are receiving this mail because: You are on the CC list for the bug.=