Fwd: OSABI Assignment

[connor horman]

I'm forwarding the below informal request for a psABI-specific OSABI assignment, and information regarding any requirements that I need to fulfil before recieving one.

---------- Forwarded message ---------
From: connor horman <chor...@gmail.com>
Date: Tue, Sep 2, 2025, 23:00
Subject: Re: OSABI Assignment
To: <gener...@googlegroups.com>

That's fair enough, although a slightly disappointing answer. I did note that the EI_OSABI field looked a bit constrained, especially for generic OS's.

Separately to this request, has there been thought put into extending it (possibly by reserving one or more values that has the extended value somewhere else - not entirely sure where, though)?

On Tue, 2 Sept 2025 at 18:29, Cary Coutant <ccou...@gmail.com> wrote:

On Sat, Aug 30, 2025 at 3:46 PM connor horman <chor...@gmail.com> wrote:

I was wondering what I need to do to get an EI_OSABI constant assignment. I'm working on a new OS which is trying to define its OS-specific ELF ABI. It has a few extensions in the format (currently just GNU ones are implemented, via forks of GNU binutils/gcc and llvm, though one link-sensitive feature is defined and I'll be starting work on that soon) - notably it supports shared objects with only DT_GNU_HASH. It also carries some differences in the code ABI (on x86-64 notably, it uses binary64 for long double instead of x87 double-extended precision), so distinguishing it is useful. The Architecture-neutral extensions are described in https://github.com/LiliumOS/rfcs/blob/lilium-elf/src/rfcs/0005-lilium-elf.md, and the x86-64 specific changes are described in https://github.com/LiliumOS/rfcs/blob/main/src/rfcs/0003-x86_64-system-abi.md. Future extensions are also expected, though are in design stages. The former one is not merged yet since it's blocked on the OSABI number. A partial dynamic loader is implemented at https://github.com/LiliumOS/ld-so-impl (supports the format itself, requires a downstream impl to actually load objects from a filesystem or otherwise), and a completed one is part of https://github.com/LiliumOS/winter-lily (which emulates the operating system APIs on linux).

I would recommend that you choose a value in the architecture-specific range (64–255) to start with. This is a much larger namespace than the global 0–63 range. If you're porting to more than one architecture, you should be able to find a common value in that range that is unassigned in each of those psABIs. You can do this by consulting the appropriate psABIs and reserving your value with the respective authoring bodies. (The x86 psABI authoring body is at x86-6...@googlegroups.com.)

If your new OS becomes established across several architectures, you can request a value in the global (0–63) range, by emailing your request to regi...@xinuos.com. I understand that this will impose an extra maintenance burden when you get a new OSABI value assigned, but we want to avoid allocating new values in this limited namespace until there's a genuine need.

Please see Appendix B in the ELF spec here:

    https://gabi.xinuos.com/index.html

-cary

--
You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/generic-abi/CAJimCsF-0sChvNFT%2BgVhwppiOiYH4C0ZCb%2B-_YTzcPi8TKNRVA%40mail.gmail.com.