# Motivation
Futex syscalls are widely used in our codebase as synchronization
mechanism. Hence, it may be worthy to abstract out the most common
routines (wait and wake). On the other hand, C++20 also provides
`std::atomic_notify_one/std::atomic_wait/std::atomic_notify_all` which
align with such functionalities. This PR introduces `Futex` as a subtype
of `cpp::Atomic<FutexWordType>` with additional
`notify_one/notify_all/wait` operations.
Providing such wrappers also make future porting easier. For example,
FreeBSD's `_umtx_op` and Darwin's `ulock` can be wrapped in a similar
manner.
### Similar Examples
1. [bionic
futex](https://android.googlesource.com/platform/bionic/+/refs/heads/main/libc/bionic/bionic_futex.cpp)
2. [futex in Rust's
std](8cef37dbb6/library/std/src/sys/pal/unix/futex.rs (L21))
This patch enables the compilation of libc for rv32 by unifying the
current rv64 and rv32 implementation into a single rv implementation.
We updated the cmake file to match the new riscv32 arch and force
LIBC_TARGET_ARCHITECTURE to be "riscv" whenever we find "riscv32" or
"riscv64". This is required as LIBC_TARGET_ARCHITECTURE is used in the
path for several platform specific implementations.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D148797
This patch is an alternative to D155902. It provides the following benefits:
- No buffer manual allocation and error handling for the general case
- More flexible API : width specifier, sign and prefix handling
- Simpler code
The more flexible API removes the need for manually tweaking the buffer afterwards, and so prevents relying on implementation details of IntegerToString.
Reviewed By: michaelrj, jhuber6
Differential Revision: https://reviews.llvm.org/D156981
This patch is an alternative to D155902. It provides the following benefits:
- No buffer manual allocation and error handling for the general case
- More flexible API : width specifier, sign and prefix handling
- Simpler code
The more flexible API removes the need for manually tweaking the buffer afterwards, and so prevents relying on implementation details of IntegerToString.
Reviewed By: michaelrj, jhuber6
Differential Revision: https://reviews.llvm.org/D156981
This patch is large, but is almost entirely just adding casts to calls
to syscall_impl. Much of the work was done programatically, with human
checking when the syntax or types got confusing.
Reviewed By: mcgrathr
Differential Revision: https://reviews.llvm.org/D156950
This patch adds a bunch of ifdefs to handle the 32 bit versions of
some syscalls, which often only append a 64 to the name of the syscall
(with exception of SYS_lseek -> SYS_llseek and SYS_futex ->
SYS_futex_time64)
This patch also tries to handle cases where wait4 is not available
(as in riscv32): to implement wait, wait4 and waitpid when wait4 is
not available, we check for alternative wait calls and ultimately rely
on waitid to implement them all.
In riscv32, only waitid is available, so we need it to support this
platform.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D148371
Fix a bunch more instances of incorrect use of the `static`
keyword and missing use of LIBC_INLINE and LIBC_INLINE_VAR
macros. Note that even forward declarations and generic template
declarations must follow the prescribed patterns for libc code so
that they match every definition, all template specializations.
Reviewed By: Caslyn
Differential Revision: https://reviews.llvm.org/D154260
1) Avoid proper function calls and referencing local variables after
the stack has been deallocated. A proper function call/return or local
variable reference that may have spilled will cause invalid memory
reads after the stack has been deallocated.
2) Mark the function as [[noreturn]] and place
`__builtin_unreachable()` after the `SYS_exit` syscalls.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D151142
Only functional for stack growsdown (same as before), but custom
`stack`, `stacksize`, `guardsize`, and `detachstate` all should be
working.
Differential Revision: https://reviews.llvm.org/D148290
This patch standardizes the error messages when a syscall is not
available to be in the format: "ABC and DEF syscalls are not available."
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D148373
Also, added riscv64 startup code for static linking which is used
by the integration tests. Functions from the C standard threads
library have been enabled.
Reviewed By: mikhail.ramalho
Differential Revision: https://reviews.llvm.org/D145670
The libc uses some functions that GCC does not currently
implement, that come from Arm's ACLE header usually.
These are:
```
__arm_wsr64
__arm_rsr64
__arm_wsr
__arm_rsr
```
This issue was reported to us (https://github.com/llvm/llvm-project/issues/60473)
and I've then reported that back to GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642).
Even if these functions are added, clang has some non standard extensions
to them that gcc may not take. So we're looking at a fix in gcc 13 at best,
and that may not be enough for what we're doing with them.
So I've added ifdefs to use alternatives with gcc.
For handling the stack pointer, inline assembly is unfortunately the only option.
I have verified that the single mov is essentially what __arm_rsr64 generates.
For fpsr and fpcr the gcc devs suggested using
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/AArch64-Built-in-Functions.html#AArch64-Built-in-Functions.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D143261
This is first of a few patches which will do similar mechanical changes.
LIBC_INLINE is a simple macro which is default defined as just `inline`.
The idea is that, different downstream contexts can define the macro as
suitable to their use case and context. For example, one can choose to
define LIBC_INLINE as `[[clang::internal_linkage]] inline`.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D142154
Add the syscall wrapper function and tests. It's implemented using a
macro to guarantee the minimum number of arguments.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D134919
A detached thread cleans itself up at completion. So, the CLEAR_TID memory is
also gone by the time the kernel tries to signal potential waiters. By nulling
the CLEAR_TID address, we prevent the kernel from signalling at a non-existent
futex location.
Previosly, a pointer to the thread data structure was stored in the
start args. However, the thread data structure need not have the
lifetime of the thread. On the the other hand, thread attributes are
stored on the thread stack so they live as long as the thread lives.
It was previously a header library. Making it an object library will
allow us to declare thread local variables which can used to setup a
thread's self object.
