These constants are not specified by POSIX, but they are in the reserved
namespace, glibc and bsd systems seem to provide them as well.
(Note that POSIX specifies -NZERO and NZERO-1 to be the limits, but
PRIO_MAX equals NZERO)
mips has signal numbers up to 127 (formerly, up to 128, but the last
one never worked right and caused kernel panic when used), so 127 in
the "signal number" field of the wait status is insufficient for
determining that the process was stopped. in addition, a nonzero value
in the upper bits must be present, indicating the signal number which
caused the process to be stopped.
details on this issue can be seen in the email with message id
CAAG0J9-d4BfEhbQovFqUAJ3QoOuXScrpsY1y95PrEPxA5DWedQ@mail.gmail.com on
the linux-mips mailing list, archived at:
http://www.linux-mips.org/archives/linux-mips/2013-06/msg00552.html
and in the associated thread about fixing the mips kernel bug.
commit 4a96b948687166da26a6c327e6c6733ad2336c5c fixed the
corresponding issue in uClibc, but introduced a multiple-evaluation
issue for the WIFSTOPPED macro.
for the most part, none of these issues affected pure musl systems,
since musl has up until now (incorrectly) defined SIGRTMAX as 64 on
all archs, even mips. however, interpreting status of non-musl
programs on mips may have caused problems. with this change, the full
range of signal numbers can be made available on mips.
also add a warning to the existing sys/poll.h. the warning is absent
from sys/dir.h because it is actually providing a slightly different
API to the program, and thus just replacing the #include directive is
not a valid fix to programs using this one.
linux commit 8d36eb01da5d371feffa280e501377b5c450f5a5 (2013-05-29)
added PF_IB for InfiniBand
linux commit d021c344051af91f42c5ba9fdedc176740cbd238 (2013-02-06)
added PF_VSOCK for VMware sockets
during the header refactoring, I had moved u_int64_t out of alltypes
under the assumption that we could just use long long everywhere.
however, it seems some broken applications make inconsistent mixed use
of u_int64_t and uint64_t, resulting in build errors when the
underlying type differs.
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
while there's no POSIX namespace provision for UIO_* in uio.h, this
exact macro name is reserved in XBD 2.2.2. apparently some
glibc-centric software expects it to exist, so let's provide it.
the main use for this macro seems to be knowing the correct allocation
granularity for dynamic-sized fd_set objects. such usage is
non-conforming and results in undefined behavior, but it is widespread
in applications.
in theory this should not be an issue, since major() should only be
applied to type dev_t, which is 64-bit. however, it appears some
applications are not using dev_t but a smaller integer type (which
works on Linux because the kernel's dev_t is really only 32-bit). to
avoid the undefined behavior, do it as two shifts.
rejecting invalid values for n is fine even in the case where a new
sem will not be created, since the kernel does its range checks on n
even in this case as well.
by default, the kernel will bound the limit well below USHRT_MAX
anyway, but it's presumably possible that an administrator could
override this limit and break things.
this type is not really intended to be used; it's just there to allow
implementations to choose the type for the shm_nattch member of
struct shmid_sh, presumably since historical implementations disagreed
on the type. in any case, it needs to be there, so now it is.
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.
this fix is far from ideal and breaks the rule of not using
arch-specific #ifdefs, but for now we just need a solution to the
existing breakage.
the underlying problem is that the kernel folks made a very stupid
decision to make misalignment of this struct part of the kernel
API/ABI for x86_64, in order to avoid writing a few extra lines of
code to handle both 32- and 64-bit userspace on 64-bit kernels. I had
just added the packed attribute unconditionally thinking it was
harmless on 32-bit archs, but non-x86 32-bit archs have 8-byte
alignment on 64-bit types.
added various MS_*, MNT_*, UMOUNT_* flags following the linux
headers, with one exception: MS_NOUSER is defined as (1U<<31)
instead of (1<<31) which invokes undefined behaviour
the S_* flags were removed following glibc
these flags are needed in order to be able to handle lwp id's
which the kernel returns after clone() calls for new threads
via ptrace(PTRACE_GETEVENTMSG).
fortunately, they're the same for all archs and in the reserved
namespace.
the old definitions were wrong on some archs. actually, EPOLL_NONBLOCK
probably should not even be defined; it is not accepted by the kernel
and it's not clear to me whether it has any use at all, even if it did
work. this issue should be revisited at some point, but I'm leaving it
in place for now in case some applications reference it.
despite glibc using __key and __seq rather than key and seq, some
applications, notably busybox, assume the names are key and seq unless
glibc is being used. and the names key and seq are really the ones
that _should_ be exposed when not attempting to present a
standards-conforming namespace; apps should not be using names that
begin with double-underscore. thus, the optimal fix is to use key and
seq as the actual names of the members when in bsd/gnu source profile,
and define macros for __key and __seq that redirect to plain key and
seq.
traditionally, both BSD and GNU systems have it this way.
sys/syscall.h is purely syscall number macros. presently glibc exposes
the syscall declaration in unistd.h only with _GNU_SOURCE, but that
does not reflect historical practice.
previously the names were exposed as key/seq with _GNU_SOURCE and
__ipc_perm_key/__ipc_perm/seq otherwise, whereas glibc always uses
__key and __seq for the names. thus, the old behavior never matched
glibc, and the new behavior always does, regardless of feature test
macros.
for now, i'm leaving the renaming here in sys/ipc.h where it's easy to
change globally for all archs, in case something turns out to be
wrong, but eventually the names could just be incorporated directly
into the bits headers for each arch and the renaming removed.
previously, a few BSD features were enabled only by _BSD_SOURCE, not
by _GNU_SOURCE. since _BSD_SOURCE is default in the absence of other
feature test macros, this made adding _GNU_SOURCE to a project not a
purely additive feature test macro; it actually caused some features
to be suppressed.
most of the changes made by this patch actually bring musl in closer
alignment with the glibc behavior for _GNU_SOURCE. the only exceptions
are the added visibility of functions like strlcpy which were BSD-only
due to being disliked/rejected by glibc maintainers. here, I feel the
consistency of having _GNU_SOURCE mean "everything", and especially
the property of it being purely additive, are more valuable than
hiding functions which glibc does not have.
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.
apparently some other archs have sys/io.h and should not break just
because they don't have the x86 port io functions. provide a blank
bits/io.h everywhere for now.
based on proposal by Isaac Dunham. nonexistance of bits/io.h will
cause inclusion of sys/io.h to produce an error on archs that are not
supposed to have it. this is probably the desired behavior, but the
error message may be a bit unusual.
although a number is reserved for it, this option is not implemented
on Linux and does not work. defining it causes some applications to
use it, and subsequently break due to its failure.
now public syscall.h only exposes __NR_* and SYS_* constants and the
variadic syscall function. no macros or inline functions, no
__syscall_ret or other internal details, no 16-/32-bit legacy syscall
renaming, etc. this logic has all been moved to src/internal/syscall.h
with the arch-specific parts in arch/$(ARCH)/syscall_arch.h, and the
amount of arch-specific stuff has been reduced to a minimum.
changes still need to be reviewed/double-checked. minimal testing on
i386 and mips has already been performed.
the old behavior of exposing nothing except plain ISO C can be
obtained by defining __STRICT_ANSI__ or using a compiler option (such
as -std=c99) that predefines it. the new default featureset is POSIX
with XSI plus _BSD_SOURCE. any explicit feature test macros will
inhibit the default.
installation docs have also been updated to reflect this change.
to deal with the fact that the public headers may be used with pre-c99
compilers, __restrict is used in place of restrict, and defined
appropriately for any supported compiler. we also avoid the form
[restrict] since older versions of gcc rejected it due to a bug in the
original c99 standard, and instead use the form *restrict.
while musl itself requires a c99 compiler, some applications insist on
being compiled with c89 compilers, and use of "inline" in the headers
was breaking them. much of this had been avoided already by just
skipping the inline keyword in pre-c99 compilers or modes, but this
new unified solution is cleaner and may/should result in better code
generation in the default gcc configuration.
based on patches by orc and Isaac Dunham, with some fixes. sys/io.h
exists and contains prototypes for these functions regardless of
whether the target arch has them; this is a bit unorthodox but I don't
think it will break anything. the function definitions do not exist
unless the appropriate SYS_* syscall number macro is defined, which
should make sure configure scripts looking for these functions don't
find them on other systems.
presently, sys/io.h does not have the inb/outb/etc. port io
macros/functions. I'd be surprised if ioperm/iopl are useful without
them, so they probably need to be added at some point in appropriate
bits/io.h files...
the kernel wrongly expects the cmsg length field to be size_t instead
of socklen_t. in order to work around the issue, we have to impose a
length limit and copy to a local buffer. the length limit should be
more than sufficient for any real-world use; these headers are only
used for passing file descriptors and permissions between processes
over unix sockets.
this is ugly and stupid, but now that the *64 symbol names exist, a
lot of broken GNU software detects them in configure, then either
breaks during build due to missing off64_t definition, or attempts to
compile without function declarations/prototypes. "fixing" it here is
easier than telling everyone to add yet another feature test macro to
their builds.
there is no reason to avoid multiple identical macro definitions; this
is perfectly legal C, and even with the maximal warning options
enabled, gcc does not issue any warning for it.
- add the rest of the junk traditionally in sys/param.h
- add prototypes for some nonstandard functions
- add _GNU_SOURCE to their source files so the compiler can check proto
the changes to syscall_ret are mostly no-ops in the generated code,
just cleanup of type issues and removal of some implementation-defined
behavior. the one exception is the change in the comparison value,
which is fixed so that 0xf...f000 (which in principle could be a valid
return value for mmap, although probably never in reality) is not
treated as an error return.
casting to int would not be correct because high bits could be lost.
mapping the high bits down onto low bits would be costlier in the
common case where the result is just used in a conditional. changing
the type of the bit array elements to int would permute the order of
the bit array on 64-bit big endian systems, so that's not an option
either.
this is a case of poorly written man pages not matching the actual
implementation, and why i hate implementing nonstandard interfaces
with no actual documentation of how they're intended to work.
some of these definitions were just plain wrong, others based on
outdated ancient "non-64" versions of the kernel interface.
as much as possible has now been moved out of bits/*
these changes break abi (the old abi for these functions was wrong),
but since they were not working anyway it can hardly matter.
with this patch, the syscallN() functions are no longer needed; a
variadic syscall() macro allows syscalls with anywhere from 0 to 6
arguments to be made with a single macro name. also, manually casting
each non-integer argument with (long) is no longer necessary; the
casts are hidden in the macros.
some source files which depended on being able to define the old macro
SYSCALL_RETURNS_ERRNO have been modified to directly use __syscall()
instead of syscall(). references to SYSCALL_SIGSET_SIZE and SYSCALL_LL
have also been changed.
x86_64 has not been tested, and may need a follow-up commit to fix any
minor bugs/oversights.
this commit shuffles around the location of syscall definitions so
that we can make a syscall() library function with both SYS_* and
__NR_* style syscall names available to user applications, provides
the syscall() library function, and optimizes the code that performs
the actual inline syscalls in the library itself.
previously on i386 when built as PIC (shared library), syscalls were
incurring bus lock (lock prefix) overhead at entry and exit, due to
the way the ebx register was being loaded (xchg instruction with a
memory operand). now the xchg takes place between two registers.
further cleanup to arch/$(ARCH)/syscall.h is planned.
this is a nonstandard header used only by backwards programs, but for
some reason it's extremely popular. the recent namespace cleanup fixes
broke it, because PATH_MAX and NAME_MAX will not be defined unless an
approriate feature test macro has been defined. moreover, it's too
late to just #define _GNU_SOURCE in param.h, since limits.h may have
already been included.
let's just hard-code standard values and be done with it.
this allows sys/types.h to provide the pthread types, as required by
POSIX. this design also facilitates forcing ABI-compatible sizes in
the arch-specific alltypes.h, while eliminating the need for
developers changing the internals of the pthread types to poke around
with arch-specific headers they may not be able to test.
