-
Notifications
You must be signed in to change notification settings - Fork 13.3k
wasm: Explicitly export all symbols with LLD #54766
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This commit fixes an oddity on the wasm target where LTO can produce working executables but plain old optimizations doesn't. The compiler already knows what set of symbols it would like to export, but LLD only discovers this list transitively through symbol visibilities. LLD may not, however, always find all the symbols that we'd like to export. For example if you depend on an rlib with a `#[no_mangle]` symbol, then if you don't actually use anything from the rlib then the symbol won't appear in the final artifact! It will appear, however, with LTO. This commit attempts to rectify this situation by ensuring that all symbols rustc would otherwise preserve through LTO are also preserved through the linking process with LLD by default.
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
Looks good to me! In the long run this should probably be implemented via a linker script like for the other linkers, so as not to run into commandline length issues. I'll let you decide if you want to do that in this PR or just r=me. |
I agree! It looks though like LLD doesn't currently have an option for that for the wasm linker, but I'll file an issue. @bors: r=michaelwoerister |
📌 Commit c7f4f3a has been approved by |
Hm actually, that may not be necessary. We've already got automatic logic to fall back to using |
wasm: Explicitly export all symbols with LLD This commit fixes an oddity on the wasm target where LTO can produce working executables but plain old optimizations doesn't. The compiler already knows what set of symbols it would like to export, but LLD only discovers this list transitively through symbol visibilities. LLD may not, however, always find all the symbols that we'd like to export. For example if you depend on an rlib with a `#[no_mangle]` symbol, then if you don't actually use anything from the rlib then the symbol won't appear in the final artifact! It will appear, however, with LTO. This commit attempts to rectify this situation by ensuring that all symbols rustc would otherwise preserve through LTO are also preserved through the linking process with LLD by default.
☀️ Test successful - status-appveyor, status-travis |
This commit fixes an oddity on the wasm target where LTO can produce
working executables but plain old optimizations doesn't. The compiler
already knows what set of symbols it would like to export, but LLD only
discovers this list transitively through symbol visibilities. LLD may
not, however, always find all the symbols that we'd like to export.
For example if you depend on an rlib with a
#[no_mangle]
symbol, thenif you don't actually use anything from the rlib then the symbol won't
appear in the final artifact! It will appear, however, with LTO. This
commit attempts to rectify this situation by ensuring that all symbols
rustc would otherwise preserve through LTO are also preserved through
the linking process with LLD by default.