-Zdefault-hidden-visibility causes linking errors due to intrinsic-related calls

[chbaker0]

-Zdefault-hidden-visibility should affect symbols defined in a crate. References to externally-defined symbols should not have hidden visibility.

Certain intrinsics such as compare_bytes may emit calls to libc.so functions (e.g. memcmp). When -Zdefault-hidden-visibility is used, these symbol references are hidden. This leads to linking errors since an undefined hidden symbol cannot be resolved to a symbol in a dynamic library.

Repro:

#![feature(core_intrinsics)]

fn main() {
    let a = 0u8;
    let b = 0u8;

    println!("{}", unsafe {
        std::intrinsics::compare_bytes(&a as *const _, &b as *const _, 1)
    });
}

error:

note: /usr/bin/ld: .../rust/build/x86_64-unknown-linux-gnu/test/ui/default-hidden-visibility-intrinsic/default-hidden-visibility-intrinsic.default_hidden_visibility_intrinsic.adfc02789a1ff675-cgu.0.rcgu.o: in function `default_hidden_visibility_intrinsic::main':
           default_hidden_visibility_intrinsic.adfc02789a1ff675-cgu.0:(.text._ZN35default_hidden_visibility_intrinsic4main17hf16163bc798359ebE+0x1e): undefined reference to `memcmp'
           /usr/bin/ld: .../rust/build/x86_64-unknown-linux-gnu/test/ui/default-hidden-visibility-intrinsic/default-hidden-visibility-intrinsic: hidden symbol `memcmp' isn't defined
           /usr/bin/ld: final link failed: bad value
           collect2: error: ld returned 1 exit status

The flag was added in #118417; MCP rust-lang/compiler-team#656

While this flag isn't really intended for use on bin crates, I suspect crates downstream of an rlib or staticlib would have the same errors.

[chbaker0]

cc @bridiver @anforowicz @danakj

[bridiver]

In my original test of this locally I only changed https://github.com/rust-lang/rust/pull/118417/files#diff-6e38fd176c5407241bf7308381c05b28fd0b2d7f768ea52721cd3eaa6145653fR87 and it appeared to work correctly in terms of the resulting symbol table.

[chbaker0]

If that's the desired behavior, perhaps this flag should have a different name. I'd assume the original target config field's behavior was intentional, and it's confusing to have a compiler flag with the same name but subtly different behavior.

[bridiver]

If that's the desired behavior, perhaps this flag should have a different name. I'd assume the original target config field's behavior was intentional, and it's confusing to have a compiler flag with the same name but subtly different behavior.

That makes sense and I'm not sure this is the root of either issue, but just wanted to mention that not all of these are strictly needed for our purposes. It could also be that the behavior should be different on macOS for both cases and it just never came up because there was no way to disable symbols on Mac before this change. So if the problem exists here, then it would also exist if you built rust with a custom configuration to hide symbols by default on macOS so it seems then that the flag isn't necessarily broken, but instead the underlying functionality is broken on macOS?

[chbaker0]

Two tests that should pass, but fail with the flag: chbaker0@eec2e8e

[chbaker0]

@alexcrichton the target spec field default-hidden-visibility was originally added by your pull request #47889

Was it intended to apply hidden visibility to rustc-generated references to memcmp, memcpy?