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

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

[vries at gcc dot gnu.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.

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

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luis.machado at arm dot com

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

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

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
There's a similar issue with lldb (version 17.0.6), with less serious failure
mode though.

When setting a write watchpoint on data.u.size8twice[1], execution stops for
reason "trace":
...
$ lldb outputs/gdb.base/watchpoint-unaligned/watchpoint-unaligned
(lldb) target create
"outputs/gdb.base/watchpoint-unaligned/watchpoint-unaligned"
Current executable set to
'/home/vries/gdb/outputs/gdb.base/watchpoint-unaligned/watchpoint-unaligned'
(aarch64).
(lldb) b main
Breakpoint 1: where = watchpoint-unaligned`main + 8 at
watchpoint-unaligned.c:65:3, address = 0x0000000000410208
(lldb) r
Process 1075081 launched:
'/home/vries/gdb/outputs/gdb.base/watchpoint-unaligned/watchpoint-unaligned'
(aarch64)
Process 1075081 stopped
* thread #1, name = 'watchpoint-unal', stop reason = breakpoint 1.1
    frame #0: 0x0000000000410208 watchpoint-unaligned`main at
watchpoint-unaligned.c:65:3
   62  
   63     assert (sizeof (data) == 8 + 3 * 8);
   64  
-> 65     write_size8twice ();
   66  
   67     while (size)
   68       {
(lldb) watch set var -w write data.u.size8twice[1]
Watchpoint created: Watchpoint 1: addr = 0x00440048 size = 8 state = enabled
type = w
    declare @
'/home/vries/gdb/src/gdb/testsuite/gdb.base/watchpoint-unaligned.c:35:3'
    watchpoint spec = 'data.u.size8twice[1]'
    new value: 0
(lldb) c
Process 1075081 resuming
Process 1075081 stopped
* thread #1, name = 'watchpoint-unal', stop reason = trace
    frame #0: 0x00000000004101f0 watchpoint-unaligned`write_size8twice at
watchpoint-unaligned.c:48:3
   45  
   46   #ifdef __aarch64__
   47     volatile void *p = &data.u.size8twice[offset];
-> 48     asm volatile ("stp %1, %2, [%0]"
   49                   : /* output */
   50                   : "r" (p), "r" (first), "r" (second) /* input */
   51                   : "memory" /* clobber */);
...

In contrast, when setting a write watchpoint on data.u.size8twice[0], execution
stops for reason "watchpoint":
...
(lldb) c
Process 1075169 resuming

Watchpoint 1 hit:
old value: 0
new value: 1
Process 1075169 stopped
* thread #1, name = 'watchpoint-unal', stop reason = watchpoint 1
    frame #0: 0x00000000004101f4 watchpoint-unaligned`write_size8twice at
watchpoint-unaligned.c:56:1
   53     data.u.size8twice[offset] = first;
   54     data.u.size8twice[offset + 1] = second;
   55   #endif
-> 56   }
   57  
   58   int
   59   main (void)
(lldb) 
...

This is using a write watchpoint, but it's the same for a regular watchpoint. 
Note that gdb handles a regualar watchpoint by reporting a watchpoint stop in
both (data.u.size8twice[0] and data.u.size8twice[1]) cases.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 15416
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15416&action=edit
Tentative linux kernel PR text

(In reply to Tom de Vries from comment #0)
> 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.

I wrote a draft.

Any comments?

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

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

[luis.machado at arm dot com]

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

--- Comment #3 from Luis Machado <luis.machado at arm dot com> ---
Looks OK to me. I sent a message off-list.

Thanks for putting this together.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Luis Machado from comment #3)
> Looks OK to me. I sent a message off-list.
> 
> Thanks for putting this together.

Filed at https://bugzilla.kernel.org/show_bug.cgi?id=218628

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