| Age | Commit message (Collapse) | Author |
|---|
|
Addresses `TODO`s in file.cpp by replacing data copies via for loops
with calls to inline_memcpy.
Signed-off-by: Shreeyash Pandey <shreeyash335@gmail.com>
|
|
Currently, the return value `LIBC_NAMESPACE::syscall_impl<int>(SYS_lseek, fd, offset, whence)` will
overflow when seeking on files >4GB.
|
|
Reverts llvm/llvm-project#152748
|
|
This is a follow up to the RFC here:
https://discourse.llvm.org/t/rfc-implementation-of-stdio-on-baremetal/86944
This provides the stdout/stderr/stdin symbols (which now don't have to
provided by the user). This allows the user to have access to all
functions, currently I've only tested `fprintf` but in theory everything
that works in the generic folder should work in the baremetal
configuration.
All streams are _non-buffered_, which does NOT require flushing. It is
based on the CookieFile that already existed
|
|
Fix using wrong variable due to copy/paste error.
---------
Co-authored-by: codefaber <codefaber>
|
|
<stdint.h> includes. (#150303)
https://github.com/llvm/llvm-project/issues/149993
|
|
The previous internal fcntl implementation modified errno directly, this
patch fixes that. This patch also moves open and close into OSUtil since
they are used in multiple places. There are more places that need
similar cleanup but only got comments in this patch to keep it
relatively reviewable.
Related to: https://github.com/llvm/llvm-project/issues/143937
|
|
LIBC_ERRNO_MODE_SYSTEM to be header-only. (#143187)
This is the first step in preparation for:
https://discourse.llvm.org/t/rfc-make-clang-builtin-math-functions-constexpr-with-llvm-libc-to-support-c-23-constexpr-math-functions/86450
|
|
Support _IONBF buffering for read_unlocked. Add the functions
read_unlocked_nbf() and read_unlocked_fbf().
Fixes: #120155
|
|
header `#include <stdlib.h> (#114690)
This finishes the work from
https://github.com/llvm/llvm-project/pull/114453 by adding proxy headers
for `malloc`, `realloc`, `free` and `aligned_alloc`.
|
|
|
|
|
|
https://github.com/llvm/llvm-project/issues/60481
|
|
This patch enables most of the libc entrypoints for riscv, except for fstatvfs, statvfs, dmull and fmull which are currently failing compilation. float16 is also not added, as rv32 doesn't seem to support it yet.
This patch also fixes the call to seek, which should take an off_t, and was missed in PR #68269.
|
|
This is a part of #97655.
|
|
declaration" (#98593)
Reverts llvm/llvm-project#98075
bots are broken
|
|
This is a part of #97655.
|
|
reland of https://github.com/llvm/llvm-project/pull/98215
Additionally adds proxy headers for FILE and the fopencookie types
The arm32 build has been failing due to redefinitions of the off_t type.
This patch fixes this by moving off_t to a proper proxy header. To do
this, it also moves stdio macros to a proxy header to hopefully avoid
including this proxy header alongside this public stdio.h.
|
|
Reverts llvm/llvm-project#98215
Breaks linux bots
|
|
The arm32 build has been failing due to redefinitions of the off_t type.
This patch fixes this by moving off_t to a proper proxy header. To do
this, it also moves stdio macros to a proxy header to hopefully avoid
including this proxy header alongside this public stdio.h.
|
|
Summary:
Including stdio here caused some multiple definitions on overlay mode.
Just include `off_t` directly.
Is this correct for 32-bit targets? Will investigate further after
fixing bots.
|
|
Summary:
The `stdio.h` header should define `off_t` as defined for the platform.
This will use the system's in overlay mode, or what the llvm-libc-types
deems correct. If this `off_t` is incorrect it should be changed in
`llvm-libc-types`. This fixes the GPU build.
|
|
This patch includes changes related to the use of off_t in libc,
targeted at 32-bit systems: in several places, the offset is used either
as a long or an off_t (64-bit signed int), but in 32-bit systems a long
type is only 32 bits long.
Fix a warning in mmap where a long offset is expected, but we were
passing an off_t. A static_cast and a comment were added to explain
that we know we are ignoring the upper 32-bit of the off_t in 32-bit
systems.
The code in pread and pwrite was slightly improved to remove a
#ifdef LIBC_TARGET_ARCH_IS_RISCV32; we are using an if constexpr now.
The Linux file operations were changed to use off_t instead of a long
where applicable. No changes were made to the standard API, e.g.,
ftell returns the offset as an int so we added a static_cast and a
comment explaining that this will cause a loss of integer precision
in 32-bit systems.
|
|
This PR fix several build errors on aarch64 targets when building with
gcc:
- uninitialized values leading to `Werrors`
- undefined builtin functions
- glibc header pollution
|
|
Fixes #93711 .
This patch implements the ``fdopen`` function. Given that ``fdopen``
internally calls ``fcntl``, the implementation of ``fcntl`` has been
moved to the ``__support/OSUtil``, where it serves as an internal public
function.
|
|
|
|
This PR address issue #89002.
#### Changes in this PR
* Added a simple implementation of `cpp::lock_guard` (an equivalent of
`std::lock_guard`) in libc/src/__support/CPP inspired by the libstdc++
implementation
* Added tests for `cpp::lock_guard` in
/libc/test/src/__support/CPP/mutex_test.cpp
* Replaced all references to `MutexLock` with `cpp::lock_guard`
---------
Co-authored-by: Guillaume Chatelet <gchatelet@google.com>
|
|
|
|
Summary:
This is a massive patch because it reworks the entire build and
everything that depends on it. This is not split up because various bots
would fail otherwise. I will attempt to describe the necessary changes
here.
This patch completely reworks how the GPU build is built and targeted.
Previously, we used a standard runtimes build and handled both NVPTX and
AMDGPU in a single build via multi-targeting. This added a lot of
divergence in the build system and prevented us from doing various
things like building for the CPU / GPU at the same time, or exporting
the startup libraries or running tests without a full rebuild.
The new appraoch is to handle the GPU builds as strict cross-compiling
runtimes. The first step required
https://github.com/llvm/llvm-project/pull/81557 to allow the `LIBC`
target to build for the GPU without touching the other targets. This
means that the GPU uses all the same handling as the other builds in
`libc`.
The new expected way to build the GPU libc is with
`LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`.
The second step was reworking how we generated the embedded GPU library
by moving it into the library install step. Where we previously had one
`libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This
patch includes the necessary clang / OpenMP changes to make that not
break the bots when this lands.
We unfortunately still require that the NVPTX target has an `internal`
target for tests. This is because the NVPTX target needs to do LTO for
the provided version (The offloading toolchain can handle it) but cannot
use it for the native toolchain which is used for making tests.
This approach is vastly superior in every way, allowing us to treat the
GPU as a standard cross-compiling target. We can now install the GPU
utilities to do things like use the offload tests and other fun things.
Some certain utilities need to be built with
`--target=${LLVM_HOST_TRIPLE}` as well. I think this is a fine
workaround as we
will always assume that the GPU `libc` is a cross-build with a
functioning host.
Depends on https://github.com/llvm/llvm-project/pull/81557
|
|
When building with compiler-rt enabled, warnings such as the following
are
observed:
llvm-project/llvm/build/projects/compiler-rt/../libc/include/llvm-libc-macros/linux/sys-stat-macros.h:46:9:
warning: 'S_IXOTH' macro redefined [-Wmacro-redefined]
#define S_IXOTH 00001
^
llvm-project/llvm/build/projects/compiler-rt/../libc/include/llvm-libc-macros/linux/fcntl-macros.h:61:9:
note: previous definition is here
#define S_IXOTH 01
^
It looks like we have these multiply defined. Deduplicate these flags;
users
should expect to find them in sys/stat.h. S_FIFO was wrong anyways
(should
have been S_IFIFO).
|
|
This is step 4 of
https://discourse.llvm.org/t/rfc-customizable-namespace-to-allow-testing-the-libc-when-the-system-libc-is-also-llvms-libc/73079
|
|
prevent file copy/paste issues. (#66477)
|
|
In patch D157792, the calls to SYS_llseek/SYS_llseek for 32-bit systems
were fixed in lseek.cpp but there was another implementation in file.cpp
that was missed.
To reduce the code duplication, this patch unifies both call sites to
use a new lseekimpl function.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D159208
|
|
This is done so that tests which only require platform file but not the
platform streams can be run as unit tests. The tests which use platform
streams can only be hermetic tests to avoid conflicts with the
system-libc streams.
Fixes:
https://github.com/llvm/llvm-project/issues/64663
https://github.com/llvm/llvm-project/issues/63558
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D158193
|
|
The GPU has much tighter requirements for handling IO functions.
Previously we attempted to define the GPU as one of the platform files.
Using a common interface allowed us to easily define these functions
without much extra work. However, it became more clear that this was a
poor fit for the GPU. The file interface uses function pointers, which
prevented inlining and caused bad perfromance and resource usage on the
GPU. Further, using an actual `FILE` type rather than referring to it as
a host stub prevented us from usin files coming from the host on the GPU
device.
After talking with @sivachandra, the approach now is to simply define
GPU specific versions of the functions we intend to support. Also, we
are ignoring `errno` for the time being as it is unlikely we will ever
care about supporting it fully.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D157427
|
|
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
|
|
This patch adds support for `fread` on the GPU via the RPC mechanism.
Here we simply pass the size of the read to the server and then copy it
back to the client via the RPC channel. This should allow us to do the
basic operations on files now. This will obviously be slow for large
sizes due ot the number of RPC calls involved, this could be optimized
further by having a special RPC call that can initiate a memcpy between
the two pointers.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D155121
|
|
Summary:
The RPC server used the size field which meant we didn't get the correct
return value for partial reads. We fix that here.
|
|
The `File` interface currently has a destructor to delete the buffer if
it is owned by the file. This is problematic for the globally allocated
`stdout`, `stdin`, and `stderr` files. This causes the file interface to
have global constructors to initialize the destructors to use these.
However, these never use the destructors because they don't own the
buffer. This patch removes the destructor and calls in manually in the
close implementation. The platform close should never need to access the
buffer and it needs to be done before clearing the whole thing, so this
should work.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D155762
|
|
Summary:
Simple cleanup of the interface so we do not depend on the installed
headers and get everything we need just including rpc_client.h.
|
|
This patch adds the necessary support for the fopen and fclose functions
to work on the GPU via RPC. I added a new test that enables testing this
with the minimal features we have on the GPU. I will update it once we
have `fread` and `fwrite` to actually check the outputted strings. For
now I just relied on checking manually via the outpuot temp file.
Reviewed By: JonChesterfield, sivachandra
Differential Revision: https://reviews.llvm.org/D154519
|
|
Reviewed By: michaelrj, thesamesam
Differential Revision: https://reviews.llvm.org/D153729
|
|
Before this change, a separate static method named cleanup was used to
cleanup the file. Instead, now the close method cleans up the full file
object using the platform's close function.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D153377
|
|
The libc flush operation is not supposed to trigger a platform level
flush operation. See "Notes" on this Linux man page:
https://man7.org/linux/man-pages/man3/fflush.3.html
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D153182
|
|
The GPU port of the LLVM C library needs to export a few extensions to
the interface such that users can interface with it. This patch adds the
necessary logic to define a GPU extension. Currently, this only exports
a `rpc_reset_client` function. This allows us to use the server in
D147054 to set up the RPC interface outside of `libc`.
Depends on https://reviews.llvm.org/D147054
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D152283
|
|
This patch moves the definitions of the standard IO streams to the
platform file definition. This is necessary because previously we had a
level of indirection where the stream's `FILE *` was initialized based
on the pointer to the internal `__llvm_libc` version. This cannot be
resolved ahead of time by the linker because the address will not be
known until runtime. This caused the previous implementation to emit a
global constructor to initialize the pointer to the actual `FILE *`. By
moving these definitions so that we can bind their address to the
original file type we can avoid this global constructor.
This file keeps the entrypoints, but makes them empty files only
containing an external reference. This is so they still appear as
entrypoints and get emitted as declarations in the generated headers.
Reviewed By: lntue, sivachandra
Differential Revision: https://reviews.llvm.org/D152983
|
|
The libc's equivalent of std::expected has a non-standard and
non-explicit operator T - https://github.com/llvm/llvm-project/issues/62738
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D152270
|
|
This patch adds the initial support required to support basic priting in
`stdio.h` via `puts` and `fputs`. This is done using the existing LLVM C
library `File` API. In this sense we can think of the RPC interface as
our system call to dump the character string to the file. We carry a
`uintptr_t` reference as our native "file descriptor" as it will be used
as an opaque reference to the host's version once functions like
`fopen` are supported.
For some unknown reason the declaration of the `StdIn` variable causes
both the AMDGPU and NVPTX backends to crash if I use the `READ` flag.
This is not used currently as we only support output now, but it needs
to be fixed
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D151282
|
|
This patch simply moves the special handling for `linux` files to a
subdirectory. This is done to make it easier in the future to extend
this support to targets (like the GPU) that will have different
dependencies.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D151231
|
