unfortunately this needs to be able to vary by arch, because of a huge
mess GCC made: the GCC definition, which became the ABI, depends on
quirks in GCC's definition of __alignof__, which does not match the
formal alignment of the type.
GCC's __alignof__ unexpectedly exposes the an implementation detail,
its "preferred alignment" for the type, rather than the formal/ABI
alignment of the type, which it only actually uses in structures. on
most archs the two values are the same, but on some (at least i386)
the preferred alignment is greater than the ABI alignment.
I considered using _Alignas(8) unconditionally, but on at least one
arch (or1k), the alignment of max_align_t with GCC's definition is
only 4 (even the "preferred alignment" for these types is only 4).
when manipulating the robust list, the order of stores matters,
because the code may be asynchronously interrupted by a fatal signal
and the kernel will then access the robust list in what is essentially
an async-signal context.
previously, aliasing considerations made it seem unlikely that a
compiler could reorder the stores, but proving that they could not be
reordered incorrectly would have been extremely difficult. instead
I've opted to make all the pointers used as part of the robust list,
including those in the robust list head and in the individual mutexes,
volatile.
in addition, the format of the robust list has been changed to point
back to the head at the end, rather than ending with a null pointer.
this is to match the documented kernel robust list ABI. the null
pointer, which was previously used, only worked because faults during
access terminate the robust list processing.
linux 3.14 introduced sched_getattr and sched_setattr syscalls in
commit d50dde5a10f305253cbc3855307f608f8a3c5f73
and the related SCHED_DEADLINE scheduling policy in
commit aab03e05e8f7e26f51dee792beddcb5cca9215a5
but struct sched_attr "extended scheduling parameters data structure"
is not yet exported to userspace (necessary for using the syscalls)
so related uapi definitions are not added yet.
The mips arch is special in that it uses different RLIMIT_
numbers than other archs, so allow bits/resource.h to override
the default RLIMIT_ numbers (empty on all archs except mips).
Reported by orc.
the excess space was unused and unintentional. this change does not
affect the ABI between applications and libc. while it does
theoretically affect linkage between third-party translation units
using jmp_buf as part of a structure, we've already changed jmp_buf at
least once on all archs, and problems were never observed, likely
because such usage would be very unusual. in any case it's best to get
things right now rather than making changes sometime during the 1.0.x
series or later.
The mips statfs struct layout is different than on other archs, so the
statfs, fstatfs, statvfs and fstatvfs APIs were broken on mips.
Now the ordering is fixed, the types are kept consistent with other archs.
the definition was found to be incorrect at least for powerpc, and
fixing this cleanly requires making the definition arch-specific. this
will allow cleaning up the definition for other archs to make it more
specific, and reversing some of the ugliness (time_t hacks) introduced
with the x32 port.
this first commit simply copies the existing definition to each arch
without any changes. this is intentional, to make it easier to review
changes made on a per-arch basis.
Userspace emulated floating-point (gcc -msoft-float) is not compatible
with the default mips abi (assumes an FPU or in kernel emulation of it).
Soft vs hard float abi should not be mixed, __mips_soft_float is checked
in musl's configure script and there is no runtime check. The -sf subarch
does not save/restore floating-point registers in setjmp/longjmp and only
provides dummy fenv implementation.
the fix should be complete on archs that use the generic definitions
(i386, arm, x86_64, microblaze), but mips and powerpc have not been
checked thoroughly and may need more fixes.
previously these macros wrongly had type double rather than long
double. I see no way an application could detect the error in C99, but
C11's _Generic can trivially detect it.
at the same time, even though these archs do not have excess
precision, the number of decimal places used to represent these
constants has been increased to 21 to be consistent with the decimal
representations used for the DBL_* macros.
PAGE_SIZE was hardcoded to 4096, which is historically what most
systems use, but on several archs it is a kernel config parameter,
user space can only know it at execution time from the aux vector.
PAGE_SIZE and PAGESIZE are not defined on archs where page size is
a runtime parameter, applications should use sysconf(_SC_PAGE_SIZE)
to query it. Internally libc code defines PAGE_SIZE to libc.page_size,
which is set to aux[AT_PAGESZ] in __init_libc and early in __dynlink
as well. (Note that libc.page_size can be accessed without GOT, ie.
before relocations are done)
Some fpathconf settings are hardcoded to 4096, these should be actually
queried from the filesystem using statfs.
msg.h was wrong for big-endian (wrong endiannness padding).
shm.h was just plain wrong (mips is not supposed to have padding).
both changes were tested using libc-test on qemu-system-mips.
a mips signal mask contains 128 bits, enough for signals 1 through
128. however, the exit status obtained from the wait-family functions
only has room for values up to 127. reportedly signal 128 was causing
kernelspace bugs, so it was removed from the kernel recently; even
without that issue, however, it was impossible to support it correctly
in userspace.
at the same time, the bug was masked on musl by SIGRTMAX incorrectly
yielding 64 on mips, rather than the "correct" value of 128. now that
the _NSIG issue is fixed, SIGRTMAX can be fixed at the same time,
exposing the full range of signals for application use.
note that the (nonstandardized) libc _NSIG value is actually one
greater than the max signal number, and also one greater than the
kernel headers' idea of _NSIG. this is the reason for the discrepency
with the recent kernel changes. since reducing _NSIG by one brought it
down from 129 to 128, rather than from 128 to 127, _NSIG/8, used
widely in the musl sources, is unchanged.
this is necessary to meet the C++ ABI target. alternatives were
considered to avoid the size increase for non-sig jmp_buf objects, but
they seemed to have worse properties. moreover, the relative size
increase is only extreme on x86[_64]; one way of interpreting this is
that, if the size increase from this patch makes jmp_buf use too much
memory, then the program was already using too much memory when built
for non-x86 archs.
rather than moving nlink_t back to the arch-specific file, I've added
a macro _Reg defined to the canonical type for register-size values on
the arch. this is not the same as _Addr for (not-yet-supported)
32-on-64 pseudo-archs like x32 and mips n32, so a new macro was
needed.
aside from the obvious C++ ABI purpose for this change, it also brings
musl into alignment with the compiler's idea of the definition of
wint_t (use in -Wformat), and makes the situation less awkward on ARM,
where wchar_t is unsigned.
internal code using wint_t and WEOF was checked against this change,
and while a few cases of storing WEOF into wchar_t were found, they
all seem to operate properly with the natural conversion from unsigned
to signed.
the arch-specific bits/alltypes.h.sh has been replaced with a generic
alltypes.h.in and minimal arch-specific bits/alltypes.h.in.
this commit is intended to have no functional changes except:
- exposing additional symbols that POSIX allows but does not require
- changing the C++ name mangling for some types
- fixing the signedness of blksize_t on powerpc (POSIX requires signed)
- fixing the limit macros for sig_atomic_t on x86_64
- making dev_t an unsigned type (ABI matching goal, and more logical)
in addition, some types that were wrongly defined with long on 32-bit
archs were changed to int, and vice versa; this change is
non-functional except for the possibility of making pointer types
mismatch, and only affects programs that were using them incorrectly,
and only at build-time, not runtime.
the following changes were made in the interest of moving
non-arch-specific types out of the alltypes system and into the
headers they're associated with, and also will tend to improve
application compatibility:
- netdb.h now includes netinet/in.h (for socklen_t and uint32_t)
- netinet/in.h now includes sys/socket.h and inttypes.h
- sys/resource.h now includes sys/time.h (for struct timeval)
- sys/wait.h now includes signal.h (for siginfo_t)
- langinfo.h now includes nl_types.h (for nl_item)
for the types in stdint.h:
- types which are of no interest to other headers were moved out of
the alltypes system.
- fast types for 8- and 64-bit are hard-coded (at least for now); only
the 16- and 32-bit ones have reason to vary by arch.
and the following types have been changed for C++ ABI purposes;
- mbstate_t now has a struct tag, __mbstate_t
- FILE's struct tag has been changed to _IO_FILE
- DIR's struct tag has been changed to __dirstream
- locale_t's struct tag has been changed to __locale_struct
- pthread_t is defined as unsigned long in C++ mode only
- fpos_t now has a struct tag, _G_fpos64_t
- fsid_t's struct tag has been changed to __fsid_t
- idtype_t has been made an enum type (also required by POSIX)
- nl_catd has been changed from long to void *
- siginfo_t's struct tag has been removed
- sigset_t's has been given a struct tag, __sigset_t
- stack_t has been given a struct tag, sigaltstack
- suseconds_t has been changed to long on 32-bit archs
- [u]intptr_t have been changed from long to int rank on 32-bit archs
- dev_t has been made unsigned
summary of tests that have been performed against these changes:
- nsz's libc-test (diff -u before and after)
- C++ ABI check symbol dump (diff -u before, after, glibc)
- grepped for __NEED, made sure types needed are still in alltypes
- built gcc 3.4.6
this change is both to fix one of the remaining type (and thus C++
ABI) mismatches with glibc/LSB and to allow use of the full range of
uid and gid values, if so desired.
passwd/group access functions were not prepared to deal with unsigned
values, so they too have been fixed with this commit.
despite declaring functions that take arguments of type va_list, these
headers are not permitted by the c standard to expose the definition
of va_list, so an alias for the type must be used. the name
__isoc_va_list was chosen to convey that the purpose of this alternate
name is for iso c conformance, and to avoid the multitude of names
which gcc mangles with its hideous "fixincludes" monstrosity, leading
to serious header breakage if these "fixes" are run.
previously we were using an unsigned type on 32-bit systems so that
subtraction would be well-defined when it wrapped, but since wrapping
is non-conforming anyway (when clock() overflows, it has to return -1)
the only use of unsigned would be to buy a little bit more time before
overflow. this does not seem worth having the type vary per-arch
(which leads to more arch-specific bugs) or disagree with the ABI musl
(mostly) follows.
there was some question as to how many decimal places to use, since
one decimal place is always sufficient to identify the smallest
denormal uniquely. for now, I'm following the example in the C
standard which is consistent with the other min/max macros we already
had in place.
the preprocessor can reliably determine the signedness of wchar_t.
L'\0' is used for 0 in the expressions so that, if the underlying type
of wchar_t is long rather than int, the promoted type of the
expression will match the type of wchar_t.
this type was removed back in 5243e5f160 ,
because it was removed from the XSI specs.
however some apps use it.
since it's in the POSIX reserved namespace, we can expose it
unconditionally.
wctype_t was incorrectly "int" rather than "long" on x86_64. not only
is this an ABI incompatibility; it's also a major design flaw if we
ever wanted wctype_t to be implemented as a pointer, which would be
necessary if locales support custom character classes, since int is
too small to store a converted pointer. this commit fixes wctype_t to
be unsigned long on all archs, matching the LSB ABI; this change does
not matter for C code, but for C++ it affects mangling.
the same issue applied to wctrans_t. glibc/LSB defines this type as
const __int32_t *, but since no such definition is visible, I've just
expanded the definition, int, everywhere.
it would be nice if these types (which don't vary by arch) could be in
wctype.h, but the OB XSI requirement in POSIX that wchar.h expose some
types and functions from wctype.h precludes doing so. glibc works
around this with some hideous hacks, but trying to duplicate that
would go against the intent of musl's headers.
these structures are purely for use by trace/debug tools and tools
working with core files. the definition of fpregset_t, which was
previously here, has been removed because it was wrong; fpregset_t
should be the type used in mcontext_t, not the type used in
ptrace/core stuff.
aside from microblaze, these should be roughly correct for all archs
now. some misc junk macros and typedefs are missing, which should
probably be added for max compatibility with trace/debug tools.
with these changes, the members/types of mcontext_t and related stuff
should closely match the glibc definitions. unlike glibc, however, the
definitions here avoid using typedefs as much as possible and work
directly with the underlying types, to minimize namespace pollution
from signal.h in the default (_BSD_SOURCE) profile.
this is a first step in improving compatibility with applications
which poke at context/register information -- mainly debuggers, trace
utilities, etc. additional definitions in ucontext.h and other headers
may be needed later.
if feature test macros are used to request a conforming namespace,
mcontext_t is replaced with an opaque structure of the equivalent size
and alignment; conforming programs cannot examine its contents anyway.
Rich Felker
Szabolcs Nagy
rofl0r