This is an implementation of `ctime` and includes `ctime_r`.
According to documentation, `ctime` and `ctime_r` are defined as the
following:
```c
char *ctime(const time_t *timep);
char *ctime_r(const time_t *restrict timep, char buf[restrict 26]);
```
closes#86567
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.
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>
Summary:
This patch implements 'getenv'. I was torn on how to implement this,
since realistically we only have access to this environment pointer in
the "loader" interface. An alternative would be to use an RPC call every
time, but I think that's overkill for what this will be used for. A
better solution is just to emit a common `DataEnvironment` that contains
all of the host visible resources to initialize. Right now this is the
`env_ptr`, `clock_freq`, and `rpc_client`.
I did this by making the `app.h` interface that Linux uses more general,
could possibly move that into a separate patch, but I figured it's
easier to see with the usage.
- added all variations of ffma and fdiv
- will add all new headers into yaml for next patch
- only fsub is left then all basic operations for float is complete
---------
Co-authored-by: OverMighty <its.overmighty@gmail.com>
This patch enables more entrypoints for riscv. The changes to the test cases are introduced to support rv32 which has long double but doesn't have int128
Disable `strfroml` entrypoint on aarch64 to please clang-11 buildbots.
Detailed in https://github.com/llvm/llvm-project/issues/101846. This is
not a fix for #101846 so I will keep the issue open until our buildbot
is updated or other mitigation is applied.
This is a non-feature change that enables most of the entrypoints for
aarch64 based runtime builds. It fixes an additional problem that some
compiler-rt targets are not defined at the time of dependency checking
thus leading to false-negatives.
According to discussions on monthly meeting, we probably don't want to
cache `getpid` anymore. glibc removes their cache. bionic is hesitating
whether such cache is to be removed. `getpid` is async-signal-safe, so
we must make sure it always work.
However, for `gettid`, we have more freedom. Moreover, we are using
`gettid` to examine deadlock such that the performance penalty is not
negligible here. Thus, this patch is separated from previous patch to
provide only `tid` caching. It is much more simplified. Hopefully,
previous build issues can be resolved easily.
- fadd removed because I need to add for different input types
- finishing rest of basic operations
- noticed duplicates will remove
---------
Co-authored-by: OverMighty <its.overmighty@gmail.com>
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.
The bind test was failing in the rv32 build bot because of how the build bot was set to run the tests: we were using shared directories between the host and qemu and the bind function was trying to create a file in this directory, thus creating it in the host machine.
The OS was returning "-1 ENXIO (No such device or address)", so we changed the rv32 buildbot to copy the binaries to qemu and dropped the shared directories feature.
This patch reverts #99781 and part of #99771 since `epoll_pwait2` is not
in fact available on all supported systems. It is my opinion that we
shouldn't provide a version of a function that doesn't perform as
expected, which is why this revert needs to happen.
The `epoll_pwait2` function can be reenabled when we have a way to check
if it is available on the target system, tracking bug for that is #80060
When SYS_statfs64 is used, struct statfs64 is used instead of struct statfs. This patch adds a define to select the appropriate struct, similar to how it's done internally.
This patch also enables fstatvfs and statvfs on riscv, which would not be compiled without this change.