[lldb-dev] [Bug 51927] New: lldb misses AArch64 stp watchpoint on certain hardware (Neoverse N1)

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=51927

            Bug ID: 51927
           Summary: lldb misses AArch64 stp watchpoint on certain hardware
                    (Neoverse N1)
           Product: lldb
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at lists.llvm.org
          Reporter: david.spickett at linaro.org
                CC: jdevlieghere at apple.com, llvm-bugs at lists.llvm.org

Created attachment 25277
  --> https://bugs.llvm.org/attachment.cgi?id=25277&action=edit
Test file

lldb misses AArch64 stp watchpoint on certain hardware (Neoverse N1)

The architecture allows a core to report an address different from the specific
address that
triggers a watchpoint. See "D2.10.5 Determining the memory location that caused
a Watchpoint exception" in the ARMARM.

This means that an stp which stores 16 bytes can report an address from the
start of the 16 bytes,
up to the specific address that caused the watchpoint trigger.

For stp, Qemu reports an address in the upper 8 bytes and a Neoverse N1 in the
lower 8 bytes.
lldb only looks for watched addresses, so if you watch the upper half on an N1
we see the trap
but can't tell you why it happened or continue from that point.

Example attached, compile with:
$ gcc /tmp/test.c -o /tmp/test.o -O0 -g

On an N1, if you watch f.b we'll not be able to find the watchpoint.

$ ./bin/lldb /tmp/test.o
(lldb) target create "/tmp/test.o"
Current executable set to '/tmp/test.o' (aarch64).
(lldb) b main
Breakpoint 1: where = test.o`main + 8 at test.c:11, address =
0x000000000000077c
(lldb) run
Process 1166052 launched: '/tmp/test.o' (aarch64)
Process 1166052 stopped
* thread #1, name = 'test.o', stop reason = breakpoint 1.1
    frame #0: 0x0000aaaaaaaaa77c test.o`main at test.c:11
   8    Foo f __attribute__((aligned (64))) = { .a=1, .b=2};
   9
   10   int main() {
-> 11     printf("---------------------------\n");
   12     printf("  f.a: %p    f.b: %p\n", &f.a, &f.b);
   13     printf("---------------------------\n");
   14
(lldb) watchpoint set variable f.b
Watchpoint created: Watchpoint 1: addr = 0xaaaaaaabb048 size = 8 state =
enabled type = w
    declare @ '/tmp/test.c:8'
    watchpoint spec = 'f.b'
    new value: 2
(lldb) c
Process 1166052 resuming
---------------------------
  f.a: 0xaaaaaaabb040    f.b: 0xaaaaaaabb048
---------------------------
Process 1166052 stopped
* thread #1, name = 'test.o', stop reason = trace
    frame #0: 0x0000aaaaaaaaa7c0 test.o`main at test.c:15
   12     printf("  f.a: %p    f.b: %p\n", &f.a, &f.b);
   13     printf("---------------------------\n");
   14
-> 15     asm volatile (
   16       "mov x0, #3\n\t"
   17       "mov x1, #4\n\t"
   18       "stp x0, x1, [%0]\n\t"
(lldb) c
<... you get stopped "trace" again over and over ...>

I believe we can implement the full architecture rules to solve most of these
situations,
but will probably need to disassemble the current instruction to do so. As this
is the only
way to know "the memory access or set of contiguous memory accesses" that is
active.

Going to be tricky for SVE scatter stores where we would have to inspect
registers,
but we can still look for instructions where just the mnemonic is enough.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20210921/dc40e5de/attachment-0001.html>