Rendered at 11:06:11 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
eqvinox 21 hours ago [-]
It'd make quite a few things so much easier if Apple just switched to ELF. At the cost of being a giant break :/
pjmlp 20 hours ago [-]
There are other UNIXes that aren't ELF, e.g. AIX.
DannyBee 20 hours ago [-]
Sure, but COFF and its variations are much less practically common in Unixes (ie ignoring PE)
In any case, it’s highly doubtful being different from ELF is offering real value to anyone at this point, it’s just nobody wants to spend time, money, etc to migrate when incremental change to their own formats gets most of what they want.
Though it is probably accurate to say apple probably has it the worst here. Mach-O tooling is almost certainly the least available out of ELF, COFF, and Mach-O.
skissane 19 hours ago [-]
I honestly think Mach-O is more elegant than ELF, with its structure of load commands.
Of course, ELF still wins by being more mainstream, and not being de facto under the control of a single vendor.
eqvinox 18 hours ago [-]
> I honestly think Mach-O is more elegant than ELF, with its structure of load commands.
Can you elaborate on that, especially contrasting with ELF's PT_LOAD program headers?
skissane 8 hours ago [-]
If Apple wants to add some brand new feature to Mach-O, they generally just define a new load command. There's generally just one way to do it. The main downside, is (in practice) only Apple can do it. [0]
Whereas, with ELF – if you want to add a new feature, do you add it as a new program table entry type (PT_), or a new note type (NT_), or a separate note section (SHT_NOTE)?
[0] Well, historically OSF/1 also used Mach-O, although my understanding is it was an incompatible implementation of the same basic ideas. The main vendor to ship an OSF/1-based Unix was DEC (later Compaq then HP Tru64 Unix), although HP also (briefly) shipped their own OSF/1-based Unix (prior to buying DEC/Compaq), as did IBM (the short-lived AIX/ESA for IBM mainframes, which despite its name, had very little in common with the AIX everyone knows), and also various supercomputer vendors (Intel Paragon and ASCI Red, Hitachi, Kendall Square Research). But all those systems are defunct, so Apple's Mach-O is the only member of the "Mach-O family" still in production use.
eqvinox 5 hours ago [-]
> Whereas, with ELF – if you want to add a new feature, do you add it as a new program table entry type (PT_), or a new note type (NT_), or a separate note section (SHT_NOTE)?
It won't be a note section since ELF binaries don't need to have any sections. You can remove all section headers from an existing ELF binary and it'll still work (sstrip [https://github.com/aunali1/super-strip - not sure the one in ELFkickers is the same thing] does this).
Program headers define how & where to load things, notes are for small metadata.
Is your point that section headers do generally exist in ELF files, even though they're not necessary? I do agree that this "double indexing" between PHs and SHs is pretty weird and a bit odd.
skissane 5 hours ago [-]
Well, you'll have a SHT_NOTE section and then PT_NOTE pointing to its contents, right? So that way the notes are accessible both via section headers and program headers.
Mach-O does similarly have a distinction between sections as a link-time view, and segments as an execution-time view – a Mach-O contains one or more segments (LC_SEGMENT for 32-bit, LC_SEGMENT_64 for 64-bit), each of which contains a segment header followed by zero or more section headers, so the sections are subdivisions of the segment. Mach-O has names for both segments and sections; ELF only has names for sections.
Let me put it this way – if you wanted to add embedded digital signatures to ELF, so the kernel could verify them at runtime, similar to Mach-O LC_CODE_SIGNATURE – what is the extension point you'd use? The Linux kernel supports digital signatures for ELF executables in conjunction with IMA, but instead of storing the signature in the executable like Mach-O does, it stores it in a filesystem xattr.
In any case, it’s highly doubtful being different from ELF is offering real value to anyone at this point, it’s just nobody wants to spend time, money, etc to migrate when incremental change to their own formats gets most of what they want.
Though it is probably accurate to say apple probably has it the worst here. Mach-O tooling is almost certainly the least available out of ELF, COFF, and Mach-O.
Of course, ELF still wins by being more mainstream, and not being de facto under the control of a single vendor.
Can you elaborate on that, especially contrasting with ELF's PT_LOAD program headers?
Whereas, with ELF – if you want to add a new feature, do you add it as a new program table entry type (PT_), or a new note type (NT_), or a separate note section (SHT_NOTE)?
[0] Well, historically OSF/1 also used Mach-O, although my understanding is it was an incompatible implementation of the same basic ideas. The main vendor to ship an OSF/1-based Unix was DEC (later Compaq then HP Tru64 Unix), although HP also (briefly) shipped their own OSF/1-based Unix (prior to buying DEC/Compaq), as did IBM (the short-lived AIX/ESA for IBM mainframes, which despite its name, had very little in common with the AIX everyone knows), and also various supercomputer vendors (Intel Paragon and ASCI Red, Hitachi, Kendall Square Research). But all those systems are defunct, so Apple's Mach-O is the only member of the "Mach-O family" still in production use.
It won't be a note section since ELF binaries don't need to have any sections. You can remove all section headers from an existing ELF binary and it'll still work (sstrip [https://github.com/aunali1/super-strip - not sure the one in ELFkickers is the same thing] does this).
Program headers define how & where to load things, notes are for small metadata.
Is your point that section headers do generally exist in ELF files, even though they're not necessary? I do agree that this "double indexing" between PHs and SHs is pretty weird and a bit odd.
Mach-O does similarly have a distinction between sections as a link-time view, and segments as an execution-time view – a Mach-O contains one or more segments (LC_SEGMENT for 32-bit, LC_SEGMENT_64 for 64-bit), each of which contains a segment header followed by zero or more section headers, so the sections are subdivisions of the segment. Mach-O has names for both segments and sections; ELF only has names for sections.
Let me put it this way – if you wanted to add embedded digital signatures to ELF, so the kernel could verify them at runtime, similar to Mach-O LC_CODE_SIGNATURE – what is the extension point you'd use? The Linux kernel supports digital signatures for ELF executables in conjunction with IMA, but instead of storing the signature in the executable like Mach-O does, it stores it in a filesystem xattr.