Summary:
Currently, the RPC interface uses a basic opcode to communicate with the
server. This currently is 16 bits. There's no reason for this to be 16
bits, because on the GPU a 32-bit write is the same as a 16-bit write
performance wise.
Additionally, I am now making all the `libc` based opcodes qualified
with the 'c' type, mimiciing how Linux handles `ioctls` all coming from
the same driver. This will make it easier to extend the interface when
it's exported directly.
- 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
The C99 restrict keyword is spelled __restrict in the libc
headers so it can be parsed by C++ compilers with GNU extensions
that recognize it. When GNU extensions are not available in C++
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>
Previously shm_test was including <asm-generic/fcntl.h> for the macro
FD_CLOEXEC. This patch adds that macro to the list we have defined, and
redirects the test to use the correct proxy header.
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).
Refer: 7.3.1 from [ISO
SPEC](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf)
I have added complex variants of F16 and F128 in libc doc but have
omitted support for them since we will have to first investigate how
their support matrix for clang and gcc looks like, and then add header
guards for them accordingly. Planning to add them in follow up PRs once
this gets landed.
This patch adds the malloc.h header, declaring Scudo's mallopt
entrypoint when built LLVM_LIBC_INCLUDE_SCUDO, as well as two
constants that can be passed to it (M_PURGE and M_PURGE_ALL).
Due to limitations of the current build system, only the declaration
of mallopt is gated by LLVM_LIBC_INCLUDE_SCUDO, and the two new
constants are defined irrespectively of it. We may need to refine
this in the future.
Note that some allocators other than Scudo may offer a mallopt
implementation too (e.g. man 3 mallopt), albeit with different
supported input values. This patch only supports the specific case of
LLVM_LIBC_INCLUDE_SCUDO.
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.
This PR first adds osutils for Windows, and changes some libc code to
make libc and its tests build on the Windows target. It then temporarily
disables some libc tests that are currently problematic on Windows.
Specifically, the changes besides the addition of osutils include:
- Macro `LIBC_TYPES_HAS_FLOAT16` is disabled on Windows. `clang-cl`
generates calls to functions in `compiler-rt` to handle float16
arithmetic and these functions are currently not linked in on Windows.
- Macro `LIBC_TYPES_HAS_INT128` is disabled on Windows.
- The invocation to `::aligned_malloc` is changed to an invocation to
`::_aligned_malloc`.
- The following unit tests are temporarily disabled because they
currently fail on Windows:
- `test.src.__support.big_int_test`
- `test.src.__support.arg_list_test`
- `test.src.fenv.getenv_and_setenv_test`
- Tests involving `__m128i`, `__m256i`, and `__m512i` in
`test.src.string.memory_utils.op_tests.cpp`
- `test_range_errors` in `libc/test/src/math/smoke/AddTest.h` and
`libc/test/src/math/smoke/SubTest.h`
Summary:
This adds the locale variants of the string functions. As previously,
these do not use the locale information at all and simply copy the
non-locale version which expects the "C" locale.
Summary:
This provides the `_l` variants for the `stdlib.h` functions. These are
just copies of the same entrypoint and don't do anything with the locale
information.
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.
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.
Some new headers were not being properly built with
new headergen, since they were using the old "add_gen_header" instead of
the new "add_header_macro". This patch fixes the issue.
Old Headergen needed extra build rules to ensure that it worked in
runtimes mode. This patch disables those checks if new headergen is
enabled. Also some new headers were not being properly built with
new headergen, and that's also fixed.
Summary:
The standard says the following: The <time.h> header shall define the
clock_t, size_t, time_t, types as described in <sys/types.h>. I couldn't
find one for `uchar.h` but it needs it once we define things like
`mbrtoc8`.
Summary:
If the implementation supports floating-point infinities, the macro
INFINITY expands to constant expression of type float which evaluates to
positive or unsigned infinity.
Currently this is a double, this makes it a float.
This is based on @izaakschroeder previous patch but I only select macro
definitions for now. We need these definitions for VDSO work, which has
been delayed for a very long time.
Co-authored-by: Izaak Schroeder <izaak.schroeder@gmail.com>
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 is supposed to define the maximum bytes required to store a char in
any locale. There's some question about what this should be set to. I
believe because the proposed solution for `locale.h` is to only support
the default locale, we should do what `musl` does and set it to `4`
which covers up to UTF-32.
Fixes https://github.com/llvm/llvm-project/issues/79358
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.
