- Re-enabled ulkbits and lkbits for Risc-V
- Bumped `int_lk_t` to a `signed long long` and a `uint_ulk_t` to an
`unsigned long long` to guarantee they both fit in 8 bytes, which `long
_Accum` and `unsigned long _Accum` are defaulted to on 32bit
architectures.
This is probably inconvenient on systems that have a word size larger
than 64 bits?
#115778
We are finalizing the header inclusion policy, and for our public
headers in the `libc/include` folder, they must use relative path in
`"..."` when including each other.
This PR does the cleanup making sure that all the public header
inclusions in `libc/include` folder use relative paths.
---------
Co-authored-by: Nick Desaulniers <nickdesaulniers@users.noreply.github.com>
In glibc and musl, fexcept_t is unsigned short int on x86 and
unsigned int on other machines that llvm-libc supports. Match
that ABI (only different from before on x86) and API (different
everywhere as it was previously signed).
Summary:
This function can easily be implemented by forwarding it to the host
process. This shows up in a few places that we might want to test the
GPU so it should be provided. Also, I find the idea of the GPU
offloading work to the CPU via `system` very funny.
Fixes#106467.
Bind was accidentally removed while trying to clean up functions that
didn't end up being needed. The GCC issue was just a warning treated as
an error.
This patch adds the necessary functions to send and receive messages
over a socket. Those functions are: recv, recvfrom, recvmsg, send,
sendto, sendmsg, and socketpair for testing.
Summary:
This patch adds the macros and entrypoints associated with the
`locale.h` entrypoints. These are mostly stubs, as we (for now and the
forseeable future) only expect to support the C and maybe C.UTF-8
locales in the LLVM libc.
Summary:
This patch adds all the libc ctype variants. These ignore the locale
ingormation completely, so they're pretty much just stubs. Because these
use locale information, which is system scope, we do not enable building
them outisde of full build mode.
The 32-bit Arm builds of libc define time_t to be `__INTPTR_TYPE__`,
i.e. a 32-bit integer. This is commented in the commit introducing it
(75398f28eb) as being for compatibility with glibc. But in the near
future not even every AArch32 build of glibc will have a 32-bit time_t:
Debian is planning that their next release (trixie) will have switched
to 64-bit. And non-Linux builds of this libc (e.g. baremetal) have no
reason to need glibc compatibility in the first place – and every reason
_not_ to want to start using a 32-bit time_t in 2024 or later.
So I've replaced the `#ifdef` in `llvm-libc-types/time_t.h` with two
versions of the header file, chosen in `CMakeLists.txt` via a new
configuration option. This involved adding an extra parameter to the
cmake `add_header` function to specify different names for the header
file in the source and destination directories.
Summary:
This header is practically useless, but we provide it mostly for the
macros so that applications can compile. I'm only doing this for the
`libc++` unittests that want it, and it is part of the C standard
technically. I just made an RPC call to do `raise`. Anything more isn't
going to work since it'd be way too annoying to make the CPU call into
some signal handler the GPU registered.
Previously, building libc for AArch64 in `LLVM_LIBC_FULL_BUILD` mode
would fail because no implementation of setjmp/longjmp was available.
This was the only obstacle, so now a full AArch64 build of libc is
possible.
This implementation automatically supports PAC and BTI if compiled with
the appropriate options. I would have liked to do the same for MTE stack
tagging, but as far as I can see there's currently no predefined macro
that allows detection of `-fsanitize=memtag-stack`, so I've left that
one as a TODO.
AAPCS64 delegates the x18 register to individual platform ABIs, and
allows them to choose what it's used for, which may or may not require
setjmp and longjmp to save and restore it. To accommodate this, I've
introduced a libc configuration option. The default is on, because the
only use of x18 I've so far encountered uses it to store information
specific to the current stack frame (so longjmp does need to restore
it), and this is also safe behavior in the default situation where the
platform ABI specifies no use of x18 and it becomes a temporary register
(restoring it to its previous value is no worse than any _other_ way for
a function call to clobber it). But if a platform ABI needs to use x18
in a way that requires longjmp to leave it alone, they can turn the
option off.
In 32-bit systems with 64-bit offsets, both fsfilcnt_t and fsblkcnt_t are 64-bit long, just like 64-bit systems. This patch changes both types to be 64-bit long for all platforms and follows the reasoning used to change off_t: the standard only requires it to be an unsigned int, so making it 64-bit long doesn't violate this property.
It should be NFC for 64-bit systems.
Summary:
This patch implements the `printf` family of functions on the GPU using
the new variadic support. This patch adapts the old handling in the
`rpc_fprintf` placeholder, but adds an extra RPC call to get the size of
the buffer to copy. This prevents the GPU from needing to parse the
string. While it's theoretically possible for the pass to know the size
of the struct, it's prohibitively difficult to do while maintaining ABI
compatibility with NVIDIA's varargs.
Depends on https://github.com/llvm/llvm-project/pull/96015.
Summary:
Straightforward RPC implementation of the `remove` function for the GPU.
Copies over the string and calls `remove` on it, passing the result
back. This is required for building some `libc++` functionality.
Note: our baremetal arm configuration compiles this as
`--target=arm-none-eabi`, so this code is built in -marm mode. It could be
smaller with `--target=armv7-none-eabi -mthumb`. The assembler is valid ARMv5,
or THUMB2, but not THUMB(1).
New pull request for https://github.com/llvm/llvm-project/issues/89443
The previous PR was reverted after breaking fullbuild due to a missing
struct declaration, which I forgot to commit.
Reverts revert and adds the missing pthread_rwlockattr_getkind_np /
pthread_rwlockattr_setkind_np functions and tests respecitvely.
This PR implements a part of WG14 N2653:
- Define C23 char8_t
- Define C11 char16_t
- Define C11 char32_t
Missing goals are:
- The type of UTF-8 character literals is changed from unsigned char to
char8_t. (Since UTF-8 character literals already have type unsigned
char, this is not a semantic change).
- New mbrtoc8() and c8rtomb() functions declared in <uchar.h> enable
conversions between multibyte characters and UTF-8.
- A new ATOMIC_CHAR8_T_LOCK_FREE macro.
- A new atomic_char8_t typedef name.
The epoll_wait functions need the rest of the epoll functions (create,
ctl) to be available to actually test them, as well as pipe to create a
usable file descriptor. This patch adds epoll_create, epoll_create1,
epoll_ctl, and pipe. These have tests, and the tests for epoll_wait,
epoll_pwait, and epoll_pwait2 (currently disabled) are updated to use
these newly available functions.
Summary:
This patch adds a temporary implementation that uses a struct-based
interface in lieu of varargs support. Once varargs support exists we
will move this implementation to the "real" printf implementation.
Conceptually, this patch has the client copy over its format string and
arguments to the server. The server will then scan the format string
searching for any specifiers that are actually a string. If it is a
string then we will send the pointer back to the server to tell it to
copy it back. This copied value will then replace the pointer when the
final formatting is done.
This will require a built-in extension to the varargs support to get
access to the underlying struct. The varargs used on the GPU will simply
be a struct wrapped in a varargs ABI.
We expect to eventually provide a complete implementation, but having an
empty definition is necessary to unblock the use of libc++ in embedded
environments.
See #84884 for more details.
Towards the goal of getting `ninja libc-lint` back to green, fix the numerous
instances of:
warning: header guard does not follow preferred style [llvm-header-guard]
This is because many of our header guards start with `__LLVM` rather than
`LLVM`.
To filter just these warnings:
$ ninja -k2000 libc-lint 2>&1 | grep llvm-header-guard
To automatically apply fixits:
$ find libc/src libc/include libc/test -name \*.h | \
xargs -n1 -I {} clang-tidy {} -p build/compile_commands.json \
-checks='-*,llvm-header-guard' --fix --quiet
Some manual cleanup is still necessary as headers that were missing header
guards outright will have them inserted before the license block (we prefer
them after).
Summary:
Recent changes added an include path in the float128 type that used the
internal `libc` path to find the macro. This doesn't work once it's
installed because we need to search from the root of the install dir.
This patch adds "include/" to the include path so that our inclusion
of installed headers always match the internal use.
The epoll_wait functions are syscall wrappers that were requested by
upstream users. This patch adds them, as well as their header and types.
The tests are currently incomplete since they require epoll_create to
properly test epoll_wait. That will be added in a followup patch since
this one is already very large.
The epoll_wait functions are syscall wrappers that were requested by
upstream users. This patch adds them, as well as their header and types.
The tests are currently incomplete since they require epoll_create to
properly test epoll_wait. That will be added in a followup patch since
this one is already very large.
These were fixed properly by f1f1875c18.
- Revert "[libc] temporarily set -Wno-shorten-64-to-32 (#77396)"
- Revert "[libc] make off_t 32b for 32b arm (#77350)"
