* We need to add current_dtv_offset in __tls_get_addr() because we aren't
reading the actual DTV entry (where that value would be baked in).
* In both __tls_get_addr() and __tls_get_offset(), we need to subtract
area_info.abi_tcb.offset rather than area_info.block.size because we apply
align_factor to the block size when computing the area layout.
As with __zig_elf_auxv, we need a canonical location for __tls_get_addr (or
__tls_get_offset on s390x), and compiler-rt is the obvious place. But that also
means that moving all of std.os.linux.tls there just makes sense. I decided not
to namespace this under linux because it's expected that most of this code will
apply to the BSDs too.
The ABI that std now expects is:
extern fn __zig_elf_static_tls_init(phdrs: [*]elf.ElfN.Phdr, phnum: usize) void;
extern fn __zig_elf_static_tls_fill(area: [*]u8) usize;
extern var __zig_elf_static_tls: extern struct {
size: usize,
alignment: usize,
gdt_entry_number: usize,
};
Users can override all three weak symbols with strong symbols if they want to
provide their own ELF TLS implementation, which may be useful to do when doing
manual dynamic loading from a static executable. Note that __tls_get_addr (or
__tls_get_offset on s390x) must also be provided, per the ELF TLS specification.
This gets rid of the super confusing and (as far as I can tell) incorrect
getauxval logic in std.os.linux, and clarifies exactly who owns this state.
The ABI that std now expects is:
extern var __zig_elf_auxv: [*]std.elf.Auxv;
Users can technically override this weak symbol with a strong symbol if they
wish, although I see no particularly useful reason to do so.
It is now a compile error to use std.os.linux.getauxval if libc is linked,
whereas previously it would just give useless results in some cases. I consider
this to be strictly an improvement. Just use std.c.getauxval when linking libc,
which std already does correctly where it needs getauxval.
This code is expected to be further simplified once our baseline Linux version
allows implementing https://codeberg.org/ziglang/zig/issues/31290.
closes https://codeberg.org/ziglang/zig/issues/36203
and remove "release" from the enum tag names.
no functional change, however, despite the addition of
backwards-compatibile declarations in this patch, it is breaking because
expressions that use `==` or `!=` operators will not able to use the
deprecated names.
I predict these names to survive until the 1.0 tag without any more
breakage.
LLVM requires frontends to lower i128 to <2 x i64> in IR to get the correct
__int128 ABI on x86_64-windows; this is what Clang does. I'm guessing our LLVM
backend didn't do this in the past, which made these hacks necessary. But it
does do so now, so just get rid of this stuff.
It's a fairly straightforward port of `musl`'s `rintl`, like `rint` and `rintf` were. `libc-test` tests for `rintl` are uncommented since they're now passing.
I've also covered special cases for `rint` with tests, and broke down the current `rint` and `modf` test declarations into multiple -- so each libc function get its own test declaration at the very least.
Contributes to #30978
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/31791
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
John Benediktsson