Features Download
From: Rich Felker <dalias <at> aerifal.cx>
Subject: Remaining ABI issues
Newsgroups: gmane.linux.lib.musl.general
Date: Thursday 10th January 2013 04:03:19 UTC (over 4 years ago)
At present, to my knowledge, musl's ABI for the C language
application/libc interface fully matches glibc's for all interfaces
and types that are supported, with the exceptions of:

1. Functions that take off_t are always the 64-bit versions on 32-bit
   archs, whereas glibc has separate legacy 32-bit functions.

2. The regoff_t type is 64-bit on 64-bit archs, as required by POSIX,
   whereas glibc incorrectly has it defined as 32-bit on 64-bit archs.

These issues are not things we can "fix", because they're flaws in
glibc; support for applications affected by these differences will
have to come with special fixups performed by the dynamic linker,
which could be added at a later time if needed.

With that said, aside from the C language application/libc interface,
there are at least 2 other ABI issues that are relevant to using
binary code that was originally intended for use on glibc:

1. Data type size issues that do not affect the app/libc interface,
   but which could affect ABI between application components which use
   these types, e.g. in non-libc-defined structures shared between
   third-party libraries and applications.

2. The C++ name-mangling ABI, which depends not only on the size and
   method of argument passing used by a type, but also the type's
   underlying identity in the C++ type system, including the exact
   name of the struct or union tag underlying struct or union types.

The main type-1 issue I'm aware of is that our jmp_buf does not match
glibc's in size. glibc's jmp_buf is bloated by 128 bytes to store a
HURD sigset_t; this is because in certain legacy modes they want to
support, setjmp actually behaves as sigsetjmp and needs a place to
store signal masks. musl's jmp_buf only contains space for the machine
registers, and musl's sigjmp_buf contains space for an entire hurd
sigset_t (128 bytes) despite the fact that musl treats all but the
first 64 or 128 bits (depending on arch) as padding.

As for type-2 issues (C++ ABI), there are a number I'm aware of and
probably plenty more I'm not aware of, where we don't match glibc and
thus can't work with glibc-targeted shared library binaries or
applications written in C++:

- FILE, mbstate_t, and fpos_t tags don't match glibc's.

- Underlying type of pthread_t is pointer in musl, long in glibc

- Type of timer_t is a pointer in musl; this is actually
  non-conforming to POSIX as well as being incompatible with glibc.

- Not only do the struct tags underlying jmp_buf and sigjmp_buf
  mismatch glibc's; worse, glibc uses the SAME tag for both (i.e.
  they're the same type).

At this point, I think we should have a serious discussion of whether
either or both of the "type-1" and "type-2" ABI issues matters; this
certainly needs to happen before 1.0, and until it happens, we can't
even declare musl to have a stable C++ ABI (since we might go and
change it), much less a glibc-compatible C++ ABI.

Note that neither type-1 nor type-2 issues affect the interface
between applications or third-party libraries and libc whatsoever.
Both are essentially ABI issues between two or more pieces of
third-party code (apps or libraries) that derive part of their own
ABIs from the libc headers.

If we decide that type-2 matters but type-1 doesn't, the jmp_buf issue
could be fixed by making both jmp_buf and sigjmp_buf the same type,
but with only 8 or 16 bytes of signal mask space, rather than 128
bytes. This would be a fairly low cost. If on the other hand we wanted
to address type-1, both would need the full bloat (and musl should
probably get an extra internal-use-only jmp_buf type to avoid internal
bss/data bloat).

The goals of this thread should be:

1. Obtain an overview of opinions on the course of action we should
   take, and the reasoning behind them, regarding these two types of
   ABI issues.

2. Compile a list of the types that would need to be changed to
   address either or both issues, in order to ascertain the difficulty
   and cost of making changes.

It's on these two areas that I would like help and feedback.

CD: 4ms