LTO preserves too many extern symbols

[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!

[alexcrichton]

cc https://bugzilla.mozilla.org/show_bug.cgi?id=1288173
cc @froydnj

[wesleywiser]

I'd like to give this a shot if that's ok. What's the best way to test a fix? Running the above test case?

[alexcrichton]

@wesleywiser sure! I'm not sure there's a great test case we can check in for this, but to manually test it yeah the commands in the description should be good enough.

[wesleywiser]

Ok cool! I believe your hunch was correct. The code was balling out too soon if the function's ABI wasn't Rust. Removing the early return and running the above commands no longer shows those symbols. Is there any other tests I should run before opening a PR? (The check-stage2 target passes on OS X.)

[alexcrichton]

Awesome! I'd run a full make check just to be sure, but if that passes it's probably good to go