fix broken lseek on mipsn32 with offsets larger than LONG_MAX
mips n32 has 32-bit long, and generally uses long syscall arguments
and return values, but provides only SYS_lseek, not SYS_llseek. we
have some framework (syscall_arg_t, added for x32) to make syscall
arguments 64-bit in such a setting, but it's not clear whether this
could match the sign-extension semantics needed for 32-bit args to all
the other syscalls, and we don't have any existing mechanism to allow
the return value of syscalls to be something other than long.
instead, just provide a custom mipsn32 version of the lseek function
doing its own syscall asm with 64-bit arguments. as a result of commit 03919b26ed41c31876db41f7cee076ced4513fad, stdio will also get the new
code, fixing fseeko/ftello too.
ever since inline syscalls were added for (o32) mips in commit 328810d32524e4928fec50b57e37e1bf330b2e40, the asm has nonsensically
loaded the syscall number, rather than taking $2 as an input
constraint to let the compiler load it. commit cfc09b1ecf0c6981494fd73dffe234416f66af10 improved on this somewhat by
allowing a constant syscall number to propagate into an immediate, but
missed that the whole operation made no sense.
now, only $4, $5, $6, $8, and $9 are potential input-only registers.
$2 is always input and output, and $7 is both when it's an argument,
otherwise output-only. previously, $7 was treated as an input (with a
"1" constraint matching its output position) even when it was not an
input, which was arguably undefined behavior (asm input from
indeterminate value). this is corrected.
this patch is not purely non-functional changes, since before, $8 and
$9 were wrongly in the clobberlist for syscalls with fewer than 5 or 6
arguments. of course it's impossible for syscalls to have different
clobbers depending on their number of arguments. the clobberlist for
the recently-added 5- and 6-argument forms was correct, and for the 0-
to 4-argument forms was erroneously copied from the mips o32 ABI where
the additional arguments had to be passed on the stack.
in making this change, I reviewed the kernel sources, and $8 and $9
are always saved for 64-bit kernels since they're part of the syscall
argument list for n32 and n64 ABIs.
use namespace-safe __lseek for __stdio_seek instead of direct syscall
this probably saves a few bytes, avoids duplicating the clunky
lseek/_llseek syscall convention in two places, and sets the stage for
fixing broken seeks on x32 and mipsn32.
as before my aim was adding everyone with either substantial code
contributions or a pattern of ongoing simple patch submission; any
omissions are unintentional.
fix build failure on arm building C code in thumb1 mode
a fully thumb1 build is not supported because some asm files are
incompatible with thumb1, but apparently it works to compile the C
code as thumb1
commit 06fbefd10046a0fae7e588b7c6d25fb51811b931 caused this regression
but introducing use of the clz instruction, which is not supported in
arm mode prior to v5, and not supported in thumb prior to thumb2
(v6t2). commit 1b9406b03c0a94ebe2076a8fc1746a8c45e78a83 fixed the
issue only for arm mode pre-v5 but left thumb1 broken.
Samuel Holland [Sat, 29 Jun 2019 23:19:05 +0000 (18:19 -0500)]
use the correct attributes for ___errno_location
In the public header, __errno_location is declared with the "const"
attribute, conditional on __GNUC__. Ensure that its internal alias has
the same attributes.
Maintainer's note: This change also fixes a regression in quality of
code generation -- multiple references to errno in a single function
started generating multiple calls again -- introduced by commit e13063aad7aee341d278d2a879a76ec7b59b2ad8.
Samuel Holland [Sat, 29 Jun 2019 23:19:06 +0000 (18:19 -0500)]
fix conflicting mips and powerpc definitions for TIOCSER_TEMT macro
Commit 3517d74a5e04a377192d1f4882ad6c8dc22ce69a changed the token in
sys/ioctl.h from 0x01 to 1, so bits/termios.h no longer matches. Revert
the bits/termios.h change to keep the headers in sync.
Samuel Holland [Sat, 29 Jun 2019 23:19:04 +0000 (18:19 -0500)]
fix restrict violations in internal use of several functions
The old/new parameters to pthread_sigmask, sigprocmask, and setitimer
are marked restrict, so passing the same address to both is
prohibited. Modify callers of these functions to use a separate object
for each argument.
prevent dup2 action for posix_spawn internal pipe fd
as reported by Tavian Barnes, a dup2 file action for the internal pipe
fd used by posix_spawn could cause it to remain open after execve and
allow the child to write an artificial error into it, confusing the
parent. POSIX allows internal use of file descriptors by the
implementation, with undefined behavior for poking at them, so this is
not a conformance problem, but it seems preferable to diagnose and
prevent the error when we can do so easily.
catch attempts to apply a dup2 action to the internal pipe fd and
emulate EBADF for it instead.
fix inadvertent use of uninitialized variable in dladdr
commit c8b49b2fbc7faa8bf065220f11963d76c8a2eb93 introduced code that
checked bestsym to determine whether a matching symbol was found, but
bestsym is uninitialized if not. instead use best, consistent with use
in the rest of the function.
simplified from bug report and patch by Cheng Liu.
remove spurious MAP_32BIT definition from riscv64 arch
this was apparently copied from x86_64; it's not part of the kernel
API for riscv64. this change eliminates the need for a
riscv64-specific bits header and lets it use the generic one.
Szabolcs Nagy [Thu, 9 May 2019 20:44:27 +0000 (20:44 +0000)]
add new syscall numbers from linux v5.1
syscall numbers are now synced up across targets (starting from 403 the
numbers are the same on all targets other than an arch specific offset)
IPC syscalls sem*, shm*, msg* got added where they were missing (except
for semop: only semtimedop got added), the new semctl, shmctl, msgctl
imply IPC_64, see
a new syscall got added that uses the fd of /proc/<pid> as a stable
handle for processes: allows sending signals without pid reuse issues,
intended to eventually replace rt_sigqueueinfo, kill, tgkill and
rt_tgsigqueueinfo, see
Szabolcs Nagy [Thu, 9 May 2019 22:49:28 +0000 (22:49 +0000)]
ipc: prefer SYS_ipc when it is defined
Linux v5.1 introduced ipc syscalls on targets where previously only
SYS_ipc was available, change the logic such that the ipc code keeps
using SYS_ipc which works backward compatibly on older kernels.
This changes behaviour on microblaze which had both mechanisms, now
SYS_ipc will be used instead of separate syscalls.
Szabolcs Nagy [Thu, 9 May 2019 18:51:53 +0000 (18:51 +0000)]
fcntl.h: add F_SEAL_FUTURE_WRITE from linux v5.1
needed for android so it can migrate from its ashmem to memfd.
allows making the memfd readonly for future users while keeping
a writable mmap of it. see
Samuel Holland [Mon, 1 Jul 2019 03:44:28 +0000 (22:44 -0500)]
fix deadlock in synccall after threaded fork
synccall may be called by AS-safe functions such as setuid/setgid after
fork. although fork() resets libc.threads_minus_one, causing synccall to
take the single-threaded path, synccall still takes the thread list
lock. This lock may be held by another thread if for example fork()
races with pthread_create(). After fork(), the value of the lock is
meaningless, so clear it.
Rich Felker [Fri, 28 Jun 2019 21:58:03 +0000 (17:58 -0400)]
cap getdents length argument to INT_MAX
the linux syscall treats this argument as having type int, so passing
extremely long buffer sizes would be misinterpreted by the kernel.
since "short reads" are always acceptable, just cap it down.
patch based on report and suggested change by Florian Weimer.
Rich Felker [Tue, 25 Jun 2019 22:50:05 +0000 (18:50 -0400)]
remove unnecessary and problematic _Noreturn from crt/ldso startup
after commit a48ccc159a5fa061a18419296100ee48a1cd6cc9 removed the use
of _Noreturn on the stage3_func type (which only worked due to it
being defined to the "GNU C" attribute in C99 mode), GCC could no
longer assume that the ends of __dls2 and __dls2b are unreachable, and
produced a warning that a function marked _Noreturn returns.
also, since commit 4390383b32250a941ec616e8bff6f568a801b1c0, the
_Noreturn declaration for __libc_start_main in crt1/rcrt1 has been not
only inconsistent with the definition, but wrong. formally,
__libc_start_main does return, via a (hopefully) tail call to a helper
function after the barrier. incorrect usage of _Noreturn in the
declaration was probably formal UB.
the _Noreturn specifiers were not useful in any of these places, so
remove them all. now, the only remaining usage of _Noreturn is in
public interfaces where _Noreturn is part of their contract.
Rich Felker [Tue, 25 Jun 2019 21:47:12 +0000 (17:47 -0400)]
allow fmemopen with zero size
previously, POSIX erroneously required this to fail with EINVAL
despite the traditional glibc implementation, on which the POSIX
interface was based, allowing it. the resolution of Austin Group issue
818 removes the requirement to fail.
Rich Felker [Fri, 21 Jun 2019 19:49:38 +0000 (15:49 -0400)]
remove implicit include of sys/sysmacros.h from sys/types.h
this reverts commit f552c792c7ce5a560f214e1104d93ee5b0833967, which
exposed the sysmacros.h macros (device major/minor calculations) for
BSD and GNU profiles to mimic an unintentional glibc behavior some
code depended on. glibc has deprecated and since removed them as the
resolution to bug #19239, so it makes no sense for us to keep this
behavior. affected code should all have been fixed by now, and if it's
not yet fixed it needs to be for use with modern glibc anyway.
Rich Felker [Fri, 24 May 2019 14:46:08 +0000 (10:46 -0400)]
add riscv64 architecture support
Author: Alex Suykov <alex.suykov@gmail.com>
Author: Aric Belsito <lluixhi@gmail.com>
Author: Drew DeVault <sir@cmpwn.com>
Author: Michael Clark <mjc@sifive.com>
Author: Michael Forney <mforney@mforney.org>
Author: Stefan O'Rear <sorear2@gmail.com>
This port has involved the work of many people over several years. I
have tried to ensure that everyone with substantial contributions has
been credited above; if any omissions are found they will be noted
later in an update to the authors/contributors list in the COPYRIGHT
file.
The version committed here comes from the riscv/riscv-musl repo's
commit 3fe7e2c75df78eef42dcdc352a55757729f451e2, with minor changes by
me for issues found during final review:
- a_ll/a_sc atomics are removed (according to the ISA spec, lr/sc
are not safe to use in separate inline asm fragments)
- a_cas[_p] is fixed to be a memory barrier
- the call from the _start assembly into the C part of crt1/ldso is
changed to allow for the possibility that the linker does not place
them nearby each other.
- DTP_OFFSET is defined correctly so that local-dynamic TLS works
- reloc.h LDSO_ARCH logic is simplified and made explicit.
- unused, non-functional crti/n asm files are removed.
- an empty .sdata section is added to crt1 so that the
__global_pointer reference is resolvable.
- indentation style errors in some asm files are fixed.
Rich Felker [Sun, 26 May 2019 23:27:20 +0000 (19:27 -0400)]
optimize aarch64 dynamic tlsdesc function to spill fewer registers
with the glibc generation counter model for reusing dynamic tls slots
after dlclose, it's really not possible to get away with fewer than 4
working registers. for us however it's always been possible, but
tricky, and only became apparent after the switch to installing new
dynamic tls at dlopen time. by merging the negated thread pointer into
the addend early, the register holding the thread pointer can
immediately be reused, bringing the working register count down to
three. this allows saving/restoring via a single stp/ldp pair, since
the return register x0 does not need to be saved.
net reduction of 3 instructions, 2 of which were push/pop.
Rich Felker [Wed, 22 May 2019 22:28:32 +0000 (18:28 -0400)]
make powerpc64 vrregset_t logical layout match expected API
between v2 and v3 of the powerpc64 port patch, the change was made
from a 32x4 array of 32-bit unsigned ints for vrregs[] to a 32-element
array of __int128. this mismatches the API applications working with
mcontext_t expect from glibc, and seems to have been motivated by a
misinterpretation of a comment on how aarch64 did things as a
suggestion to do the same on powerpc64.
Rich Felker [Wed, 22 May 2019 19:17:12 +0000 (15:17 -0400)]
fix vrregset_t layout and member naming on powerpc64
the mistaken layout seems to have been adapted from 32-bit powerpc,
where vscr and vrsave are packed into the same 128-bit slot in a way
that looks like it relies on non-overlapping-ness of the value bits in
big endian.
the powerpc64 port accounted for the fact that the 64-bit ABI puts
each in its own 128-bit slot, but ordered them incorrectly (matching
the bit order used on the 32-bit ABI), and failed to account for vscr
being padded according to endianness so that it can be accessed via
vector moves.
in addition to ABI layout, our definition used different logical
member layout/naming from glibc, where vscr is a structure to
facilitate access as a 32-bit word or a 128-bit vector. the
inconsistency here was unintentional, so fix it.
Szabolcs Nagy [Mon, 13 May 2019 18:47:11 +0000 (18:47 +0000)]
fix tls offsets when p_vaddr%p_align != 0 on TLS_ABOVE_TP targets
currently the bfd linker does not seem to create tls segments where
p_vaddr%p_align != 0, but this is valid in ELF and then the runtime
computed tls offset must satisfy
offset%p_align == (base+p_vaddr)%p_align
and in case of local exec tls (main executable) the smallest such
offset must be used (otherwise it is incompatible with the offset
computed by the static linker). the !TLS_ABOVE_TP case is handled
correctly (the offset is negative then in the formula).
the ldso code for TLS_ABOVE_TP is changed so the static tls offset
of each module satisfies the formula.
Szabolcs Nagy [Thu, 16 May 2019 17:15:33 +0000 (17:15 +0000)]
fix static tls offsets of shared libs on TLS_ABOVE_TP targets
tls_offset should always point to the end of the allocated static tls
area, but this was not handled correctly on "tls variant 1" targets
in the dynamic linker:
after application tls was allocated, tls_offset was aligned up,
potentially wasting tls space. (alignment may be needed at the
begining of the tls area, not at the end, but that will be fixed
separately as it is unlikely to affect real binaries.)
when static tls was allocated for a shared library, tls_offset was
only updated with the size of the tls segment which does not include
alignment gaps, which can easily happen if the tls size update for
one library leaves tls_offset misaligned for the next one. this can
cause oob access in __copy_tls or arbitrary breakage at tls access.
(the issue was observed on aarch64 with rust binaries)
Rich Felker [Thu, 16 May 2019 21:12:56 +0000 (17:12 -0400)]
fix format strings for uid/gid values in putpwent/putgrent
commit 648c3b4e18b2ce2b6af7d44783e42ca267ea49f5 omitted this change,
which is needed to be able to use uid/gid values greater than INT_MAX
with these interfaces. it fixes alpine linux bug #10460.
Rich Felker [Sat, 11 May 2019 23:44:21 +0000 (19:44 -0400)]
improve i386 inline syscall asm on non-broken compilers
we have to avoid using ebx unconditionally in asm constraints for
i386, because gcc 3 and 4 and possibly other simplistic compilers
(pcc?) implement PIC via making ebx a fixed-use register, and disallow
its use for anything else. rather than hard-coding knowledge of which
compilers work (at least gcc 5+ and clang), perform a configure test;
this should give us the good codegen on any new compilers we don't yet
know about.
swapping ebx and edx is kept for 1- and 2-arg syscalls because it
avoids having any spills/stack-frame at all in small functions. for
6-arg, if ebx is directly usable, the complex shuffling introduced in
commit c8798ef974d21c338a7d8d874a402978ffc6168e can be avoided, and
ebp can be loaded the same way ebx is in 5-arg syscalls for compilers
that don't support direct use of ebx.
Rich Felker [Sat, 11 May 2019 00:56:19 +0000 (20:56 -0400)]
fix regression in i386 inline syscall asm producing invalid code
commit 22e5bbd0deadcbd767864bd714e890b70e1fe1df inlined the i386
syscall mechanism, but wrongly assumed memory operands to the 5- and
6-argument syscall asm would be esp-based. however, nothing in the
constraints prevented them from being ebx- or ebp-based, and in those
cases, ebx and ebp could be clobbered before use of the memory operand
was complete. in the 6-argument case, this prevented restoration of
the original register values before the end of the asm block, breaking
the asm contract since ebx and ebp are not marked as clobbered. (they
can't be, because lots of compilers don't accept these registers in
constraints or clobbers if PIC or frame pointer is enabled).
doing this right is complicated by the fact that, after a single push,
no operands which might be memory operands are usable. if they are
esp-based, the value of esp has changed, rendering them invalid.
introduce some new dances to load the registers. for the 5-arg case,
push the operand that may be a memory operand first, and after that,
it doesn't matter if the operand is invalid, since we'll just use the
newly pushed value. for the 6-arg case, we need to put both operands
in memory to begin with, like the old non-inline code prior to commit 22e5bbd0deadcbd767864bd714e890b70e1fe1df accepted, so that there's
only one potentially memory-based operand to the asm. this can then be
saved with a single push, and after that the values can be read off
into the registers they're needed in.
there's some size overhead, but still a lot less execution overhead
than the old out-of-line code. doing it better depends on a modern
compiler that lets you use ebx and ebp in asm constraints without
restriction. the failure modes on compilers where this doesn't work
are inconsistent and dangerous (on at least some gcc versions 4.x and
earlier, wrong codegen!), so this is a delicate matter. it can be
addressed later if needed.
Rich Felker [Mon, 6 May 2019 02:50:57 +0000 (22:50 -0400)]
make fgetwc set error indicator for stream on encoding errors
this is a requirement in POSIX that's omitted, and seemed potentially
non-conforming, in the C standard. as such it was omitted here.
however, as part of Austin Group issue #1170, the discrepancy was
raised with WG14 and determined to be unintended; future versions of
the C standard will require the error indicator to be set, as POSIX
does.
Rich Felker [Sun, 5 May 2019 15:24:57 +0000 (11:24 -0400)]
fix broken posix_fadvise on mips due to missing 7-arg syscall support
commit 788d5e24ca19c6291cebd8d1ad5b5ed6abf42665 exposed the breakage
at build time by removing support for 7-argument syscalls; however,
the external __syscall function provided for mips before did not pass
a 7th argument from the stack, so the behavior was just silently
broken.
Rich Felker [Sun, 5 May 2019 15:15:23 +0000 (11:15 -0400)]
allow archs to provide a 7-argument syscall if needed
commit 788d5e24ca19c6291cebd8d1ad5b5ed6abf42665 noted that we could
add this if needed, and in fact it is needed, but not for one of the
archs documented as having a 7th syscall arg register. rather, it's
needed for mips (o32), where all but the first 4 arguments are passed
on the stack, and the stack can accommodate a 7th.
Rich Felker [Sun, 5 May 2019 14:52:41 +0000 (10:52 -0400)]
fix passing of 64-bit syscall arguments on microblaze
this has been wrong since the beginning of the microblaze port: the
syscall ABI for microblaze does not align 64-bit arguments on even
register boundaries. commit 788d5e24ca19c6291cebd8d1ad5b5ed6abf42665
exposed the problem by introducing references to a nonexistent
__syscall7. the ABI is not documented well anywhere, but I was able to
confirm against both strace source and glibc source that microblaze is
not using the alignment.
per the syscall(2) man page, posix_fadvise, ftruncate, pread, pwrite,
readahead, sync_file_range, and truncate were all affected and either
did not work at all, or only worked by chance, e.g. when the affected
argument slots were all zero.
make new math code compatible with unused variable warning/error
commit b50d315fd23f0fbc4c11e2583801dd123d933745 introduced
fp_force_eval implemented by default with a dead store to a volatile
variable. unfortunately introduces warnings with -Wunused-variable and
breaks the ability to use -Werror with the default warning options set
by configure when warnings are enabled.
we could just call fp_barrier instead, but that results in a spurious
load after the store due to volatile semantics.
the fix committed here avoids the load. it will still produce warnings
without -Wno-unused-but-set-variable, but that's part of our default
warning profile, and there are already other locations in the source
where an unused variable warning will occur without it.
Szabolcs Nagy [Sun, 2 Dec 2018 18:53:37 +0000 (18:53 +0000)]
math: add configuration macros
Musl currently aims to support non-nearest rounding mode and does not
support SNaNs. These macros allow marking relevant code paths in case
these decisions are changed later (they also help documenting the
corner cases involved).
Szabolcs Nagy [Sun, 22 Oct 2017 13:51:35 +0000 (13:51 +0000)]
math: add single precision error handling functions
These are supposed to be used in tail call positions when handling
special cases in new code. (fp exceptions may be raised "naturally"
by the common code path if special casing is more effort.)
This implements the error handling apis used in
https://github.com/ARM-software/optimized-routines
without errno setting.
Szabolcs Nagy [Sat, 1 Dec 2018 23:52:34 +0000 (23:52 +0000)]
math: add eval_as_float and eval_as_double
Previously type casts or assignments were used for handling excess
precision, which assumed standard C99 semantics, but since it's a
rarely needed obscure detail, it's better to use explicit helper
functions to document where we rely on this. It also helps if the
code is used outside of the libc in non-C99 compilation mode: with the
default excess precision handling of gcc, explicit inline asm barriers
are needed for narrowing on FLT_EVAL_METHOD!=0 targets.
I plan to use this in new code with the existing style that uses
double_t and float_t as much as possible.
One ugliness is that it is required for almost every return statement
since that does not drop excess precision (the standard changed this
in C11 annex F, but that does not help in non-standard compilation
modes or with old compilers).
Szabolcs Nagy [Mon, 26 Nov 2018 23:30:00 +0000 (23:30 +0000)]
math: add fp_arch.h with fp_barrier and fp_force_eval
C99 has ways to support fenv access, but compilers don't implement it
and assume nearest rounding mode and no fp status flag access. (gcc has
-frounding-math and then it does not assume nearest rounding mode, but
it still assumes the compiled code itself does not change the mode.
Even if the C99 mechanism was implemented it is not ideal: it requires
all code in the library to be compiled with FENV_ACCESS "on" to make it
usable in non-nearest rounding mode, but that limits optimizations more
than necessary.)
The math functions should give reasonable results in all rounding modes
(but the quality may be degraded in non-nearest rounding modes) and the
fp status flag settings should follow the spec, so fenv side-effects are
important and code transformations that break them should be prevented.
Unfortunately compilers don't give any help with this, the best we can
do is to add fp barriers to the code using volatile local variables
(they create a stack frame and undesirable memory accesses to it) or
inline asm (gcc specific, requires target specific fp reg constraints,
often creates unnecessary reg moves and multiple barriers are needed to
express that an operation has side-effects) or extern call (only useful
in tail-call position to avoid stack-frame creation and does not work
with lto).
We assume that in a math function if an operation depends on the input
and the output depends on it, then the operation will be evaluated at
runtime when the function is called, producing all the expected fenv
side-effects (this is not true in case of lto and in case the operation
is evaluated with excess precision that is not rounded away). So fp
barriers are needed (1) to prevent the move of an operation within a
function (in case it may be moved from an unevaluated code path into an
evaluated one or if it may be moved across a fenv access), (2) force the
evaluation of an operation for its side-effect when it has no input
dependency (may be constant folded) or (3) when its output is unused. I
belive that fp_barrier and fp_force_eval can take care of these and they
should not be needed in hot code paths.
Szabolcs Nagy [Thu, 29 Nov 2018 22:09:53 +0000 (22:09 +0000)]
math: move complex math out of libm.h
This makes it easier to build musl math code with a compiler that
does not support complex types (tcc) and in general more sensible
factorization of the internal headers.
Szabolcs Nagy [Tue, 16 Oct 2018 22:20:39 +0000 (22:20 +0000)]
define FP_FAST_FMA* when fma* can be inlined
FP_FAST_FMA can be defined if "the fma function generally executes about
as fast as, or faster than, a multiply and an add of double operands",
which can only be true if the fma call is inlined as an instruction.
gcc sets __FP_FAST_FMA if __builtin_fma is inlined as an instruction,
but that does not mean an fma call will be inlined (e.g. it is defined
with -fno-builtin-fma), other compilers (clang) don't even have such
macro, but this is the closest we can get.
(even if the libc fma implementation is a single instruction, the extern
call overhead is already too big when the macro is used to decide between
x*y+z and fma(x,y,z) so it cannot be based on libc only, defining the
macro unconditionally on targets which have fma in the base isa is also
incorrect: the compiler might not inline fma anyway.)
this solution works with gcc unless fma inlining is explicitly turned off.
A. Wilcox [Wed, 13 Mar 2019 16:16:11 +0000 (11:16 -0500)]
fcntl.h: define O_TTY_INIT to 0
POSIX: "[If] either O_TTY_INIT is set in oflag or O_TTY_INIT has the
value zero, open() shall set any non-standard termios structure
terminal parameters to a state that provides conforming behavior."
The Linux kernel tty drivers always perform initialisation on their
devices to set known good termios values during the open(2) call. This
means that setting O_TTY_INIT to zero is conforming.
remove external __syscall function and last remaining users
the weak version of __syscall_cp_c was using a tail call to __syscall
to avoid duplicating the 6-argument syscall code inline in small
static-linked programs, but now that __syscall no longer exists, the
inline expansion is no longer duplication.
the syscall.h machinery suppported up to 7 syscall arguments, only via
an external __syscall function, but we presently have no syscall call
points that actually make use of that many, and the kernel only
defines 7-argument calling conventions for arm, powerpc (32-bit), and
sh. if it turns out we need them in the future, they can easily be
added.
implement inline 5- and 6-argument syscalls for mipsn32 and mips64
n32 and n64 ABIs add new argument registers vs o32, so that passing on
the stack is not necessary, so it's not clear why the 5- and
6-argument versions were special-cased to begin with; it seems to have
been pattern-copying from arch/mips (o32).
i've treated the new argument registers like the first 4 in terms of
clobber status (non-clobbered). hopefully this is correct.
implement inline 5- and 6-argument syscalls for mips
the OABI passes these on the stack, using the convention that their
position on the stack is as if the first four arguments (in registers)
also had stack slots. originally this was deemed too awkward to do
inline, falling back to external __syscall, but it's not that bad and
now that external __syscall is being removed, it's necessary.
the inline syscall code is copied directly from powerpc64. the extent
of register clobber specifiers may be excessive on both; if that turns
out to be the case it can be fixed later.
remove cruft for supposedly-buggy clang from or1k & microblaze syscall_arch
it was never demonstrated to me that this workaround was needed, and
seems likely that, if there ever was any clang version for which it
was needed, it's old enough to be unusably buggy in other ways. if it
turns out some compilers actually can't do the register allocation
right, we'll need to replace this with inline shuffling code, since
the external __syscall dependency is being removed.
overhaul i386 syscall mechanism not to depend on external asm source
this is the first part of a series of patches intended to make
__syscall fully self-contained in the object file produced using
syscall.h, which will make it possible for crt1 code to perform
syscalls.
the (confusingly named) i386 __vsyscall mechanism, which this commit
removes, was introduced before the presence of a valid thread pointer
was mandatory; back then the thread pointer was setup lazily only if
threads were used. the intent was to be able to perform syscalls using
the kernel's fast entry point in the VDSO, which can use the sysenter
(Intel) or syscall (AMD) instruction instead of int $128, but without
inlining an access to the __syscall global at the point of each
syscall, which would incur a significant size cost from PIC setup
everywhere. the mechanism also shuffled registers/calling convention
around to avoid spills of call-saved registers, and to avoid
allocating ebx or ebp via asm constraints, since there are plenty of
broken-but-supported compiler versions which are incapable of
allocating ebx with -fPIC or ebp with -fno-omit-frame-pointer.
the new mechanism preserves the properties of avoiding spills and
avoiding allocation of ebx/ebp in constraints, but does it inline,
using some fairly simple register shuffling, and uses a field of the
thread structure rather than global data for the vdso-provided syscall
code address.
for now, the external __syscall function is refactored not to use the
old __vsyscall so it can be kept, but the intent is to remove it too.
in membarrier fallback, allow for possibility that sigaction fails
this is a workaround to avoid a crashing regression on qemu-user when
dynamic TLS is installed at dlopen time. the sigaction syscall should
not be able to fail, but it does fail for implementation-internal
signals under qemu user-level emulation if the host libc qemu is
running under reserves the same signals for implementation-internal
use, since qemu makes no provision to redirect/emulate them. after
sigaction fails, the subsequent tkill would terminate the process
abnormally as the default action.
no provision to account for membarrier failing is made in the dynamic
linker code that installs new TLS. at the formal level, the missing
barrier in this case is incorrect, and perhaps we should fail the
dlopen operation, but in practice all the archs we support (and
probably all real-world archs except alpha, which isn't yet supported)
should give the right behavior with no barrier at all as a consequence
of consume-order properties.
in the long term, this workaround should be supplemented or replaced
by something better -- a different fallback approach to ensuring
memory consistency, or dynamic allocation of implementation-internal
signals. the latter is appealing in that it would allow cancellation
to work under qemu-user too, and would even allow many levels of
nested emulation.
Bobby Bingham [Fri, 5 Apr 2019 17:26:17 +0000 (12:26 -0500)]
fix signature of function accepted by makecontext
This parameter was incorrectly declared to be a pointer to a function
accepting zero parameters. The intent of makecontext is that it is
possible to pass integer parameters to the function, so this should
have been a pointer to a function accepting an unspecified set of
parameters.
Frediano Ziglio [Tue, 26 Mar 2019 09:36:47 +0000 (09:36 +0000)]
use __strchrnul instead of strchr and strlen in execvpe
The result is the same but takes less code.
Note that __execvpe calls getenv which calls __strchrnul so even
using static output the size of the executable won't grow.
fix harmless-by-chance typo in priority inheritance mutex code
commit 54ca677983d47529bab8752315ac1a2b49888870 inadvertently
introduced bitwise and where logical and was intended. since the
right-hand operand is always 0 or -1 whenever the left-hand operand is
nonzero, the behavior happened to be equivalent.
Rich Felker [Sun, 31 Mar 2019 22:03:27 +0000 (18:03 -0400)]
implement priority inheritance mutexes
priority inheritance is a feature to mitigate priority inversion
situations, where a execution of a medium-priority thread can
unboundedly block forward progress of a high-priority thread when a
lock it needs is held by a low-priority thread.
the natural way to do priority inheritance would be with a simple
futex flag to donate the calling thread's priority to a target thread
while it waits on the futex. unfortunately, linux does not offer such
an interface, but instead insists on implementing the whole locking
protocol in kernelspace with special futex commands that exist solely
for the purpose of doing PI mutexes. this would require the entire
"trylock" logic to be duplicated in the timedlock code path for PI
mutexes, since, once the previous lock holder releases the lock and
the futex call returns, the lock is already held by the caller.
obviously such code duplication is undesirable.
instead, I've made the PI timedlock success path set the mutex lock
count to -1, which can be thought of as "not yet complete", since a
lock count of 0 is "locked, with no recursive references". a simple
branch in a non-hot path of pthread_mutex_trylock can then see and act
on this state, skipping past the code that would check and take the
lock to the same code path that runs after the lock is obtained for a
non-PI mutex.
because we're forced to let the kernel perform the actual lock and
unlock operations whenever the mutex is contended, we have to patch
things up when it does the wrong thing:
1. the lock operation is not aware of whether the mutex is
error-checking, so it will always fail with EDEADLK rather than
deadlocking.
2. the lock operation is not aware of whether the mutex is robust, so
it will successfully obtain mutexes in the owner-died state even if
they're non-robust, whereas this operation should deadlock.
3. the unlock operation always sets the lock value to zero, whereas
for robust mutexes, we want to set it to a special value indicating
that the mutex obtained after its owner died was unlocked without
marking it consistent, so that future operations all fail with
ENOTRECOVERABLE.
the first of these is easy to solve, just by performing a futex wait
on a dummy futex address to simulate deadlock or ETIMEDOUT as
appropriate. but problems 2 and 3 interact in a nasty way. to solve
problem 2, we need to back out the spurious success. but if waiters
are present -- which we can't just ignore, because even if we don't
want to wake them, the calling thread is incorrectly inheriting their
priorities -- this requires using the kernel's unlock operation, which
will zero the lock value, thereby losing the "owner died with lock
held" state.
to solve these problems, we overload the mutex's waiters field, which
is unused for PI mutexes since they don't call the normal futex wait
functions, as an indicator that the PI mutex is permanently
non-lockable. originally I wanted to use the count field, but there is
one code path that needs to access this flag without synchronization:
trylock's CAS failure path needs to be able to decide whether to fail
with EBUSY or ENOTRECOVERABLE, the waiters field is already treated as
a relaxed-order atomic in our memory model, so this works out nicely.
Rich Felker [Fri, 29 Mar 2019 19:49:14 +0000 (15:49 -0400)]
clean up access to mutex type in pthread_mutex_trylock
there was no point in masking off the pshared bit when first loading
the type, since every subsequent access involves a mask anyway. not
masking it may avoid a subsequent load to check the pshared flag, and
it's just simpler.
Rich Felker [Thu, 21 Mar 2019 17:58:12 +0000 (13:58 -0400)]
fix data race choosing next key slot in pthread_key_create
commit 84d061d5a31c9c773e29e1e2b1ffe8cb9557bc58 wrongly moved the
access to the global next_key outside of the scope of the lock. the
error manifested as spurious failure to find an available key slot
under concurrent calls to pthread_key_create, since the stopping
condition could be met after only a small number of slots were
examined.
Rich Felker [Fri, 15 Mar 2019 00:52:18 +0000 (20:52 -0400)]
fix crash/out-of-bound read in sscanf
commit d6c855caa88ddb1ab6e24e23a14b1e7baf4ba9c7 caused this
"regression", though the behavior was undefined before, overlooking
that f->shend=0 was being used as a sentinel for "EOF" status (actual
EOF or hitting the scanf field width) of the stream helper (shgetc)
functions.
obviously the shgetc macro could be adjusted to check for a null
pointer in addition to the != comparison, but it's the hot path, and
adding extra code/branches to it begins to defeat the purpose.
so instead of setting shend to a null pointer to block further reads,
which no longer works, set it to the current position (rpos). this
makes the shgetc macro work with no change, but it breaks shunget,
which can no longer look at the value of shend to determine whether to
back up. Szabolcs Nagy suggested a solution which I'm using here:
setting shlim to a negative value is inexpensive to test at shunget
time, and automatically re-trips the cnt>=shlim stop condition in
__shgetc no matter what the original limit was.
Rich Felker [Thu, 14 Mar 2019 03:23:26 +0000 (23:23 -0400)]
fix namespace violation in dependencies of mtx_lock
commit 2de29bc994029b903a366b8a4a9f8c3c3ee2be90 left behind one
reference to pthread_mutex_trylock. fixing this also improves code
generation due to the namespace-safe version being hidde.
Szabolcs Nagy [Thu, 7 Mar 2019 21:53:48 +0000 (21:53 +0000)]
sys/prctl.h: add PR_PAC_RESET_KEYS from linux v5.0
aarch64 pointer authentication code related prctl that allows
reinitializing the key for the thread, added in linux commit ba830885656414101b2f8ca88786524d4bb5e8c1
projects / musl / log