musl/src/linux, branch v1.2.5 musl - an implementation of the standard library for Linux-based systems riscv: fall back to syscall __riscv_flush_icache 2024-02-26T01:35:24+00:00 Stefan O'Rear sorear@fastmail.com 2020-09-03T09:23:40+00:00 2c887f24da36fa30eccd72e50d91222828fa526e Matches glibc behavior and fixes a case where we could fall off the function without returning a value. 
Matches glibc behavior and fixes a case where we could fall off the
function without returning a value.
add statx interface using syscall, fallback to fstatat 2024-02-24T17:27:09+00:00 Duncan Bellamy dunk@denkimushi.com 2022-08-31T19:07:34+00:00 b817541f1cfd38e4b81257b3215e276ea9d0fc61 






add framework to support archs without a native wait4 syscall
2024-02-22T23:50:34+00:00

Rich Felker
dalias@aerifal.cx

2024-02-22T23:50:34+00:00

19563e1850808af216b1b84263bb7e83cccce506

this commit should make no codegen change for existing archs, but is a
prerequisite for new archs including riscv32. the wait4 emulation
backend provides both cancellable and non-cancellable variants because
waitpid is required to be a cancellation point, but all of our other
uses are not, and most of them cannot be.

based on patch by Stefan O'Rear.





this commit should make no codegen change for existing archs, but is a
prerequisite for new archs including riscv32. the wait4 emulation
backend provides both cancellable and non-cancellable variants because
waitpid is required to be a cancellation point, but all of our other
uses are not, and most of them cannot be.

based on patch by Stefan O'Rear.







riscv: correct symbol version of __vdso_flush_icache
2024-02-04T00:49:42+00:00

gns
infiwang@proton.me

2024-01-25T15:59:52+00:00

bd3138b74a06dd764508f399d1b58cb9d6c35c1f

Previously, __riscv_flush_icache would not work correctly as
__vdso_flush_icache had a wrong symbol version. Fix this by correcting
symbol version.

Fixes: 0a48860c27a8 ("add riscv64 architecture support")





Previously, __riscv_flush_icache would not work correctly as
__vdso_flush_icache had a wrong symbol version. Fix this by correcting
symbol version.

Fixes: 0a48860c27a8 ("add riscv64 architecture support")







add preadv2 and pwritev2 syscall wrappers, flag value macros
2024-01-25T17:02:34+00:00

Rich Felker
dalias@aerifal.cx

2024-01-25T17:02:34+00:00

81cced6ebeb4419a78a8892ec7d7e28f5582d24a












move ppoll from src/linux to src/select reflecting future standardization
2024-01-21T22:18:36+00:00

Rich Felker
dalias@aerifal.cx

2024-01-21T22:18:36+00:00

07af01816d65b49a901cd784db69a030a6213e03

the ppoll function has been accepted as a future part of the standard
as the outcome of Austin Group tracker issue 1263. move the source
file to reflect this.





the ppoll function has been accepted as a future part of the standard
as the outcome of Austin Group tracker issue 1263. move the source
file to reflect this.







fix public clone function to be safe and usable by applications
2023-06-01T20:15:38+00:00

Rich Felker
dalias@aerifal.cx

2023-05-31T16:04:06+00:00

fa4a8abd06a401822cc8ba4e352a219544c0118d

the clone() function has been effectively unusable since it was added,
due to producing a child process with inconsistent state. in
particular, the child process's thread structure still contains the
tid, thread list pointers, thread count, and robust list for the
parent. this will cause malfunction in interfaces that attempt to use
the tid or thread list, some of which are specified to be
async-signal-safe.

this patch attempts to make clone() consistent in a _Fork-like sense.
as in _Fork, when the parent process is multi-threaded, the child
process inherits an async-signal context where it cannot call
AS-unsafe functions, but its context is now intended to be safe for
calling AS-safe functions. making clone fork-like would also be a
future option, if it turns out that this is what makes sense to
applications, but it's not done at this time because the changes would
be more invasive.

in the case where the CLONE_VM flag is used, clone is only vfork-like,
not _Fork-like. in particular, the child will see itself as having the
parent's tid, and cannot safely call any libc functions but one of the
exec family or _exit.

handling of flags and variadic arguments is also changed so that
arguments are only consumed with flags that indicate their presence,
and so that flags which produce an inconsistent state are disallowed
(reported as EINVAL). in particular, all libc functions carry a
contract that they are only callable with ABI requirements met, which
includes having a valid thread pointer to a thread structure that's
unique within the process, and whose contents are opaque and only able
to be setup internally by the implementation. the only way for an
application to use flags that violate these requirements without
executing any libc code is to perform the syscall from
application-provided asm.





the clone() function has been effectively unusable since it was added,
due to producing a child process with inconsistent state. in
particular, the child process's thread structure still contains the
tid, thread list pointers, thread count, and robust list for the
parent. this will cause malfunction in interfaces that attempt to use
the tid or thread list, some of which are specified to be
async-signal-safe.

