Skip to content

LTO preserves too many extern symbols #34985

Closed
@alexcrichton

Description

@alexcrichton

Right now the standard library ends up exporting a bunch of extern symbols from liblibc:

$ echo '#[no_mangle] pub extern fn foo() { panic!() }' > foo.rs
$ echo 'extern void foo(); int main() { foo(); return 0; }' > foo.c
$ rustc foo.rs --crate-type staticlib -C lto
$ gcc foo.c libfoo.a
$ nm -g ./a.out | grep libc
000000000049e310 T _ZN4libc4unix6notbsd11WEXITSTATUS17hdf8e9951afe1c101E
000000000049e530 T _ZN4libc4unix6notbsd5linux7CPU_SET17hb5ba54c4f04e4ad5E
000000000049e510 T _ZN4libc4unix6notbsd5linux8CPU_ZERO17hc3389841ca5535cfE
000000000049e630 T _ZN4libc4unix6notbsd5linux9CPU_EQUAL17h6aa5067ba806ec07E
000000000049e5b0 T _ZN4libc4unix6notbsd5linux9CPU_ISSET17h25c9bc3ffd366857E
000000000049e170 T _ZN4libc4unix6notbsd6FD_CLR17h82439e27c061361cE
000000000049e250 T _ZN4libc4unix6notbsd6FD_SET17h6f0001978b943490E
000000000049e2c0 T _ZN4libc4unix6notbsd7FD_ZERO17h157d16767431163aE
000000000049e1e0 T _ZN4libc4unix6notbsd8FD_ISSET17h9bb2d4903026e75fE
000000000049e320 T _ZN4libc4unix6notbsd8WTERMSIG17h140bc8346daf707fE
000000000049e2f0 T _ZN4libc4unix6notbsd9WIFEXITED17h9b79d0f36c3cdb42E

These are all defined in the libc crate, but LTO should be stripping them out.

I believe the reason that this is happening is we attempt to preserve extern symbols from upstream crates (as they may be part of the ABI), but we don't check for #[no_mangle] (which none of these functions have).

I think the relevant clause is here which ends up calling this function coming over to this function. Although there's a clause which looks like it checks for this, I think we're falling through too quickly and we may wish to change that.

Note that this is mostly just a hunch though, some more investigation may be required! For an aspiring trans hacker though I don't think this should be too hard and I'd be willing to help out!

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-linkageArea: linking into static, shared libraries and binariesE-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions