LIBC_INLINE is defined in attributes.h, which was not included. Since
constexpr already implies inline, simply remove the LIBC_INLINE
qualifier from the static helper, matching the x86_64 and aarch64
irelative implementations.
Resolves ifunc targets before `main()` runs in static libc
This enables static binaries to use ifunc-based dispatch during early
process startup, so optimized implementations can be selected based on
CPU features. Without this relocation step in startup, those targets are
not ready when program code begins executing.
This change:
- adds IRELATIVE relocation handling for x86_64, AArch64, ARMv7 and RISC-V,
- reads `AT_HWCAP` / `AT_HWCAP2` from auxv and passes them to resolvers
where required (notably AArch64),
- runs IRELATIVE processing after base-address discovery and before TLS
setup,
- adds integration tests for both the ifunc path and the no-ifunc path,
- Changed the load bias type for ptrdiff_t to intptr_t to align with
IRELATIVE handling, which uses intptr_t for load bias calculations.
In order to add Control-flow Enforcement Technology (CET) Shadow Stack
(SHSTK) support, we need to parse the `PT_GNU_PROPERTY` program header
and the corresponding section to evaluate if the binary being started
was compiled with the necessary support.
PS: This is my first PR to llvm-libc, I might have made obvious styling
mistakes so I'd appreciate any feedback or suggestions to improve it.
I have a prototype branch using this change to enable SHSTK support:
https://github.com/jakos-sec/llvm-project/tree/add-shstk-support
teardown_main_tls is called right before the main process exit to unmap
the TLS but that's unnecesary since the process is terminating anyway,
this just introduces extra system call. This can be potentially harmful
in case one of the other threads tries the access the memory that has
been unmapped. Other C library implementations don't unmap TLS either so
this makes LLVM libc's behavior more consistent.
Fixes#173409
Closes https://github.com/llvm/llvm-project/issues/153666
This patch introduces a new centralized AUXV (auxiliary vector) handling
mechanism for LLVM libc on Linux, replacing the previous scattered
implementation across multiple files.
## Key Changes:
### New Files:
- **libc/src/__support/OSUtil/linux/auxv.h**: New header library
providing
a clean interface for AUXV access with:
- `auxv::Entry` struct for AUXV entries (type and value)
- `auxv::Vector` class with iterator support for traversing AUXV
- `auxv::get()` function for retrieving specific AUXV values
- Thread-safe initialization with fallback mechanisms (prctl and
/proc/self/auxv)
### Modified Files:
1. **libc/src/__support/OSUtil/linux/CMakeLists.txt**:
- Added `auxv` header library declaration with proper dependencies:
- libc.hdr.fcntl_macros
- libc.src.__support.OSUtil.osutil
- libc.src.__support.common
- libc.src.__support.CPP.optional
- libc.src.__support.threads.callonce
2. **libc/config/linux/app.h**:
- Removed `AuxEntry` struct (moved to auxv.h as `auxv::Entry`)
- Removed `auxv_ptr` from `AppProperties` struct
- Simplified application properties structure
3. **libc/src/sys/auxv/linux/getauxval.cpp**:
- Completely refactored to use new auxv.h interface
- Removed ~200 lines of complex initialization code
- Simplified to just call `auxv::get()` function
- Removed dependencies to external symbols (mman, prctl, fcntl, read,
close, open)
4. **libc/src/sys/auxv/linux/CMakeLists.txt**:
- Updated dependencies to use new auxv header library
- Removed dependencies to external symbols (prctl, mman, fcntl, unistd,
etc.)
5. **libc/startup/linux/do_start.cpp**:
- Updated to use new `auxv::Vector` interface
- Changed from pointer-based to iterator-based AUXV traversal
- Updated field names (`aux_entry->id` → `aux_entry.type`,
`aux_entry->value` → `aux_entry.val`)
- Added call to `auxv::Vector::initialize_unsafe()` for early AUXV setup
6. **libc/startup/linux/CMakeLists.txt**:
- Added dependency on `libc.src.__support.OSUtil.linux.auxv`
The call chain to `Mutex:lock` can be polluted by stack protector. For
completely safe, let's postpone the main TLS tearing down to a separate
phase.
fix#108030
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.
This PR fix several build errors on aarch64 targets when building with
gcc:
- uninitialized values leading to `Werrors`
- undefined builtin functions
- glibc header pollution
Otherwise the startup objects will fail to link since they were cross compiled,
but the linker is not informed of the intent to cross compile, which results in
linker errors when the host architecture does not match the target
architecture.
Summary:
Currently, doing `ninja install` will fail in fullbuild mode due to the
startup utilities not being built by default. This was hidden previously
by the fact that if tests were run, it would build the startup utilities
and thus they would be present.
This patch solves this issue by making the `libc-startup` target a
dependncy on the final library. Furthermore we simply factor out the
library install directory into the base CMake directory next to the
include directory handling. This change makes the `crt` files get
installed in `lib/x86_64-unknown-linu-gnu` instead of just `lib`.
This fixes an error I had where doing a runtimes failed to install its
libraries because the install step always errored.
```
AppProperties app;
```
is marked as a weak symbol in header now. One can just use `&app !=
nullptr` to check if `app` is defined. There is no need to define it for
overlay mode.
For some reasons, we are using `-fpie`
(libc/cmake/modules/LLVMLibCObjectRules.cmake:31) without supporting it.
According to @lntue, some of the hermetic tests are broken without
proper PIE support. This patch implements basic relocations support for
PIE.
* separate initialization routines into _start and do_start for all
architectures.
* lift do_start as a separate object library to avoid code duplication.
* (addtionally) address the problem of building hermetic libc with
-fstack-pointer-*
The `crt1.o` is now a merged result of three components:
```
___
|___ x86_64
| |_______ start.cpp.o <- _start (loads process initial stack and aligns stack pointer)
| |_______ tls.cpp.o <- init_tls, cleanup_tls, set_thread_pointer (TLS related routines)
|___ do_start.cpp.o <- do_start (sets up global variables and invokes the main function)
```
As part of startup refactoring, this patch adds a function to merge
multiple objects into a single relocatable object:
cc -r obj1.o obj2.o -o obj.o
A relocatable object is an object file that is not fully linked into an
executable or a shared library. It is an intermediate file format that
can be passed into the linker.
A crt object can have arch-specific code and arch-agnostic code. To
reduce code cohesion, the implementation is splitted into multiple
units. As a result, we need to merge them into a single relocatable
object.
__stack_chk_fail should be provided by libc.a, not startup files.
Add __stack_chk_fail to existing linux and arm entrypoints. On Windows
(when
not targeting MinGW), it seems that the corresponding function
identifier is
__security_check_cookie, so no entrypoint is added for Windows.
Baremetal
targets also ought to be compileable with `-fstack-protector*`
There is no common header for this prototype, since calls to
__stack_chk_fail
are meant to be inserted by the compiler upon function return when
compiled
`-fstack-protector*`.
This patch lifts aux vector related definitions to app.h. Because
startup's refactoring is in progress, this patch still contains
duplicated changes. This problem will be addressed very soon in an
incoming patch.
If a function is declared with stack-protector, the compiler may try to
load the TLS. However, inside certain runtime functions, TLS may not be
available. This patch disables stack protectors for such routines to fix
the problem.
Closes#74487.
This patch enables the compilation of libc for rv32 by unifying the
current rv64 and rv32 implementation into a single rv implementation.
We updated the cmake file to match the new riscv32 arch and force
LIBC_TARGET_ARCHITECTURE to be "riscv" whenever we find "riscv32" or
"riscv64". This is required as LIBC_TARGET_ARCHITECTURE is used in the
path for several platform specific implementations.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D148797
This patch changes the default types of argc/argv so it's no longer a
uint64_t in all systems, instead, it's now a uintptr_t, which fixes
crashes in 32-bit systems that expect 32-bit types. This patch also adds
two uintptr_t types (EnvironType and AuxEntryType) for the same reason.
The patch also adds a PgrHdrTableType type behind an ifdef that's
Elf64_Phdr in 64-bit systems and Elf32_Phdr in 32-bit systems.
This patch changes the instruction in set_thread_ptr from ld to mv,
as rv32 doesn't have the ld instruction, and mv is supported by both
rv32 and rv64.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D159110
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 mostly renames files so it better reflects the function they declare.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D155607
This patch standardizes the error messages when a syscall is not
available to be in the format: "ABC and DEF syscalls are not available."
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D148373
