[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 9 Jan 2013 23:03:19 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Remaining ABI issues
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.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
