Closed
Description
Bugzilla Link | 26031 |
Version | unspecified |
OS | Linux |
Reporter | LLVM Bugzilla Contributor |
CC | @emrekultursay |
Extended Description
Following tests fail on arm-linux:
TestWatchLocationWithWatchSet.py
TestStepOverWatchpoint.py
Ptrace interface fails to set read/write watchpoints on single byte variables which are not word aligned.
Following commands fail, in case of TestStepOverWatchpoint:
watchpoint set variable -w read g_watch_me_write
Following commands fail, in case of TestWatchLocationWithWatchSet:
watchpoint set expression -w write -s 1 -- g_char_ptr + 7
Need to do further investigation on how to make sure we can select individual bytes while setting watchpoints on arm.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
llvmbot commentedon Oct 15, 2019
Some LLDB Watchpoints tests marked as Xfail for ARM/ARM64 or AArch32/AArch64 on linux and android due to one reason or another. This bug report tracks the progress on their resolution or provides and explanation into those failures.
llvmbot commentedon Mar 3, 2021
Ok, I think this is the same problem that I'm hitting on FreeBSD. Basically:
(lldb) p &g_watch_me_read
(char *) $0 = 0x0000000000230b40 ""
(lldb) p &g_watch_me_write
(char *) $1 = 0x0000000000230b42 ""
Currently LLDB 'rounds' watchpoint addresses down, so the second wp would have the same address as first wp, and this is unsupported -- probably because we couldn't say which one was hit. I was thinking we could improve the current code by using BAS to select specific bytes rather than extending the range but I'm not sure if this will change how watchpoints are reported.
This could be easily illustrated using the following sample program:
volatile char a = 1;
volatile char b = 2;
int main() {
a = 4;
b = 7;
return 0;
}
If you set watchpoint on b, you'd get hits on both assignments.
llvmbot commentedon Mar 3, 2021
Oh, and if I read AArch64 documentation right (it's really hard to read), I think that 4-byte alignment is necessary, not 8-byte.
jasonmolenda commentedon May 25, 2022
Hm, on Darwin, this works correctly - at the gdb-remote protocol level
On Darwin systems, the watchpoint hit is delivered as a mach exception which includes the FAR_EL1 register contents -- in this case, the address that was modified, 0x100004001, that we were watching. debugserver uses BAS style watchpoints on arm64 right now, although I want to change that to mask style watchpoints to allow for more flexible watchpoints. The instruction sequence, may be important; in my binary, clang is writing a single byte (
strb w8, [x9, #0x1]
) so the address of the exception is what lldb expects. If the compiler had written a word of memory to set both of these, the beginning address of that write would be the value we get back in the FAR. This is a problem with how we handle watchpoints on AArch64 right now that I know I need to do something about -- allowing for some fuzz between the FAR address we get back, and the address of the nearest watchpoint that we recognize it as.jasonmolenda commentedon Sep 23, 2023
With
I believe this is fixed now.