Linux kernel commit ee988c11acf6f9464b7b44e9a091bf6afb3b3a49 added two
new HWCAP bits: one for ARCH_3_1, which is the Power10 ISA revision, and
one for MMA, which is the optional Matrix Multiply Assist extension.
When buffering on a FILE is disabled we still send both iovecs, even
though the first one is always empty. Clean things up by skipping the
empty iovec instead.
POSIX 2024 added a requirement that mbsnrtowcs, like mbrtowc, consume
any final partial character and store it in the mbstate_t object
before returning. this was previously unspecified but documented as a
potential future change.
an internal mbstate_t object is added for the case where the argument
is a null pointer. previously this was not needed since no operations
could modify the internal object and not processing it at all gave the
same behavior "as if" there were an internal object.
some recent compilers have adopted a dubious interpretation of the C
specification for union initializers, that when the initialized member
is smaller than the size of the union, the remaining padding does not
have to be zero-initialized. in the interests of not depending on any
particular interpretation, place the larger member first so it's
initialized and ensures the whole object is zero-filled.
traditionally, our cfsetispeed just set the output speed. this was not
conforming or reasonable behavior.
use of the input baud bits in termios c_cflag depends on kernel
support, which was added to linux along with TCSETS2 ioctl and
arbitrary-baud functionality sometime in the 2.6 series. with older
kernels, the separate input baud will not take, but this is the best
behavior we can hope for anyway, certainly better than wrongly
clobbering output baud setting.
the nonstandard cfsetspeed is now moved to a separate file, since it
no longer admits the weak alias implementation that made it
namespace-safe. it now sets the output speed, and on success, sets the
input speed to 0 (matched to output).
This just mirrors what is done in the start code for the affected
ports, as well as what is already done for the three x86 ports.
Clearing the frame pointer helps protect FP-based unwinders from
wrongly attempting to traverse into the parent thread's call frame
stack.
this function is documented as returning a null pointer on failure and
the current textdomain encoding, which is always UTF-8 in our
implementation, on success. there was some confusion over whether it's
expected to also return a null pointer in the case where it's using
the locale's encoding by default, rather than an explicitly bound one,
but it does not seem like that behavior would match applications'
expectations, and it would require gratuitously storing a meaningless
1-bit state for the textdomain.
the UTF-8 output code was written assuming an invariant that iconv's
decoders only emit valid Unicode Scalar Values which wctomb can encode
successfully, thereby always returning a value between 1 and 4.
if this invariant is not satisfied, wctomb returns (size_t)-1, and the
subsequent adjustments to the output buffer pointer and remaining
output byte count overflow, moving the output position backwards,
potentially past the beginning of the buffer, without storing any
bytes.
the man page for this nonstandardized function has historically
documented it as scanning for a substring; however, this is
functionally incorrect (matches the substring "atime" in the "noatime"
option, for example) and differs from other existing implementations.
with the change made here, it should match glibc and other
implementations, only matching whole options delimited by commas or
separated from a value by an equals sign.
as a result of incorrect bounds checking on the lead byte being
decoded, certain invalid inputs which should produce an encoding
error, such as "\xc8\x41", instead produced out-of-bounds loads from
the ksc table.
in a worst case, the loaded value may not be a valid unicode scalar
value, in which case, if the output encoding was UTF-8, wctomb would
return (size_t)-1, causing an overflow in the output pointer and
remaining buffer size which could clobber memory outside of the output
buffer.
bug report was submitted in private by Nick Wellnhofer on account of
potential security implications.
out-of-range second bytes were not handled, leading to wrong character
output rather than a reported encoding error.
fix based on bug report by Nick Wellnhofer, submitted in private in
case the issue turned out to have security implications.
Calling __tls_get_addr with brasl is not valid since it's a global symbol; doing
so results in an R_390_PC32DBL relocation error from lld. We could fix this by
marking __tls_get_addr hidden since it is not part of the s390x ABI, or by using
a different instruction. However, given its simplicity, it makes more sense to
just manually inline it into __tls_get_offset for performance.
The patch has been tested by applying to Zig's bundled musl copy and running the
full Zig test suite under qemu-s390x.
Some weird linkers may emit PT_LOAD segments with memsz = 0. ELF
specification does not forbid this, but such a segment with non-zero
p_vaddr will result in reclaiming of invalid memory address.
This patch skips such segments during reclaiming for better
compatibility.
we have the cpuset macros call calloc/free/memset/memcmp directly so
that they don't depend on any further ABI surface. this is not
namespace-clean, but only affects the _GNU_SOURCE feature profile,
which is not intended to be namespace-clean. nonetheless, reports come
up now and then of things which are gratuitously broken, usually when
an application has wrapped malloc with macros.
this patch parenthesizes the function names so that function-like
macros will not be expanded, and removes the unused declaration of
memcpy. this is not a complete solution, but it should improve things
for affected applications, particularly ones which are not even trying
to use the cpuset interfaces which got them just because g++ always
defines _GNU_SOURCE.
the kernel mq_attr structure has 8 64-bit longs instead of 8 32-bit
longs.
it's not clear that this is the nicest way to implement the fix, but
the concept (translation) is right, and the details can be changed
later if desired.
previously, we left any changes made by the application to the timer
thread's signal mask active when resetting the thread state for reuse.
not only did this violate the intended invariant that timer threads
start with all signals blocked; it also allowed application code to
execute in a thread that, formally, did not exist. and further, if the
internal SIGTIMER signal became unblocked, it could also lead to
missed timer expiration events.
commit 6ae2568bc2 introduced a fatal
signal condition if the internal timer signal used for SIGEV_THREAD
timers is unblocked. this can happen whenever the application alters
the signal mask with SIG_SETMASK, since sigset_t objects never include
the bits used for implementation-internal signals.
this patch effectively reverts the breakage by adding back a no-op
signal handler.
overruns will not be accounted if the timer signal becomes unblocked,
but POSIX does not specify them except for SIGEV_SIGNAL timers anyway.
The LLVM assembler reportedly assembles the form using the j mnemonic
incorrectly (see issue 107460). The jr form is canonical and avoids
this problem, so use it instead.
When the pattern was changed from matching any whitespace to just
matching spaces and tabs, a newline started being appended to the
value of the matched field, if that field was a string. For example,
in a 4-field line, the mnt_opts field would have a newline on the end.
This happened because a newline is not a space or a tab, and so was
matched as part of the value before the end of the string was reached.
\n should therefore be added as a character that terminates a value.
This shouldn't interfere with the intention of the change to space and
tab only, as it was trying to make sure that other whitespace like
carriage returns, that should have been part of parsed values, were.
Fixes: f314e133
The instruction encoding that would be "br %r0" is not actually a
branch to r0, but instead a nop/memory-barrier. gcc 14 has been found
to choose r0 for the "r"(pc) constraint, breaking CRTJMP.
This patch adjusts the inline assembly constraints and marks "pc" as
address ("a"), which disallows usage of r0.
commit 8cca79a72c added use of SYS_pause
to exit() without accounting for newer archs omitting the syscall.
use the newly-added __sys_pause abstraction instead, which uses
SYS_ppoll when SYS_pause is missing.
newer archs lack the syscall. the pause() function accounted for this
with its own #ifdef, but that didn't allow use of the syscall directly
elsewhere, so move the logic to macros in src/internal/syscall.h where
it can be shared.
commit b817541f1c introduced statx with
a fallback using fstatat, but failed to fill in stx_rdev_major/minor
and stx_attributes[_mask]. the rdev omission has been addressed
separately. rather than explicitly zeroing the attributes and their
mask, pre-fill the entire structure with zeros. this will also cover
the padding adjacent to stx_mode, in case it's ever used in the
future.
explicit zeroing of stx_btime is removed since, with this change, it
will already be pre-zeroed. as an aside, zeroing it was not strictly
necessary, since STATX_BASIC_STATS does not include STATX_BTIME and
thus does not indicate any validity for it.
The current implementation of the statx function fails to set the
values of stx->stx_rdev_major and stx->stx_rdev_minor if the statx
syscall fails with ENOSYS and thus the statx function has to fall back
on fstatat-based emulation.
the value placed in the aux vector AT_MINSIGSTKSZ by the kernel is
purely the signal frame size, and does not include any execution space
for the signal handler. this is contrary to the POSIX definition of
MINSIGSTKSZ to be a value that can actually execute at least some
minimal signal handler, and contrary to the historical definitions of
MINSIGSTKSZ which had at least 1k of headroom.
commit 996b6154b2 added support for
querying the dynamic limit but did not enforce it in sigaltstack. the
kernel also does not seem to reliably enforce it, or at least does not
necessarily enforce the same limit exposed to userspace, so it needs
to be enforced here.
internally, printf always works with the maximal-size supported
integer and floating point formats. however, the space needed to
format a floating point number is proportional to the mantissa and
exponent ranges. on archs where long double is larger than double,
knowing that the actual value fit in double allows us to use a much
smaller buffer, roughly 1/16 the size.
as a bonus, making the working buffer a VLA whose dimension depends on
the format specifier prevents the compiler from lifting the stack
adjustment to the top of printf_core. this makes it so printf calls
without floating point arguments do not waste even the smaller amount
of stack space needed for double, making it much more practical to use
printf in tightly stack-constrained environments.
linux puts hung-up ttys in a state where ioctls produce EIO, and may
do the same for other types of devices in error or shutdown states.
such an error clearly does not mean the device is not a tty, but it
also can't reliably establish that the device is a tty, so the only
safe thing to do seems to be reporting the error. programs that don't
check errno will conclude that the device is not a tty, which is no
different from what happens now, but at least they gain the option to
differentiate between the cases.
commit c84971995b introduced the errno
collapsing behavior, but prior to that, errno was not set at all by
isatty.
this is purely a readability change, not a functional one. all of the
integer format cases use a common tail for handling precision logic
after the string representation of the number has been generated. the
code as I originally wrote it was overly clever in the aim of making a
point that the flow could be done without goto, and jumped over
intervening cases by wrapping them in if (0) { }, with the case labels
for each inside the conditional block scope.
this has been a perpetual source of complaints about the readability
and comprehensibility of the file, so I am now changing it to
explicitly jump to the tail logic with goto statements.
this is the same as cp850, but with the euro symbol replacing the
lowercase dotless i at 0xd5. it is significant because it's used by
thermal receipt printers.
the comment does not match the required or actual behavior when x<0
and y is not an integer. while it could be corrected, the role of
comments here is to tell about characteristics unique to the
implementation, not to restate the requirements of the standard, so
just removing it seems best.
while not the only error codes presently omitted, these two are
particularly likely to be encountered in the wild.
EUCLEAN is used by linux filesystem and device drivers to report
filesystem structure corruption or data corruption.
ENAVAIL is used by some linux drivers to indicate non-availability of
a resource.
both names are new inventions to correspond to how they are actually
used, as the original kernel strings ("Structure needs cleaning" and
"No XENIX semaphores available") are not remotely meaningful or
reasonable.
the file-level crt_arch.h asm fragments generally make direct
(non-PLT) calls from _start to _start_c, which is only valid when
there is a local, non-interposable definition for _start_c. generally,
the linker is expected to know that local definitions in a main
executable (as opposed to shared library) output are non-interposable,
making this work, but historically there have been linker bugs in this
area, and microblaze is reportedly still broken, flagging the
relocation for the call as a textrel.
the equivalent _dlstart_c, called from the same crt_arch.h asm
fragments, has always used hidden visibility without problem, and
semantically it should be hidden, so make it hidden. this ensures the
direct call is always valid regardless of whether the linker properly
special-cases main executable output.
if sem_post is interrupted between clearing the waiters bit from the
semaphore value and performing the futex wait operation, subsequent
calls to sem_post will not perform a wake operation unless a new
waiter has arrived.
usually, this is at most a minor nuisance, since the original wake
operation will eventually happen. however, it's possible that the wake
is delayed indefinitely if interrupted by a signal handler, or that
the address the wake needs to be performed on is no longer mapped if
the semaphore was a process-shared one that has since been unmapped
but has a waiter on a different mapping of the same semaphore. this
can happen when another thread using the same mapping "steals the
post" atomically before actually becoming a second waiter, deduces
from success that it was the last user of the semaphore mapping, then
re-posts and unmaps the semaphore mapping. this scenario was described
in a report by Markus Wichmann.
instead of checking only the waiters bit, also check the waiter count
that was sampled before the atomic post operation, and perform the
wake if it's nonzero. this will not produce any additional wakes under
non-race conditions, since the waiters bit only becomes zero when
targeting a single waiter for wake. checking both was already the
behavior prior to commit 159d1f6c02.
J. Neuschäfer
A. Wilcox
Casey Connolly
Rich Felker
Alex Rønne Petersen
Lihua Zhao
Xing Li
Yao Zi
Alyssa Ross
Khem Raj
Stefan Liebler
Gabriel Ravier