this patch attempts to make clone() consistent in a _Fork-like sense.
as in _Fork, when the parent process is multi-threaded, the child
process inherits an async-signal context where it cannot call
AS-unsafe functions, but its context is now intended to be safe for
calling AS-safe functions. making clone fork-like would also be a
future option, if it turns out that this is what makes sense to
applications, but it's not done at this time because the changes would
be more invasive.

in the case where the CLONE_VM flag is used, clone is only vfork-like,
not _Fork-like. in particular, the child will see itself as having the
parent's tid, and cannot safely call any libc functions but one of the
exec family or _exit.

handling of flags and variadic arguments is also changed so that
arguments are only consumed with flags that indicate their presence,
and so that flags which produce an inconsistent state are disallowed
(reported as EINVAL). in particular, all libc functions carry a
contract that they are only callable with ABI requirements met, which
includes having a valid thread pointer to a thread structure that's
unique within the process, and whose contents are opaque and only able
to be setup internally by the implementation. the only way for an
application to use flags that violate these requirements without
executing any libc code is to perform the syscall from
application-provided asm.







wait4: fix missing rusage on x32 due to wrong success condition
2023-04-11T13:23:44+00:00

Alexey Izbyshev
izbyshev@ispras.ru

2023-03-06T08:59:21+00:00

c1b42c4a3a0324ec25877980f59db233fa420925

Resource usage data is filled by the kernel only when wait4 returns
a pid, i.e. a positive value.

Commit 5850546e9669f793aab61dfc7c4f2c1ff35c4b29 introduced this bug,
possibly because of copy-pasting from getrusage.





Resource usage data is filled by the kernel only when wait4 returns
a pid, i.e. a positive value.

Commit 5850546e9669f793aab61dfc7c4f2c1ff35c4b29 introduced this bug,
possibly because of copy-pasting from getrusage.







remove LFS64 symbol aliases; replace with dynamic linker remapping
2022-10-19T18:01:31+00:00

Rich Felker
dalias@aerifal.cx

2022-09-26T21:14:18+00:00

246f1c811448f37a44b41cd8df8d0ef9736d95f4

originally the namespace-infringing "large file support" interfaces
were included as part of glibc-ABI-compat, with the intent that they
not be used for linking, since our off_t is and always has been
unconditionally 64-bit and since we usually do not aim to support
nonstandard interfaces when there is an equivalent standard interface.

unfortunately, having the symbols present and available for linking
caused configure scripts to detect them and attempt to use them
without declarations, producing all the expected ill effects that
entails.

as a result, commit 2dd8d5e1b8ba1118ff1782e96545cb8a2318592c was made
to prevent this, using macros to redirect the LFS64 names to the
standard names, conditional on _GNU_SOURCE or _LARGEFILE64_SOURCE.
however, this has turned out to be a source of further problems,
especially since g++ defines _GNU_SOURCE by default. in particular,
the presence of these names as macros breaks a lot of valid code.

this commit removes all the LFS64 symbols and replaces them with a
mechanism in the dynamic linker symbol lookup failure path to retry
with the spurious "64" removed from the symbol name. in the future,
if/when the rest of glibc-ABI-compat is moved out of libc, this can be
removed.





originally the namespace-infringing "large file support" interfaces
were included as part of glibc-ABI-compat, with the intent that they
not be used for linking, since our off_t is and always has been
unconditionally 64-bit and since we usually do not aim to support
nonstandard interfaces when there is an equivalent standard interface.

unfortunately, having the symbols present and available for linking
caused configure scripts to detect them and attempt to use them
without declarations, producing all the expected ill effects that
entails.

as a result, commit 2dd8d5e1b8ba1118ff1782e96545cb8a2318592c was made
to prevent this, using macros to redirect the LFS64 names to the
standard names, conditional on _GNU_SOURCE or _LARGEFILE64_SOURCE.
however, this has turned out to be a source of further problems,
especially since g++ defines _GNU_SOURCE by default. in particular,
the presence of these names as macros breaks a lot of valid code.

this commit removes all the LFS64 symbols and replaces them with a
mechanism in the dynamic linker symbol lookup failure path to retry
with the spurious "64" removed from the symbol name. in the future,
if/when the rest of glibc-ABI-compat is moved out of libc, this can be
removed.







epoll_create: fail with EINVAL if size is non-positive
2022-08-25T00:35:47+00:00

Kristina Martsenko
kristina.martsenko@arm.com

2022-08-24T14:26:52+00:00

d4f987e4ac44e4e5ca2bcf68365b4c2b77bdf2d0

This is a part of the interface contract defined in the Linux man
page (official for a Linux-specific interface) and asserted by test
cases in the Linux Test Project (LTP).





This is a part of the interface contract defined in the Linux man
page (official for a Linux-specific interface) and asserted by test
cases in the Linux Test Project (LTP).