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.

[connor horman]

Is there even a list of the assigned OSABI constants for x86_64? I can't find one.

[Ali Bahrami]

On 2/6/26 12:07 AM, connor horman wrote:
> Is there even a list of the assigned OSABI constants for x86_64? I can't
> find one.
>

You want the gABI:

https://gabi.xinuos.com/elf/b-osabi.html

But note that x86_64 is a machine, not an ABI, so
you really want this:

https://gabi.xinuos.com/elf/a-emachine.html

EM_X86_64 62 AMD x86-64 architecture

I'm sure you already know that though, so are you asking about
OSABI assignments that are specifically only for x86_64? If so
I think these are orthogonal information, not specifically tied
to each other. Any of the OSABIs in appendix B can be combined with
any machine from Appendix A.

I hope that helps, sorry if I missed the actual question.

- Ali

[connor horman]

gABI only assigns OSABIs 0 through 63, and leaves the remaining space for the byte to the psABI to assign.

--
You received this message because you are subscribed to the Google Groups "X86-64 System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to x86-64-abi+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/x86-64-abi/ec3f17aa-a2f7-4c5a-a08f-83c4aa7af08d%40emvision.com.

[connor horman]

Anyways, I have two asks right now: Whether or not there is an existing assignment list (and where it is, if there is one), and what I'd need (tooling and implementation-wise) to receive such an assignment, as I was informed on the gABI list that it may be better to pursue an assignment in the psABI range rather than in the gABI.

[Ali Bahrami]

Oh, of course. Sorry, didn't remember those.

I would assume that those are assigned by the psabi for
each architecture. And I see that you've cc'd the
x86-64-abi list, which seems like the right place
to ask.

I googled it out of curiousity, and then decided to try the
AI, asking "have any oasbi elf architecture-specific values
been defined". It replied yes, giving examples of ARM EABI,
MIPS, and some embedded standalone systems.

So then I tried "have any oasbi elf architecture-specific
values been defined for x86_64", and this time it said no.

I'll be interested to hear what the non-AI answer is, but
I don't believe I've ever heard of it being done.

- Ali

On 2/6/26 12:02 PM, connor horman wrote:
> gABI only assigns OSABIs 0 through 63, and leaves the remaining space
> for the byte to the psABI to assign.
>
>
> On Fri, 6 Feb 2026 at 12:48, Ali Bahrami <ali_e...@emvision.com
> <mailto:ali_e...@emvision.com>> wrote:
>
> On 2/6/26 12:07 AM, connor horman wrote:
> > Is there even a list of the assigned OSABI constants for x86_64?
> I can't
> > find one.
> >
>
>
> You want the gABI:
>

> https://gabi.xinuos.com/elf/b-osabi.html <https://gabi.xinuos.com/
> elf/b-osabi.html>

>
> But note that x86_64 is a machine, not an ABI, so
> you really want this:
>

> https://gabi.xinuos.com/elf/a-emachine.html <https://
> gabi.xinuos.com/elf/a-emachine.html>

>
>      EM_X86_64    62    AMD x86-64 architecture
>
> I'm sure you already know that though, so are you asking about
> OSABI assignments that are specifically only for x86_64? If so
> I think these are orthogonal information, not specifically tied
> to each other. Any of the OSABIs in appendix B can be combined with
> any machine from Appendix A.
>
> I hope that helps, sorry if I missed the actual question.
>
> - Ali
>
> --
> You received this message because you are subscribed to the Google
> Groups "X86-64 System V Application Binary Interface" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to x86-64-abi+...@googlegroups.com

> <mailto:x86-64-abi%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/
> x86-64-abi/ec3f17aa-a2f7-4c5a-a08f-83c4aa7af08d%40emvision.com

> <https://groups.google.com/d/msgid/x86-64-abi/ec3f17aa-a2f7-4c5a-
> a08f-83c4aa7af08d%40emvision.com>.
>

[Roland McGrath]

I think indeed it simply has not been done before x86-64, not because it's not a well-defined part of the psABI's purview, but because it's just literally never come up before.  Nobody has wanted to use such a value.

From a quick glance at the actual ABI details in the linked OS-specific spec, it looks like fairly generic pure ABI choices that are not especially related to this OS per se.  If those differences from other systems' ABIs are really what this is about, then it's also possible to take a different tack that doesn't entail tool support specific to an OS per se.  In terms of getting a wide range of tools to support the format and conventions a new and small OS wants to use and have that cleanly maintained across many tools for a long time, there may be benefit in doing things that are more generic.  What I have in mind here is the GNU properties mechanism.  The general format is defined by the GNU gABI and, and the x86-64 psABI already specifies the use of that format with psABI-specific details.  So far x86-64 has defined properties quite thoroughly for ISA support issues.  It has not yet specified details on using that mechanism for software ABI issues such as calling conventions, floating-point formats, etc.  But other psABIs specify the same or very similar formats and do use them for various software ABI purposes, in particular ARM/AArch64 and RISC-V psABIs use the attribute/property sort of scheme in this way as well as for the ISA things analogous to existing x86-64 psABI specs for GNU property stuff.  So this is something that I think it would make sense for the x86-64 psABI generically and could naturally cover all the things I saw mentioned as motivating distinctions of the proposed new OSABI value.

I'm not at all discouraging the very slight breaking of new ground in assigning an x86-64 psABI-specific OSABI value for Lilium.  But I've never been a fan of OSABI as a proxy for pure software feature sets (whether calling conventions or ELF dynamic linking features) rather than finer-grained indicators of exactly what matters where.  And there does seem to be plenty of precedent for taking the fine-grained approach, so I thought I'd mention the idea.

[connor horman]

The OSABI is responsible for determining the interpretation of the {PT,SHT,DT}_{LO,HI}OS ranges. Generic tooling won't be able to recognize the extended features without an OSABI constant. Obviously, lilium specific tooling, like its dynamic linker, will be able to happily ignore ELFOSABIGENERIC in determining how to interpret the dynamic tags and program headers, but linkers, and tools like objdump won't know what the value means. Some future extensions (like the hash scheme that is being designed still) may make sense to "genericise" in the future (either into gABI or the psABI), but the main one that's been adopted for now, {DT, SHT}_REQUIRE_SUBSYSTEMS is specific to Lilium and doesn't have a generic version (it specifically interacts with system interfaces that are only provided on Lilium). It also needs specific support from the static linker, hence the specification requiring SHF_OS_NONCONFORMING to be set (on top of emitting a dynamic tag, it needs string references moved to `.dynstr` from `.strtab`, as well as deduplication) I also don't follow the "GNU" scheme of "Pick a number that's probably unique" as, given the space, that's bound to fail eventually. Obviously for preexisting GNU extensions that are copied over, those are preserved with their numbers (mostly because it's too much hassle to not make use of them, and also DT_GNU_HASH is leagues better than the gABI DT_HASH, even if it itself is not very good imo). 

The x86-64 specific changes are also something I don't think fits in the generic psABI, as it wouldn't be easily compatible (namely, `long double` being 64-bit instead of 80-bit). They could perhaps be adopted as a "Sub ABI", like x32, but I don't know if they'd ever be reused (I've never seen anything else on x86_64 use f64 long double - looking at gcc, bionic does on 32-bit, but it uses f128 on 64-bit).

There is also a separate initialization spec (which has not yet been merged) that allows certain assumptions to be made about certain registers (at the very least, rax - depending on the value read, other registers may have defined meaning as well) when control is given to the entry point, beyond what the psABI allows. This could more reasonably be a property flag, but it's useful IMO to at least have some way to make it obvious that this thing ought not to load on other OS's/dynamic linkers that don't follow the same spec. That could very well be generalized, assuming that a property was defined (I don't want to propose it to the general purpose ABI yet, though). 

[Florian Weimer]

* Roland McGrath:

> I'm not at all discouraging the very slight breaking of new ground in
> assigning an x86-64 psABI-specific OSABI value for Lilium. But I've
> never been a fan of OSABI as a proxy for pure software feature sets
> (whether calling conventions or ELF dynamic linking features) rather
> than finer-grained indicators of exactly what matters where. And
> there does seem to be plenty of precedent for taking the fine-grained
> approach, so I thought I'd mention the idea.

As a compromise, we could declare the OSABI values from (say) 250 to 255
as reserved for private use in the x86-64 ABI. Then people can do
whatever they want with them, and graduate to something else if certain
usage patterns emerge.

The generic ABI does not reserve any values for private use.

Thanks,
Florian

[connor horman]

Having a Private Use Area would be suitable in this case, at least for now. 
Using 240 to 255 would be nice and clean (0xF0 to 0xFF instead of 0xFA to 0xFF), though 0xFF is commonly used to mean "STANDALONE" so it may be better to not rule out using it like that here.