Only allow compiler_builtins to call LLVM intrinsics, not any link_name function...
source link: https://github.com/rust-lang/rust/pull/123347
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Conversation
Member
This is another case of accidental reliance on inline(never) like I rooted out in #118770. Without this PR, attempting to build some large programs with -Zcross-crate-inline-threshold=yes with a sysroot also compiled with that flag will result in linker errors like this:
= note: /usr/bin/ld: /tmp/cargo-installNrfN4T/x86_64-unknown-linux-gnu/release/deps/libcompiler_builtins-d2a9b69f4e45b883.rlib(compiler_builtins-d2a9b69f4e45b883.compiler_builtins.dbbc6c2ca970faa4-cgu.0.rcgu.o): in function `core::panicking::panic_fmt':
/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panicking.rs:72:(.text.unlikely._ZN4core9panicking9panic_fmt17ha407cc99e97c942fE+0x31): undefined reference to `rust_begin_unwind'
With -Zcross-crate-inline-threshold=yes we can inline panic_fmt into compiler_builtins. Then we end up with a call to an upstream monomorphization, but one that has a link_name set. But unlike LLVM's magic intrinsic names, this link name is going to make it to the linker, and then we have a problem.
This logic looks scuffed, but also we're doing this in 4 other places. Don't know if that means it's good or bad.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK