From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DD68A3857C52; Thu, 14 Mar 2024 12:39:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DD68A3857C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1710419971; bh=SWjN0HSeBxzWQtlNBbaoDtvOfIWOitNb9ltdZXS0yJE=; h=From:To:Subject:Date:From; b=Uolc5RnVpDth8QKGDxlpfQJQht7taR+jig9DX3VlQjIG31bRv6s5u5u6+ap+/YhQD klYTJ4upEvgEixBQ0c2sJYN67hBZhPRG0AvaWEJXzjVYOf9o2GY/587yrR9LK/L6q5 RWxO3btnRhH9NHRoIU2NmafMPjs7mADSY8Na6KOo= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug tdep/31486] New: [gdb/tdep, aarch64] Hang when hitting access watchpoint on M1 Date: Thu, 14 Mar 2024 12:39:31 +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 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31486 Bug ID: 31486 Summary: [gdb/tdep, aarch64] Hang when hitting access watchpoint on M1 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: --- With commit 9a03f218534 ("[gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp = on aarch64"), things have improved for regular watchpoints on the M1 aarch64 S= OC, but the problem reported in PR29423 still exists for other watchpoints. For instance, this works ok: ... $ gdb -q -batch -iex "set trace-commands on" \ outputs/gdb.base/watchpoint-unaligned/watchpoint-unaligned \ -ex "awatch data.u.size8twice[0]" \ -ex run +awatch data.u.size8twice[0] Hardware access (read/write) watchpoint 1: data.u.size8twice[0] +run [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Hardware access (read/write) watchpoint 1: data.u.size8twice[0] Old value =3D 0 New value =3D 1 write_size8twice () at /home/vries/gdb/src/gdb/testsuite/gdb.base/watchpoint-unaligned.c:56 56 } ... but this doesn't: ... $ gdb -q -batch -iex "set trace-commands on" \ outputs/gdb.base/watchpoint-unaligned/watchpoint-unaligned \ -ex "awatch data.u.size8twice[1]" \ -ex run +awatch data.u.size8twice[1] Hardware access (read/write) watchpoint 1: data.u.size8twice[1] +run [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". ... Luis mentioned an idea for trying to handle this here ( https://sourceware.org/pipermail/gdb-patches/2024-March/207259.html ). Another idea for a fix explores the fact that on the one hand it's trivial = to fix this by doing: ... index 802bab6d682..f22840dd914 100644 --- a/gdb/aarch64-nat.c +++ b/gdb/aarch64-nat.c @@ -292,7 +292,7 @@ aarch64_stopped_data_address (const struct aarch64_debug_reg_state *state, RK3399 SOC). But it also can be p (observed on M1 SOC). Checking for this situation introduces the possibility of false positives, so we only do this for hw_write watchpoints. */ - const CORE_ADDR max_access_size =3D type =3D=3D hw_write ? 16 : 8; + const CORE_ADDR max_access_size =3D type =3D=3D hw_write ? 16 : 16; const CORE_ADDR addr_watch_base =3D addr_watch_aligned - (max_access_size - AARCH64_HWP_MAX_LEN_PER_REG); if (!(addr_trap >=3D addr_watch_base ... but on the other hand that runs the risk of false positives. It may not be acceptable to expose the user to this unprompted, but it may be acceptable = if the user does so explicitly, by say "maint set imprecise-watchpoint-window = 16". Also, it seems to me that if the kernel would communicate the watchpoint register values (DBGBCRn_EL1 and DBGBVRn_EL1) for which it reports a trigge= r to user space, it would make it trivial to determine whether and which watchpo= int triggered (well, according to the kernel, which may still be wrong). We sh= ould probably file a linux kernel PR for this. --=20 You are receiving this mail because: You are on the CC list for the bug.=