|
Message-ID: <20130110040319.GA5159@brightrain.aerifal.cx> 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.