Siguza

(replying to Saagar Jha)

@saagar @Kahanis @joe @shac @hikari tryna watchpoint a CPY?

Saagar Jha

(replying to Siguza)
@siguza @Kahanis @joe @shac @hikari This is actually one of the things I think ARM is completely out of their depth on, x86 actually thinks about what happens in situations like these and for a lot of traps ARM goes “why don’t you figure out how to reconstruct state ¯\_(ツ)_/¯”
2 replies →
2 replies

Siguza

(replying to Saagar Jha)

@saagar @Kahanis @joe @shac @hikari which is actually a more sane thing to present to software, just abysmal to figure out how to do... while x86 looks at all the options, picks the worst one, and then everyone is stuck with that forever.

Allison Husain

(replying to Saagar Jha)

@saagar huh, does ARMv8 (or later) have non-restartable instructions? Is this like vector stuff or something? I thought it was pretty clean in this regard in that you can always just ERET back after resolving the fault and the program will keep going.

Or, hmm, maybe things like non-FPAC IABORTs are non-restartable since PC is trashed and you can't (confidently) know if it's PAC or just a bogus address? Though if you're trying to recover from a PAC fail you kinda deserve it.

Saagar Jha

(replying to Allison Husain)
@ezhes_ Not sure, this was mostly a watchpoint hate session (which you may have seen a previous iteration of: https://federated.saagarjha.com/notice/ATdDMNXtw4QuTBZ1jU)

Allison Husain

(replying to Saagar Jha)

@saagar in theory, doesn't FEAT_Debugv8p2 solve this whole mess? ESR.ISS.WPT reports the matched watchpoint number for a trap and is mandatory. Though, they kinda ruin it with WPTV which can make WPT invalid, but that goes away in 8p9 where WPT cannot be invalid.

arm.jonpalmisc.com/2023_09_sys

2 replies →
2 replies

Saagar Jha

(replying to Allison Husain)
@ezhes_ > Watchpoint might be false-positive.

lol

Jason Molenda

(replying to Allison Husain)

@ezhes_ @saagar in streaming SVE mode a write near a watched region can trigger a false watchpoint hit, and that watchpoint number will be reported as the one hit. lldb changed its default watchpoint type to "modify" for write-wps last year, so we can ignore a false positive in this mode, and also because we use the MASK style wps to allow people to watch > 8byte blocks of memory on darwin, and we need to ignore writes outside of any non-pow-of-2 region they might request. e.g. "watch 96B”.

2 replies →
2 replies

Jason Molenda

(replying to Jason Molenda)

@ezhes_ @saagar should say - "modify watchpoint” in this context means “the memory being watched was mutated", so writing the same value there is not reported to the user. I think it's a more useful mode for who people use watchpoints tbh. A genuine write-watchpoint is still available if someone needs to audit every piece of code touching a region, even if storing the same value.

Jason Molenda

(replying to Jason Molenda)

@ezhes_ @saagar fun aside, lldb will also try to use multiple Byte Address Select watchpoints (1..8 bytes) on non-darwin AArch64 systems, e.g. Linux where only BAS watchpoints are available, or other targets like Intel. The engine that splits up a user's watchpoint request is flexible, but it only handles those two types of watchpoint capabilities today.

Jason Molenda

(replying to Jason Molenda)

@ezhes_ @saagar (no such cleverness possible for a read watchpoint, short of instruction decoding, which lldb doesn't do in this context for AArch64. We'll have false positives in SSVE mode or if a non-power-of-2 region of memory is being watched, 8 bytes or larger)