From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 130BA385829C; Thu, 14 Mar 2024 10:24:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 130BA385829C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1710411865; bh=SDVYWmWWcoVrZiNbbL5KPWKaMvRKCM7S28cNgeXGKeo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=sTY0C39NhrvZwMxszThKt+8yvelIeRSVHknoFN0g7HSOdSVGozktVGnKTRRLuneHH T/xG2ygFGD0EdWWLCP/Wxd1UbNRo8qkQ0tA/WVOV6IW5oNoldgZPg/qXX7EN/ZgXpQ C/+N5EUM7cMeNFOZtGRR7ybQotbtSCMknX3wsJ+0= From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout) Date: Thu, 14 Mar 2024 10:24:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: tdep X-Bugzilla-Version: 12.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit 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=3D29423 --- Comment #25 from Sourceware Commits --- The master branch has been updated by Tom de Vries : https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D9a03f2185347= bd8f20da9bf535bc68a8d0f18ce8 commit 9a03f2185347bd8f20da9bf535bc68a8d0f18ce8 Author: Tom de Vries Date: Thu Mar 14 11:25:10 2024 +0100 [gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64 On aarch64-linux, with test-case gdb.base/watchpoint-unaligned.exp I run into: ... (gdb) watch data.u.size8twice[1]^M Hardware watchpoint 241: data.u.size8twice[1]^M (gdb) PASS: gdb.base/watchpoint-unaligned.exp: watch data.u.size8twice[= 1] continue^M Continuing.^M FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout) FAIL: gdb.base/watchpoint-unaligned.exp: size8twice write ... This happens as follows. We start the exec and set an 8-byte hardware watchpoint on data.u.size8twice[1] at address 0x440048: ... (gdb) p sizeof (data.u.size8twice[1]) $1 =3D 8 (gdb) p &data.u.size8twice[1] $2 =3D (uint64_t *) 0x440048 ... We continue execution, and a 16-byte write at address 0x440040 triggers= the hardware watchpoint: ... 4101c8: a9000801 stp x1, x2, [x0] ... When checking whether a watchpoint has triggered in aarch64_stopped_data_address, we check against address 0x440040 (passed= in parameter addr_trap). This behaviour is documented: ... /* ADDR_TRAP reports the first address of the memory range accessed by the CPU, regardless of what was the memory range watched. ... */ ... and consequently the matching logic compares against an addr_watch_alig= ned: ... && addr_trap >=3D addr_watch_aligned && addr_trap < addr_watch + len) ... However, the comparison fails: ... (gdb) p /x addr_watch_aligned $3 =3D 0x440048 (gdb) p addr_trap >=3D addr_watch_aligned $4 =3D false ... Consequently, aarch64_stopped_data_address returns false, and stopped_by_watchpoint returns false, and watchpoints_triggered returns = 0, which make infrun think it's looking at a delayed hardware breakpoint/watchpoint trap: ... [infrun] handle_signal_stop: stop_pc=3D0x4101c8 [infrun] handle_signal_stop: delayed hardware breakpoint/watchpoint t= rap, ignoring ... Infrun then ignores the trap and continues, but runs into the same situation again and again, causing a hang which then causes the test timeout. Fix this by allowing a match 8 bytes below addr_watch_aligned. This introduces the possibility for false positives, so we only do this for regular "value changed" watchpoints. An earlier version of this patch worked by aligning addr_watch_aligned = to 16 instead of 8: ... - const CORE_ADDR addr_watch_aligned =3D align_down (state->dr_addr_wp= [i], 8); + const CORE_ADDR addr_watch_aligned =3D align_down (state->dr_addr_wp= [i], 16); ... but while that fixed the test-case, it didn't fix the problem completel= y, so extend the test-case to check more scenarios. Tested on aarch64-linux. Tested-By: Luis Machado Approved-By: Luis Machado PR tdep/29423 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29423 --=20 You are receiving this mail because: You are on the CC list for the bug.=