Post #3574226

2026-04-24 13:09 UTC

No, no it's so much worse than that: libbfd only cares if you have fseeko64 for 64-bit host support. which we do, but it's a lie, and it doesn't just use FILE_OFFSET_BITS in that case, it uses a whole different half of the fucking makefile and undefines FILE_OFFSET_BITS entirely. Oh boy.

Replies (1)

@parzivalwolfram@infosec.exchange 2026-04-24 13:24

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.)

Open ##3574225