Our glibc stub assembly file looked something like this:
```
.globl _Exit_2_2_5
.type _Exit_2_2_5, %function;
.symver _Exit_2_2_5, _Exit@@GLIBC_2.2.5
.hidden _Exit_2_2_5
_Exit_2_2_5:
```
With clang 12, the shared objects this produced stopped having any
exported symbols. When I removed the `.hidden` directive, it resolved
the issue, however, there are now unwanted exports:
```
$ readelf -W --dyn-syms libc.so.6 | grep sys_errlist
139: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 _sys_errlist_GLIBC_2_3
147: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 _sys_errlist_GLIBC_2_4
395: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 _sys_errlist_GLIBC_2_2_5
487: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 sys_errlist_GLIBC_2_2_5
1266: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 _sys_errlist@@GLIBC_2.12
1267: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 _sys_errlist@GLIBC_2.2.5
1268: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 _sys_errlist@GLIBC_2.3
1269: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 _sys_errlist@GLIBC_2.4
2137: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 sys_errlist@@GLIBC_2.12
2138: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 sys_errlist@GLIBC_2.2.5
2139: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 sys_errlist@GLIBC_2.3
2140: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 sys_errlist@GLIBC_2.4
2156: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 sys_errlist_GLIBC_2_3
2161: 000000000001ee08 0 FUNC GLOBAL DEFAULT 7 sys_errlist_GLIBC_2_4
```
Every line here without an `@` symbol is an unwanted export. Before, the
unwanted ones had LOCAL HIDDEN linkage.
As a mitigation, I did two things:
* Added `_GLIBC_` to the unwanted exports so that they would not
conflict with anything.
* Made the default export (the `@@` one) the bare symbol name. This
appears to reduce the unwanted exports to only symbols that have more
than one symbol (which is still quite many).
This will unblock progress on this branch, however, there is now a new
issue to solve, that the provided glibc stub .so files have too many
symbols exported. We will have to find a way to avoid this.
* CLI: change to -mred-zone and -mno-red-zone to match gcc/clang.
* build.zig: remove the double negative and make it an optional bool.
This follows precedent from other flags, allowing the compiler CLI to
be the decider of what is default instead of duplicating the default
value into the build system code.
* Compilation: make it an optional `want_red_zone` instead of a
`no_red_zone` bool. The default is decided by a call to
`target_util.hasRedZone`.
* When creating a Clang command line, put -mred-zone on the command
line if we are forcing it to be enabled.
* Update update_clang_options.zig with respect to the recent {s}/{} format changes.
* `zig cc` integration with red zone preference.
Previously Zig would need to recompile runtime libs if you changed the
values of --strip or -O. Now, unless the `debug_compiler_runtime_libs`
flag is set (which is currently not exposed to the CLI), Zig will always
choose ReleaseFast or ReleaseSmall for compiler runtime libraries.
When the main application chooses ReleaseFast or ReleaseSmall, that
value is propagated to compiler runtime libraries. Otherwise a decision
is made based on the target, which is currently ReleaseSmall for
freestanding WebAssembly and ReleaseFast for everything else.
Ultimately the purpose of this commit is to have Debug and ReleaseSafe
builds of applications still get optimized builds of, e.g. libcxx and
libunwind, as well as to spend less time unnecessarily rebuilding compiler
runtime libraries.
* rename is_compiler_rt_or_libc to skip_linker_dependencies
and set it to `true` for all sub-Compilations. I believe
this resolves the deadlock we were experiencing on Drone
CI and on some users' computers. I will remove the CI workaround in
a follow-up commit.
* enabling TSAN automatically causes the Compilation to link against
libc++ even if not requested, because TSAN depends on libc++.
* add -fno-rtti flags where appropriate when building TSAN objects.
Thanks Firefox317 for pointing this out.
* TSAN support: resolve all the undefined symbols. We are still seeing
a dependency on __gcc_personality_v0 but will resolve this one in a
follow-up commit.
* static libs do not try to build libc++ or libc++abi.
std.crypto.random
* cross platform, even freestanding
* can't fail. on initialization for some systems requires calling
os.getrandom(), in which case there are rare but theoretically
possible errors. The code panics in these cases, however the
application may choose to override the default seed function and then
handle the failure another way.
* thread-safe
* supports the full Random interface
* cryptographically secure
* no syscall required to initialize on Linux (AT_RANDOM)
* calls arc4random on systems that support it
`std.crypto.randomBytes` is removed in favor of `std.crypto.random.bytes`.
I moved some of the Random implementations into their own files in the
interest of organization.
stage2 no longer requires passing a RNG; instead it uses this API.
Closes#6704
