OSABI Assignment

[connor horman]

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

[Cary Coutant]

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

[connor horman]

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

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

[Cary Coutant]

If it came down to it, we could let e_ident[EI_OSABI] = 63 be an escape value, and burn another padding byte for more values. But, in the words of Bartleby, I would prefer not to.

For the record, here's a little history I dug up on the OSABI feature, from notes of our gABI discussions between 1998 and 2001:

In the original proposal to add EI_OSABI (around 1998), the field was entirely dependent on the e_machine value:

    Byte e_ident[EI_OSABI] identifies the operating system and
    ABI to which the object is targeted. Some fields in other
    ELF structures have flags and values that have operating
    system and/or ABI specific meanings; the interpretation of
    those fields is determined by the value of this byte. The
    value of this byte must be interpreted differently for each
    machine. That is, each value for the e_machine field
    determines a set of values for the EI_OSABI byte. Values are
    assigned by the ABI processor supplement for each machine.
    If the processor supplement does not specify a set of
    values, the value 0 shall be used and indicates unspecified.

We added this around 1998, but the value 0 specified SYSV, and we also had HPUX = 1, and STANDALONE = 255.

I had requested the feature as we started joint talks with Intel, SCO, SGI, Sun, IBM, about porting the various OSes to Itanium. We recognized that each OS was going to have its own set of ELF extensions (because we weren't going to accomplish adding *everything* to the gABI), and per-machine flags and attributes weren't sufficient. We at HP were also interested in using that field to distinguish different ABIs that could conceivably be supported by HP-UX (e.g., running Linux executables directly under HP-UX). The STANDALONE value was intended for embedded applications (including the OS kernel) which did not depend on any underlying ABI.

By January 1999, we had added values for NETBSD = 2 (although it was at first labeled "Unspecified), LINUX = 3, SOLARIS = 6, ..., through IRIX = 12. STANDALONE was still defined, and there was no architecture-specific range. During those discussions, it was generally assumed that the field would only be needed for EM_IA_64 (Itanium).

In the July 2000 draft of the gABI, OSABI was completely architecture specific; the psABI was responsible for defining the set of values, and the value 0 meant "unspecified."

The first proposal to reserve separate ranges for gABI and psABI was to make the lower 128 values of the EI_OSABI field for gABI. But we discovered that ARM was already using the value 97 for its psABI, so we agreed to narrow the gABI range to 0-63. By April 2001, 0 had become NONE, and new definitions had been added for FREEBSD, TRU64, MODESTO (Novell), and OPENBSD. STANDALONE had been removed (or relegated to the Itanium psABI), and the architecture-specific range was 64-255.

-cary

To view this discussion visit https://groups.google.com/d/msgid/generic-abi/CADLV35hSzpdbLjPXvEvjxBqxWiH8adDVhTuHnPzviQPFmnBfkw%40mail.gmail.com.