@dougall @marcan ARM on the other hand is incredibly messy. To begin with, there are two independent ways to set breakpoints (at the byte level, or for an entire power-of-two region 8 bytes to 2 GB in size). This is actually quite flexible, but it’s pretty complicated.

@marcan @dougall That’s not that bad, though. Where it really gets awful is what happens when you get an exception. All you get back is an address in FAR: notably, you don’t know *which* watchpoint triggered, so you need to figure out the one it corresponds to.

@marcan @dougall Not hard enough yet? The address in FAR isn’t actually the faulting address. It’s just *any* address that the instruction touches. Notably, if doesn’t even have to return an address that you happen to be watching! This is completely bonkers!

@marcan @dougall Let’s say you set an 8-byte watchpoint from 0x1000 to 0x1007 and get a trap on a dc zva. FAR could legitimately contain something like 0x1016! AFAIK all you really need is that the instruction writes to FAR and it also writes to a watchpoint of yours.

@dougall @marcan So to correlate I think you first need to decode the instruction, figure out its possible range, then see if your watchpoint could be in it. If you have multiple watchpoints that match, tough luck I guess? Honestly not sure what you are supposed to do here…

@dougall @marcan Anyways it’s probably needless to say that nobody really has answers here or bothers to do anything beyond the basics so it’s broken in all the debuggers that I know of. For example I found this when double checking something just now: https://discourse.llvm.org/t/aarch64-watchpoints-reported-address-outside-watched-range-adopting-mask-style-watchpoints/67660