Iwasawa 🌟 (one hikari of too many)
(replying to Kahanis)
@Kahanis i have much more respect for that choice! 64-bit with 32-bit pointers still lets you take full advantage of the hardware
AssertionError("Joe Groff")
(replying to Saagar Jha)
Saagar Jha
(replying to AssertionError("Joe Groff"))
2 replies
shac ron ₪
(replying to Saagar Jha)
Saagar Jha
(replying to shac ron ₪)
AssertionError("Joe Groff")
(replying to Saagar Jha)
@saagar @Kahanis @shac @hikari but the biggest crime aarch64 committed was taking away conditional everything
2 replies
Saagar Jha
(replying to AssertionError("Joe Groff"))
AssertionError("Joe Groff")
(replying to Saagar Jha)
shac ron ₪
(replying to AssertionError("Joe Groff"))
@joe @saagar @Kahanis @hikari An architecture where any instruction can be a conditional branch is objectively insane. But also the most fun assembly to write.
2 replies
Saagar Jha
(replying to shac ron ₪)
Saagar Jha
(replying to Saagar Jha)
2 replies
Saagar Jha
(replying to Siguza)
2 replies
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)
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.
https://arm.jonpalmisc.com/2023_09_sysreg/AArch64-esr_el2#fieldset_0-24_0_24-23_18-1
2 replies
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
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)
charlie cummings
(replying to Saagar Jha)
@saagar @Kahanis @joe @shac @hikari i can't find it now but i saw someone post a month or two ago a snippet that used the fact an instruction would mutate register state before faulting to tell if a page wasn't resident in memory and the kernel was reattempting it after a fault 🙂
2 replies
