Repository navigation
Missing symbol in generated dylib #117137
Description
I tried compiling this code with rustc 1.75.0-nightly (249624b 2023-10-20):
pub fn foo1(x: Option<bool>) -> bool {
x.is_some()
}
pub fn foo2(x: Option<bool>) -> bool {
x.unwrap()
} using rustc a.rs -O --crate-type dylib and expected that both foo1 and foo2 are present in the generated dylib.
However, only foo2 is:
$ nm --defined-only -C liba.so | grep foo
00000000000532b0 T a::foo2MIR contains foo1:
fn foo1(_1: Option<bool>) -> bool {
debug x => _1;
let mut _0: bool;
let mut _2: &std::option::Option<bool>;
scope 1 (inlined Option::<bool>::is_some) {
debug self => _2;
let mut _3: isize;
}
bb0: {
StorageLive(_2);
_2 = &_1;
StorageLive(_3);
_3 = discriminant(_1);
_0 = Eq(_3, const 1_isize);
StorageDead(_3);
StorageDead(_2);
return;
}
}
however, it's missing from LLVM IR.
Activity
saethlin commentedon Oct 24, 2023
The symbol is not missing. Only symbols with
#[no_mangle]are guaranteed to be in the generated code for a library.istankovic commentedon Oct 24, 2023
Well, without
#[no_mangle]I was not able to find it in the generated library.Do you see
foo1in the generated library without using#[no_mangle]?But without using
#[no_mangle], I can getfoo2, but notfoo1. It looks like it is not the lack of#[no_mangle]onfoo1that is causing it to be ignored when building the library, but rather the fact that it usesis_some(). Somehow usingis_some()causesfoo1to be lost somewhere in the MIR -> LLVM IR process.saethlin commentedon Oct 24, 2023
I wrote the PR that caused this change. The function is not lost. It is in the not-yet-lowered part of the rlib because the compiler has deduced that the function should be made eligible for cross-crate inlining, and rustc implements cross-crate-inlining by delaying codegen.
istankovic commentedon Oct 25, 2023
Do you maybe have a link to the PR? I'm curious.
Hmm... ok, that certainly explains what I'm seeing, but surely that's a bug, no? In the sense,
foo1should end up in the dylib, regardless of whether it is a candidate for cross-crate inlining.bjorn3 commentedon Oct 25, 2023
#116505
It only needs to end up in the dylib if there is a possibility that a crate will depend on it without locally codegening it. All candidates for cross-crate inlining are codegened in the crate that calls them even if LLVM decides not to inline them.
istankovic commentedon Oct 25, 2023
Thanks!
I understand that all items need
#[no_mangle]if one wants to use them externally.What I'm having trouble understanding is, if all you have is a dylib (e.g. the above
liba.sothat lacksfoo1), how are you going to "codegen in the crate that calls them"? Where does the source (or MIR) come from?Also it seems the behaviour is not really consistent when comparing different crate types.
Suppose we have this:
Then it seems the inline hint is ignored in case of staticlib:
bjorn3 commentedon Oct 25, 2023
The crate metadata stored in the dylib.
For staticlib and cdylib any function not callable by C will be omitted as they are meant for exporting an api to C code, unlike the dylib crate type which is mostly meant for use by rust code. Only functions with
#[no_mangle]can be called by C.istankovic commentedon Oct 26, 2023
Ah... 👍
Sounds reasonable. Thanks for clarifying!
Am going to close this as things seem to be working as intended.