-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Support raw-dylib functions being used inside inlined functions #102988
Conversation
r? @davidtwco (rust-highfive has picked a reviewer for you, use r? to override) |
ebf5338
to
9ed8a0f
Compare
Thanks, @dpaoliello! I'm in the process of reviewing this. |
This issue exists for all kinds on native libraries, not only raw dylibs. If we have a tree like this
then the "Rust dylib" can leak symbols from all the native libs through inline/const/generic functions. For this reason
Also, what happens with Rust dylib dependencies of the second order (Final executable -> Rust dylib -> Rust dylib -> Native libs)? Are they also always linked into the final binary (together with their native dependencies)? UPD: Yes, they are. This all feels suboptimal. |
I believe it exports all functions which you declared in |
@petrochenkov, to make sure I understand this correctly: you propose to do pretty much the same as this PR, but generate import libraries that only contain the symbols that are actually needed? |
@michaelwoerister |
9ed8a0f
to
d21a168
Compare
Yes, that sounds reasonable to me. Although there is a trade-off between the additional complexity this might introduce in rustc (not sure how complex it would actually be) and the gains we might expect from generating more targeted import libs. I'd guess, there's no way of telling without giving it a try. But yes, not in this PR. |
Thanks for the PR, @dpaoliello! The implementation looks good to me It would be great to add another test for the transitive case @petrochenkov mentions, i.e. |
d21a168
to
f9acfc4
Compare
Added this test case. |
This comment has been minimized.
This comment has been minimized.
f9acfc4
to
db52b64
Compare
Thanks, @dpaoliello! |
📌 Commit db52b64b672c489823d760e87faa48a6e33d34cd has been approved by It is now in the queue for this repository. |
⌛ Testing commit db52b64b672c489823d760e87faa48a6e33d34cd with merge 5edf6a1ac36d232f1e8be86f64d64bf79e92c9f9... |
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
Looks like the added test just needs to be updated to account for raw-dylib being unstable on x86. @bors delegate+ |
✌️ @dpaoliello can now approve this pull request |
db52b64
to
3a1ef50
Compare
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (31d754a): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Footnotes |
discussed in T-compiler meeting today beta backport approved, with expectation that it will be part of Rust 1.65 that goes out in one week. @rustbot label: beta-accepted |
…mulacrum [beta] backport rollup * poll_fn and Unpin: fix pinning rust-lang#102737 * Support raw-dylib functions being used inside inlined functions rust-lang#102988 * Fix line numbers for MIR inlined code rust-lang#103071 * Add architectures to fn create_object_file rust-lang#103240 * Add eval hack in super_relate_consts back rust-lang#103279 * Mark std::os::wasi::io::AsFd etc. as stable. rust-lang#103308 * Truncate thread names on Linux and Apple targets rust-lang#103379 * Do not consider repeated lifetime params for elision. rust-lang#103450 * rustdoc: add missing URL redirect rust-lang#103588 * Remove commit_if_ok probe from NLL type relation rust-lang#103601 Also includes a copy of the release notes. r? `@ghost`
Fixes #102714
Issue Details:
When generating the import library for
raw-dylib
symbols, we currently only use the functions and variables declared within the current crate. This works fine if all crates are static libraries orrlib
s as the generated import library will be contained in the static library orrlib
itself, but if a dependency is a dynamic library AND the use of araw-dylib
function or variable is inlined or part of a generic instantiation then the current crate won't see its dependency's import library and so linking will fail.Fix Details:
Instead, when we generate the import library for a
dylib
orbin
crate, we will now generate it for the symbols both for the current crate and all upstream crates. We do this in two steps so that the import library for the current crate is passed into the linker first, thus it is preferred if there are any ambiguous symbols.