@parzivalwolfram@infosec.exchange
Post #3574225
2026-04-24 13:24 UTC
see, this is an issue because sol7 defines both `long long` and `int64`/`uint64` as union(int32*2,double) "for alignment purposes", as you're not meant to actually try to USE them, and fseeko64 is `long long`, so it's completely valid. After staring into adb (no, not the Android kind) for way too long, it appears what the SIGILLs and SIGSEGVs are from is it's encoding constants into ELF files as 64 bits, inline, as i've noticed almost all of the SIGILLs happen directly after a register store, so something like "mov r32,imm32" and then an illegal 4-byte "instruction." Sounds a lot like it's emitting a 64-bit imm32, which would explain why it's so flaky: the first 32 bits might make it into the register, and then the second 32 fucking don't and might or might not be a valid opcode (the second 32 bits are usually not \x00, so i'm assuming something's also going wrong with the offsets, as no normal ELF is going to be a few terabytes into the address space on a fucking 486.)
Replies (1)
-
@parzivalwolfram@infosec.exchange 2026-05-02 06:31
Ah yes, we're now segfaulting in, uh... ...ah, fuck, that's init code isn't it? we're not even *in* the ELF yet, are we?