[libc] Migrate to using LIBC_NAMESPACE_DECL for namespace declaration (#98597)

This is a part of #97655.

Revert "[libc] Migrate to using LIBC_NAMESPACE_DECL for namespace declaration" (#98593)

Reverts llvm/llvm-project#98075

bots are broken

[libc] Migrate to using LIBC_NAMESPACE_DECL for namespace declaration (#98075)

This is a part of #97655.

[libc] Codify header inclusion policy (#87017)


When supporting "overlay" vs "fullbuild" modes, "what ABI are you
using?" becomes a fundamental question to have concrete answers for.
Overlay mode MU

[libc] Codify header inclusion policy (#87017)


When supporting "overlay" vs "fullbuild" modes, "what ABI are you
using?" becomes a fundamental question to have concrete answers for.
Overlay mode MUST match the ABI of the system being overlayed onto;
fullbuild more flexible (the only system ABI relevant is the OS kernel).

When implementing llvm-libc we generally prefer the include-what-you use
style of avoiding transitive dependencies (since that makes refactoring
headers more painful, and slows down build times). So what header do you
include for any given type or function declaration? For any given
userspace program, the answer is straightforward. But for llvm-libc
which is trying to support multiple ABIs (at least one per
configuration), the answer is perhaps less clear.

This proposal seeks to add one layer of indirection relative to what's
being done today.

It then converts users of sigset_t and struct epoll_event and the epoll
implemenations over to this convention as an example.

show more ...

[libc] fix -Wcast-function-type via union rather than reinterpret_cast (#76875)

The GCC build is producing the following diagnostic:

llvm-project/libc/src/signal/linux/signal_utils.h: In member f

[libc] fix -Wcast-function-type via union rather than reinterpret_cast (#76875)

The GCC build is producing the following diagnostic:

llvm-project/libc/src/signal/linux/signal_utils.h: In member function
‘__llvm_libc_18_0_0_git::KernelSigaction&
__llvm_libc_18_0_0_git::KernelSigaction::operator=(const sigaction&)’:
llvm-project/libc/src/signal/linux/signal_utils.h:38:20: warning:
cast between incompatible function types from ‘void (*)(int, siginfo_t*,
void*)’ to ‘void (*)(int)’ [-Wcast-function-type]
38 | sa_handler = reinterpret_cast<HandlerType *>(sa.sa_sigaction);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
llvm-project/libc/src/signal/linux/signal_utils.h: In member function
‘__llvm_libc_18_0_0_git::KernelSigaction::operator sigaction() const’:
llvm-project/libc/src/signal/linux/signal_utils.h:51:25: warning:
cast between incompatible function types from ‘void (*)(int)’ to ‘void
(*)(int, siginfo_t*, void*)’ [-Wcast-function-type]
51 | sa.sa_sigaction = reinterpret_cast<SiginfoHandlerType
*>(sa_handler);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Two issues here:
1. Clang supports -Wcast-function-type, but not as part of the -Wextra
group.
2. The existing implementation tried to work around the oddity that is
the
kernel's struct sigaction != POSIX via reinterpret_cast in a way that's
not
compatible with -Wcast-function-type. Just use a union which is well
defined
(and two function pointers are the same size.)

Link: https://github.com/llvm/llvm-project/issues/76872

Fixes: https://github.com/llvm/llvm-project/issues/74617

show more ...

[libc] Mass replace enclosing namespace (#67032)

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

[libc][cleanup] Fix most conversion warnings

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 wh

[libc][cleanup] Fix most conversion warnings

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

show more ...

[libc] Use the new style includes

We should be using the standard includes.

Differential Revision: https://reviews.llvm.org/D154529

[libc][NFC] Another round of replacement of static inline with LIBC_INLINE.

Reviewed By: lntue

Differential Revision: https://reviews.llvm.org/D142398

[libc] add syscall function

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 Re

[libc] add syscall function

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

show more ...

[libc] Re-enable functions from signal.h and re-enable abort.

They were disabled because we were including linux/signal.h from our
signal.h. Linux's signal.h is not designed to be included from user

[libc] Re-enable functions from signal.h and re-enable abort.

They were disabled because we were including linux/signal.h from our
signal.h. Linux's signal.h is not designed to be included from user
programs as it causes a lot of non-standard name pollution. Also, it is
not self-contained. This change defines types and macros relevant for
signal related syscalls within libc's headers and removes inclusion of
Linux headers.

This patch enables the funtions only for x86_64. They will be enabled
for aarch64 also in a follow up patch after testing.

Reviewed By: abrachet, lntue

Differential Revision: https://reviews.llvm.org/D134567

show more ...