Iwasawa 🌟 (one hikari of too many)

(replying to Iwasawa 🌟 (one hikari of too many))

‪so… if you have a phone with a 64-bit CPU (every modern Android phone) and a 64-bit kernel (probably also every modern Android phone), but less than 4GB RAM… supporting both 32-bit and 64-bit applications is kind of painful memory-wise, so they just… use a 32-bit only userland‬

Iwasawa 🌟 (one hikari of too many)

(replying to Iwasawa 🌟 (one hikari of too many))

‪now i can see how they came to that, but it's an extremely Google Moment honestly. Apple didn't want to play this game and gave 32-bit a sudden, swift, merciful death. Google are prolonging the agony for everyone. I can't stress enough how absurd “32-bit-only 64-bit device” is‬

3 replies →
3 replies

Kahanis

(replying to Iwasawa 🌟 (one hikari of too many))
@hikari if i understand it correctly, apple also plays a similar game on the watches. They do run aarch64, but with 32 bit pointers. Though this is most likely irrelevant for emulator devs. :P

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

Saagar Jha

(replying to Iwasawa 🌟 (one hikari of too many))
@hikari @Kahanis With what, userspace PAE?

AssertionError("Joe Groff")

(replying to Saagar Jha)

@saagar @Kahanis @hikari are these 32-bit-only Android devices still using the armv7 instruction set? arm64_32 at least lets you still use all thirty-one 64-bit GPRs

Saagar Jha

(replying to AssertionError("Joe Groff"))
@joe @Kahanis @hikari PC is a GPR if you try hard enough
2 replies →
2 replies

I Can't Believe It's Not Zero!

(replying to Saagar Jha)

@saagar @Kahanis @joe @hikari that’s right


shac ron ₪‎

(replying to Saagar Jha)

@saagar @joe @Kahanis @hikari PC is not addressable on arm64. It can only be indirectly modified, unlike arm32 that can use it as the source or destination of most instructions.

Saagar Jha

(replying to shac ron ₪‎)
@shac @joe @Kahanis @hikari Guess 64-bit doesn’t really let you take full advantage of the hardware after all

AssertionError("Joe Groff")

(replying to Saagar Jha)

@saagar @Kahanis @shac @hikari but the biggest crime aarch64 committed was taking away conditional everything

2 replies →
2 replies

Saagar Jha

(replying to AssertionError("Joe Groff"))
@joe @Kahanis @shac @hikari What about conditional conditions

AssertionError("Joe Groff")

(replying to Saagar Jha)

@saagar @Kahanis @shac @hikari what if you use a thumb IT instruction over conditionalized ARM instructions


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 →
2 replies

Saagar Jha

(replying to shac ron ₪‎)
@shac @joe @Kahanis @hikari That’s every architecture that supports breakpoints

Saagar Jha

(replying to Saagar Jha)
@shac @Kahanis @hikari @joe The extra-fun architectures are where you can branch halfway through an instruction
2 replies →
2 replies

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)


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 🙂


AssertionError("Joe Groff")

(replying to shac ron ₪‎)

@shac @saagar @Kahanis @hikari it would've been nice to keep conditional calls in arm64 at least, there are some nice things you can do with them


Iska

(replying to Iwasawa 🌟 (one hikari of too many))

@hikari@social.noyu.me

Apple didn't want to play this game and gave 32-bit a sudden, swift, merciful death.
I'd rather call it an execution or orbital strike, when half your apps stop working overnight.
Imagine the amount of support tickets that came out of iOS 11, especially once downgrade became impossible.

Iwasawa 🌟 (one hikari of too many)

(replying to Iska)

Siguza

(replying to Iwasawa 🌟 (one hikari of too many))

@hikari every single Raspberry Pi question on Stack Overflow... "binary says no such file or directory but uname -m says arm64" aaaaaaargh!!

Iwasawa 🌟 (one hikari of too many)

(replying to Iwasawa 🌟 (one hikari of too many))

‪there is no destiny for these devices other than e-waste and it is fucking painful‬

1 replies →
1 replies

sweet little raquel

(replying to Iwasawa 🌟 (one hikari of too many))

@hikari is that not something that could be changed on the software side when they do decide to kill off 32 bit for good?

Iwasawa 🌟 (one hikari of too many)

(replying to sweet little raquel)

@fishtrauma unfortunately android phones essentially do not get os updates

Iwasawa 🌟 (one hikari of too many)

(replying to Iwasawa 🌟 (one hikari of too many))

‪the fact that 4GB is considered a small amount of memory is extremely jokerifying also. iPhones have delivered a premium 64-bit experience both with that much memory and with half that. Android is an absolutely wretchedly inefficient platform. skill issue skill issue skill iss—‬

1 replies →
1 replies

Mia ‘Meetings? I Abstain’ Luna Tearmoon

(replying to Iwasawa 🌟 (one hikari of too many))

@hikari tbh Windows NT 4 delivered a premium 32-bit experience with 64 MB RAM, with noticeably lower interface latency

I will never stop being weirded out by how much RAM modern apps need

Iwasawa 🌟 (one hikari of too many)

(replying to Iwasawa 🌟 (one hikari of too many))

‪the absolute worst thing, that pisses me off more than anything else, is that ofc making an Android phone that supports both 64-bit and 32-bit is an option when building the OS image, or even better, just 64-bit. but Google said they'd start mandating the opposite. i'm serious‬

Iwasawa 🌟 (one hikari of too many)

(replying to Iwasawa 🌟 (one hikari of too many))

‪obviously that mandate was not for phones with lots of RAM. they said they'd mandate only supporting 32-bit specifically on brand-new 64-bit low-memory phones. to reduce the number of configurations they had to worry about.‬

‪i do not know if they went ahead with it but SCREAMS

Iwasawa 🌟 (one hikari of too many)

(replying to Iwasawa 🌟 (one hikari of too many))

‪ARM GAVE YOU THE WORLD'S SMALLEST 64-BIT-CAPABLE CORE TWELVE YEARS AGO AND THIS IS WHAT YOU CHOOSE TO DO WITH IT? THIS????? DOES YOUR LUST FOR INFLICTED SUFFERING KNOW NO BOUNDS, GOOGLE? DO YOU NOT LOOK UPON YOUR CREATIONS AND WEEP FOR WHAT YOU HAVE DONE. WHY DO YOU CURSE US‬

1 replies →
1 replies

Saagar Jha

(replying to Iwasawa 🌟 (one hikari of too many))
@hikari ARM had 64-bit cores in 2012?

Iwasawa 🌟 (one hikari of too many)

(replying to Saagar Jha)

@saagar yes. in the ruins of our civilisation, they will know us by the Cortex-A53 chips

Saagar Jha

(replying to Iwasawa 🌟 (one hikari of too many))
@hikari Ah ok so this is the typical ARM-brain at work. Yes it was “available” in 2012 (in the form of IP of course) and then it took at least two years for anyone to actually ship it

Iwasawa 🌟 (one hikari of too many)

(replying to Saagar Jha)

@saagar sure, that's the typical lead time. anyway that means we've been making cortex-a53 phones for an entire decade now

Saagar Jha

(replying to Iwasawa 🌟 (one hikari of too many))
@hikari And we shall make them for a decade to come

Iwasawa 🌟 (one hikari of too many)

(replying to Saagar Jha)

@saagar at the end of the world, there will be famine, pestilence, and Cortex-A53

Iwasawa 🌟 (one hikari of too many)

(replying to Iwasawa 🌟 (one hikari of too many))

‪if this does blow up then please do not follow me for technology opinions. you'd be enabling my worst tendencies. i am here to post about kanbaru suruga from the monogatari series and also how pretty the sky is‬