Skip to content
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

Create _imp__ symbols also when doing ThinLTO #129079

Merged
merged 2 commits into from
Oct 11, 2024

Conversation

Zoxc
Copy link
Contributor

@Zoxc Zoxc commented Aug 14, 2024

When generating a rlib crate on Windows we create dllimport / _imp__ symbols for each global. This effectively makes the rlib contain an import library for itself and allows them to both be dynamically and statically linked. However when doing ThinLTO we do not generate these and thus we end up with missing symbols. Microsoft's link can fix these up (and emits warnings), but lld seems to currently be unable to.

This PR also does this generation for ThinLTO avoiding those issues with lld and also avoids the warnings on link.

This is an workaround for #81408.

cc @lqd

@rustbot
Copy link
Collaborator

rustbot commented Aug 14, 2024

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 14, 2024
Copy link
Member

@wesleywiser wesleywiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a simple test case to demonstrate that the _imp__ symbols are generated now? Asm or llvm-ir test would be sufficient if it's too complex to do an end-to-end test.

@Zoxc
Copy link
Contributor Author

Zoxc commented Aug 20, 2024

I think we'd need to inspect the symbols in the linker inputs to test this.

@lqd
Copy link
Member

lqd commented Aug 20, 2024

if it's too complex to do an end-to-end test

@wesleywiser what would you want to see in an end-to-end test? #81408 will pass before and after this PR, until we revert #103353 -- is lqd@f9fb8e9 what you have in mind? (note it doesn't duplicate cargo's use of -Clinker-plugin-lto as it wasn't needed to reproduce the failure, but easily can be added if need be of course)

@ChrisDenton
Copy link
Member

Note that merged this fixes #111480

Copy link
Member

@wesleywiser wesleywiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Talked with @lqd offline about his comment and I'm fine with merging this as-is.

@wesleywiser
Copy link
Member

Thanks @Zoxc!

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Oct 11, 2024

📌 Commit 562c0d1 has been approved by wesleywiser

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 11, 2024
@lqd
Copy link
Member

lqd commented Oct 11, 2024

@ChrisDenton as you've done the most investigation on #111480, do we need a test for that issue, or is the one added in this PR good for it as well? That is, it seems like #111480 is a duplicate of #81408?

@ChrisDenton
Copy link
Member

Fully minimizing #111480 seems to be near enough the test case here. I guess there is a difference in that #111480 does compiles a cdylib as well.

@lqd
Copy link
Member

lqd commented Oct 11, 2024

IIRC there are a few issues when multiple crate types are used with cargo including cdylibs, and LTO enabled, like rust-lang/cargo#9672; other issues happen with PGO as well #117220

(I hope these issues don't emulate -Zdylib-lto in practice...)

I guess we can leave #111480 as E-needs-test and people can use this one as a base and also test a cdylib in there if they want. The missing _imp symbols should be the root cause in both types of libraries anyways.

@ChrisDenton
Copy link
Member

Yeah I don't feel strongly either way. I'm happy with the test here as it does exercise the underlying problem.

bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 11, 2024
…iaskrgr

Rollup of 6 pull requests

Successful merges:

 - rust-lang#129079 (Create `_imp__` symbols also when doing ThinLTO)
 - rust-lang#131208 (ABI: Pass aggregates by value on AIX)
 - rust-lang#131394 (fix(rustdoc): add space between struct fields and their descriptions)
 - rust-lang#131519 (Use Default visibility for rustc-generated C symbol declarations)
 - rust-lang#131541 (compiletest: Extract auxiliary-crate properties to their own module/struct)
 - rust-lang#131542 (next-solver: remove outdated FIXMEs)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 7c79621 into rust-lang:master Oct 11, 2024
6 checks passed
@rustbot rustbot added this to the 1.83.0 milestone Oct 11, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Oct 11, 2024
Rollup merge of rust-lang#129079 - Zoxc:thinlto_imp_symbols, r=wesleywiser

Create `_imp__` symbols also when doing ThinLTO

When generating a rlib crate on Windows we create `dllimport` / `_imp__` symbols for each global. This effectively makes the rlib contain an import library for itself and allows them to both be dynamically and statically linked. However when doing ThinLTO we do not generate these and thus we end up with missing symbols. Microsoft's `link` can fix these up (and emits warnings), but `lld` seems to currently be unable to.

This PR also does this generation for ThinLTO avoiding those issues with `lld` and also avoids the warnings on `link`.

This is an workaround for rust-lang#81408.

cc `@lqd`
@Zoxc Zoxc deleted the thinlto_imp_symbols branch October 12, 2024 00:49
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 7, 2024
unpin and update memchr

I'm unable to build x86_64-pc-windows-gnu Rust due to some weird binutils bug, but thinlto issue seems to be no longer present. Let's give it a go on the CI.
Possibly fixed by rust-lang#129079

try-job: x86_64-mingw
try-job: i686-mingw
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 7, 2024
unpin and update memchr

I'm unable to build x86_64-pc-windows-gnu Rust due to some weird binutils bug, but thinlto issue seems to be no longer present. Let's give it a go on the CI.
Possibly fixed by rust-lang#129079

Fixes rust-lang#127890
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Nov 9, 2024
unpin and update memchr

I'm unable to build x86_64-pc-windows-gnu Rust due to some weird binutils bug, but thinlto issue seems to be no longer present. Let's give it a go on the CI.
Possibly fixed by rust-lang/rust#129079

Fixes #127890
mati865 pushed a commit to mati865/rust that referenced this pull request Nov 12, 2024
unpin and update memchr

I'm unable to build x86_64-pc-windows-gnu Rust due to some weird binutils bug, but thinlto issue seems to be no longer present. Let's give it a go on the CI.
Possibly fixed by rust-lang#129079

Fixes rust-lang#127890
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants