Summary: | [gdb/tdep, aarch64] Hang when hitting access watchpoint on M1 | ||
---|---|---|---|
Product: | gdb | Reporter: | Tom de Vries <vries> |
Component: | tdep | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | NEW --- | ||
Severity: | normal | CC: | luis.machado |
Priority: | P2 | ||
Version: | HEAD | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: | Tentative linux kernel PR text |
Description
Tom de Vries
2024-03-14 12:39:31 UTC
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. Created attachment 15416 [details] 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? Looks OK to me. I sent a message off-list. Thanks for putting this together. (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 |