3 ms·

See the comments in https://justine.lol/ape.patch https://justine.lol/ape.patch and at the bottom of https://github.com/jart/cosmopolitan/blob/3.0/tool/build/ap

by jart 3y ago

See the comments in https://justine.lol/ape.patch https://justine.lol/ape.patch and at the bottom of https://github.com/jart/cosmopolitan/blob/3.0/tool/build/apelink.c https://github.com/jart/cosmopolitan/blob/3.0/tool/build/ape... and also https://github.com/jart/cosmopolitan/blob/3.0/ape/loader.c https://github.com/jart/cosmopolitan/blob/3.0/ape/loader.c has good information too. I'm planning to roll it all into a formal looking specification pdf sometime very soon. Feedback is welcome. As for your question, ELF headers are defined in the APE shell script as printf 'octal' statements. The loader parses those out in order and looks to see if the e_machine matches the host architecture, and if so, uses that one.

amluto 3y ago
I did read the comments. ISTM if this thing goes in the Linux kernel (and maybe a BSD kernel and maybe a Windows kernel, yeah right), it should at least be written down cleanly. It doesn’t necessarily need to be a PDF. (Linux can load ELF files. ELF has a spec or five that are only mostly horrible, and I’m not actually aware of a unified ELF spec that covers everything, but this isn’t really a showstopper.) Off the top of my head, it seems like it would be nice for whatever bit of the shell-compatible header encodes an ELF header to also indicate that it’s ELF (as opposed to something else) and maybe even that it’s Linux-flavored ELF. Maybe like: #ELF-Linux-LE print… #ELF-BSD-LE print… #ELF-U-boot-BE print… This isn’t intended to be a real proposal. Little- and big-endian in the same binary would be even more amusing than the average APE binary, and I don’t remember off the top of my head exactly which properties of the target can be unambiguously determined from the binary encoding of the ELF header. (And obviously there would be some shell-flavored conditions in the middle.)

by jart 3y ago

amluto 3y ago

I did read the comments. ISTM if this thing goes in the Linux kernel (and maybe a BSD kernel and maybe a Windows kernel, yeah right), it should at least be written down cleanly. It doesn’t necessarily need to be a PDF. (Linux can load ELF files. ELF has a spec or five that are only mostly horrible, and I’m not actually aware of a unified ELF spec that covers everything, but this isn’t really a showstopper.) Off the top of my head, it seems like it would be nice for whatever bit of the shell-compatible header encodes an ELF header to also indicate that it’s ELF (as opposed to something else) and maybe even that it’s Linux-flavored ELF. Maybe like: #ELF-Linux-LE print… #ELF-BSD-LE print… #ELF-U-boot-BE print… This isn’t intended to be a real proposal. Little- and big-endian in the same binary would be even more amusing than the average APE binary, and I don’t remember off the top of my head exactly which properties of the target can be unambiguously determined from the binary encoding of the ELF header. (And obviously there would be some shell-flavored conditions in the middle.)