Saagar Jha

(replying to Saagar Jha)
@dougall @marcan (In fact it actually does an exceptionally good job: for example it needs to implement, presumably in microcode, traps *in the middle* of an operation with a rep prefix, despite it being one instruction. This means it needs to actually let you observe the split!

Saagar Jha

(replying to Saagar Jha)
@dougall @marcan In particular it will stop execution with all the registers updated for you so you can restart where you left off simply by continuing execution by running that prefixed instruction again. Setting TF runs a single “step” and may not change the program counter.)
1 replies →
1 replies

Dougall

(replying to Saagar Jha)

@saagar @marcan Yeah, that's how I'd do it. (I worry I've misled you by mentioning x86 – I only meant to imply I had no idea how it worked on ARM.) That said, I can hardly be surprised when a production debugger ends up having to disassemble, and failing weirdly when it can't. Trying to maintain portable APIs across decades of different architectures, with subtly different behaviours (break before or after memory access, provide access address/size/data in exception-info or don't) seems hard.

Saagar Jha

(replying to Dougall)
@dougall @marcan I wouldn’t be surprised but that’s mostly because there does not exist a single debugger that isn’t a massive pile of hacks

Saagar Jha

(replying to Saagar Jha)
@marcan @dougall > To match the fault address in the watchpoint list, Jaydeep Patil in 2015 https://reviews.llvm.org/D11672 to recognize load/store instructions and calculate the memory address by decoding them.

Saagar Jha

(replying to Saagar Jha)
@dougall @marcan That aside, the more critical bit is that on a trap x86 tells you the breakpoint that triggered, which you can read to figure out precisely which watchpoint you hit and what address it corresponds to, without having to really peek at the instruction stream.

Saagar Jha

(replying to Saagar Jha)
@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.
1 replies →
1 replies

Saagar Jha

(replying to Saagar Jha)
@marcan @dougall oh yeah btw if you are ever super desperate to emulate 4K pages and crafty enough to make do with just a few of them, well

Saagar Jha

(replying to Saagar Jha)
@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.

Saagar Jha

(replying to Saagar Jha)
@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!

Saagar Jha

(replying to Saagar Jha)
@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.

Saagar Jha

(replying to Saagar Jha)
@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…

Saagar Jha

(replying to Saagar Jha)
@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

Sam Collinson

(replying to Saagar Jha)

@saagar great thread!