Reserve e_flags bits 24 through 31 for custom use

[jrtc27]

Whilst here, correctly pluralise some headers and use consistent
alignment.

Closes: #157

[jrtc27]

I dropped the "Reserved for" as otherwise the table gets rather wide

[jim-wilson]

I think that there are practical issues with this suggestion. The ELF Header flags are one of the first things checked when trying to figure out if we can run this binary, but if the ELF Header flags contain bits that can only be parsed if something else is read first then the bits aren't usable for their normal purpose. It isn't clear why anyone would want to put vendor specific bits in eflags. Is there any other target that does this? Just checking binutils, I don't see an obvious one that is allowing unknown bits in eflags.

Something that could work is if the bits were dependent on the EI_OSABI byte in the ident string, e.g. if ELFOSABI_LINUX and ELFOSABI_FREEBSD used the bits for different purposes then that would be OK, as then we can still parse the bits without reading anything other than the elf header. Or if we had two different machine numbers, e.g. EM_RISCV and another one, and the value of the bits depended on which machine number is being used, but a second machine number is probably best avoided if possible.

Anyways, I think bits that can't be parsed without reading something outside the elf header is a mistake. There are lots of other ways to add vendor specific support, like vendor specific program headers, or sections, or relocations, or vendor specific extensions to the elf attribute which is designed to be extensible. We don't need vendor specific bits in eflags.

[jrtc27]

This proposal is what was discussed in #157. We use them downstream for CHERI to distinguish between plain RISC-V binaries and pure-capability CHERI-RISC-V binaries. Just like the float ABI, different binaries are totally incompatible, but even more so; the code is totally different, even if it does resemble RISC-V a lot. Even Arm, after dragging their heels and not using an ELF flag for Morello for over a year, relented and reserved one in ARM-software/abi-aa#101. In FreeBSD, which ELF image activator (32-bit, 64-bit and, in our case, 64-bit CHERI pure-capability) gets used is decided very early on based solely on the ELF header, and it's only once it's decided on an image activator that it then starts to look at program headers, so this information has to be in the ELF header. Not to mention that so many tools need to know the information that having an ELF note or similar is just a complete pain for no gain.

Whatever happens in the RISC-V psABI, we will just continue to use an ELF flag downstream because that is by far the best solution for our needs. I'd just like to use a bit that I know won't be used by the psABI in future (without abusing my power to stop people allocating the bits we're using and thereby giving my downstream special treatment). I appreciate the point that discovering what the bits mean isn't really possible, but having them be meaningful in that kind of context just isn't a goal. This is for "I have a system where I absolutely need an ELF flag and control both the OS and toolchain producing them, and have no need to support any other such non-standard extensions". To be honest, I don't want people to use these bits, because the situations in which you should be using them are exceedingly rare, only for something as radical as CHERI (I see these more as "research" than "vendor" bits...), but it is a part of the psABI that currently does not have a provision for custom extensions that need to reserve bits/encodings and so I feel there should be something there for such cases like ours.

I could add a big blob of "Do not use these unless you absolutely need to. There is no provision for compatibility between conflicting uses, and many standard RISC-V tools will ignore them. Only use these if you control the operating system and the toolchain, and the ABI differences are so significant that they cannot be done with an ELF note, such as if you require use of a different syscall ABI." kind of text if that would help?

[jim-wilson]

In the ARM case it is a Morello specific bit, not a reserved extension bit. The GNU toolchain doesn't support this Morello bit yet.

Yes, I think adding a note to recommend not using the bits except in special cases would help.

[jrtc27]

In the ARM case it is a Morello specific bit, not a reserved extension bit. The GNU toolchain doesn't support this Morello bit yet.

Well, there is a commitment from them not to use the bit in the main AAELF64 spec, which they can do because both are controlled solely by Arm. I can't just reserve a bit for CHERI-RISC-V and commit to not allocating it in the psABI because that's an abuse of power, hence why I want to go through the officials channels to ensure there is a bit we can freely use without reserving it specifically for CHERI-RISC-V (I mean, if people would rather I do that instead then I can but I rather doubt that's more palatable...).

And yes, the Morello GNU toolchain lags LLVM in many respects, it's just not a particularly useful artefact at this point given the distinct lack of a working GCC (which they are working on, but is a large undertaking to replicate all the work we did to the internals of LLVM for CHERI and is a way away from being usable, let alone efficient), there's zero reason why you'd choose to use LLVM with GNU binutils, the basic opcodes BFD parts are primarily there for GDB at the moment, with the GNU as and ld parts really only starting to be useful for the GCC work (I don't know of anything else using them), thus all the development happens on the LLVM toolchain with their binutils playing catch-up when people notice (which makes a change to have it that way round for once!).

[kito-cheng]

Although I am not flavor to reserve e_flags for custom/vendor use, but we have .riscv.attribute which has lots space to extend, so LGTM once it add note.