[Bug tdep/31486] New: [gdb/tdep, aarch64] Hang when hitting access watchpoint on M1

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31486

            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 SOC,
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 = 0
New value = 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".
<hangs>
...

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 = type == hw_write ? 16 : 8;
+       const CORE_ADDR max_access_size = type == hw_write ? 16 : 16;
        const CORE_ADDR addr_watch_base = addr_watch_aligned -
          (max_access_size - AARCH64_HWP_MAX_LEN_PER_REG);
        if (!(addr_trap >= 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 trigger to
user space, it would make it trivial to determine whether and which watchpoint
triggered (well, according to the kernel, which may still be wrong).  We should
probably file a linux kernel PR for this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.