Make `@returnAddress()` return for the BPF target, as the BPF target for
the time being does not support probing for the return address. Stack
traces for the general purpose allocator for the BPF target is also set
to not be captured.
Before, `std.Progress` was printing unwanted stuff to stderr. Now, the
test runner's logic to detect whether we should print each test as a
separate line to stderr is properly activated.
* Create Vector language documentation
Main changes to docs:
1. Create brief documentation on Zig vector types with code example
2. Get rid of the SIMD sub-heading under the main Vectors heading,
and update links accordingly
3. Add an example to the `@shuffle` docs
The status quo for the `build.zig` build system is preserved in
the sense that, if the user does not explicitly override
`dylib.setInstallName(...);` in their build script, the default
of `@rpath/libname.dylib` applies. However, should they want to
override the default behaviour, they can either:
1) unset it with
```dylib.setIntallName(null);```
2) set it to an explicit string with
```dylib.setInstallName("somename.dylib");```
When it comes to the command line however, the default is not to
use `@rpath` for the install name when creating a dylib. The user
will now be required to explicitly specify the `@rpath` as part
of the desired install name should they choose so like so:
1) with `build-lib`
```
zig build-lib -dynamic foo.zig -install_name @rpath/libfoo.dylib
```
2) with `cc`
```
zig cc -shared foo.c -o libfoo.dylib -Wl,"-install_name=@rpath/libfoo.dylib"
```
This reverts commit 11803a3a56.
Observations from the performance dashboard:
* strictly worse in terms of CPU instructions
* slightly worse wall time (but this can be noisy)
* sometimes better, sometimes worse for branch predictions
Given that the commit was introducing complexity for optimization's
sake, these performance changes do not seem worth it.
See https://github.com/ziglang/zig/pull/10337 for context.
In #10337 the `available` tracking fix necessitated an additional condition on the probe loop in both `getOrPut` and `getIndex` to prevent an infinite loop. Previously, this condition was implicit thanks to the guaranteed presence of a free slot.
The new condition hurts the `HashMap` benchmarks (https://github.com/ziglang/zig/pull/10337#issuecomment-996432758).
This commit removes that extra condition on the loop. Instead, when probing, first check whether the "home" slot is the target key — if so, return it. Otherwise, save the home slot's metadata to the stack and temporarily "free" the slot (but don't touch its value). Then continue with the original loop. Once again, the loop will be implicitly broken by the new "free" slot. The original metadata is restored before the function returns.
`getOrPut` has one additional gotcha — if the home slot is a tombstone and `getOrPut` misses, then the home slot is is written with the new key; that is, its original metadata (the tombstone) is not restored.
Other changes:
- Test hash map misses.
- Test using `getOrPutAssumeCapacity` to get keys at the end (along with `get`).
When entries are inserted and removed into a hash map at an equivalent rate (maintaining a mostly-consistent total count of entries), it should never need to be resized. But `HashMapUnmanaged.available` does not presently count tombstoned slots as "available", so this put/remove pattern eventually panics (assertion failure) when `available` reaches `0`.
The solution implemented here is to count tombstoned slots as "available". Another approach (which hashbrown (b3eaf32e60/src/raw/mod.rs (L1455-L1542)) takes) would be to rehash all entries in place when there are too many tombstones. This is more complex but avoids an `O(n)` bad case when the hash map is full of many tombstones.
This number tracks the glibc version in the oldest still-active LTS
version of Debian, which is Jessie, extended LTS expiring in June 2022,
at which point this number can be bumped again.
Before this commit, glibc headers did the following mapping:
* (zig) mipsel-linux-gnu => (glibc) mipsel-linux-gnu
* (zig) mipsel-linux-gnu-soft => (glibc) (none)
* (zig) mips-linux-gnu => (glibc) mips-linux-gnu
* (zig) mips-linux-gnu-soft => (glibc) (none)
While the glibc ABI stubs used the (zig) gnueabi and gnueabihf ABIs,
and the stage2 available_libcs array listed:
* (zig) mipsel-linux-gnu
* (zig) mips-linux-gnu
The problem is the mismatch between the ABI component of the headers and
the stubs.
This commit makes the following clarifications:
* (zig) mips-linux-gnueabi means soft-float
* (zig) mipsel-linux-gnueabi means soft-float
* (zig) mips-linux-gnueabihf means hard-float
* (zig) mipsel-linux-gnueabihf means hard-float
Consequently, the glibc headers now do this mapping:
* (zig) mips-linux-gnueabihf => (glibc) mips-linux-gnu
* (zig) mipsel-linux-gnueabihf => (glibc) mipsel-linux-gnu
* (zig) mips-linux-gnueabi => (glibc) mips-linux-gnu-soft
* (zig) mipsel-linux-gnueabi => (glibc) mipsel-linux-gnu-soft
The glibc ABI stubs are unchanged, and the stage2 available_libcs
array's 2 entries are modified and it gains 2 more:
* (zig) mipsel-linux-gnueabi
* (zig) mipsel-linux-gnueabihf
* (zig) mips-linux-gnueabi
* (zig) mips-linux-gnueabihf
Now everything is consistent. Zig no longer recognizes a `mips-linux-gnu`
triple; one must use `mips-linux-gnueabi` (soft float) or
`mips-linux-gnueabihf` (hard float).
Upstream, some of the nonshared functions moved to be different for hurd
and for linux. Since our glibc is linux-only we update to use the
linux-specific files.
This fixes std lib tests for x86_64 when linking glibc.
This commit introduces tools/update_glibc.zig to update the start files
for next time.
Some notable changes in recent glibc:
* abi-note.S has been changed to abi-note.c but we resist the change to
keep it easier to compile the start files.
* elf-init.c has been deleted upstream. Further testing should be done
to verify that binaries against glibc omitting elf-init.c still run
properly on oldel glibc linux systems.
Closes#4926
execve can return EBADLIB on Linux. I observed this when passing
an x86_64 interpreter path to qemu-i386.
This error code is Linux and Solaris-only. I came up with an improved
pattern for dealing with OS-specific error codes.
Since `BoundedArray.insert` internally reserves space for the element
to be inserted, it can support inserting at the position that is
the current length of the array. Change the check for the insertion position
to allow this.
