-
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
Implement unstable -Clinker-flavor=gcc:lld
for MCP 510
#96827
Conversation
|
I suddenly got busy and will get to this PR (and then to #96884) next weekend most likely. |
This comment was marked as resolved.
This comment was marked as resolved.
But that's not a linker flavor, that's literally If that was a linker flavor, then we'd add
to already existing
flavors. If we want to pass strings to EDIT:
And that option already exists on stable and is called |
(I need to reread the zulip thread because I'm starting to forget all of the colors of this shed.) |
☔ The latest upstream changes (presumably #97409) made this pull request unmergeable. Please resolve the merge conflicts. |
Sorry for the delay. |
Update: I'm still against having a free form component in |
☔ The latest upstream changes (presumably #98975) made this pull request unmergeable. Please resolve the merge conflicts. |
only the stable values for `-Clinker-flavor` can be used on stable until we have more feedback on the interface
Rebased.
@petrochenkov I've pushed a separate commit to remove that, and use the existing The two experiments are interesting but look more like general refactorings that don't necessarily impact the CLI for the MCP or prevent from making progress here until stabilization ? (and when they do impact the CLI, this can be seen as breaking changes on stable flags, something that I've avoided) |
-Clinker-flavor=gcc:*
for MCP 510-Clinker-flavor=gcc:lld
for MCP 510
Sorry for the delay. So I wanted to try documenting what "linker flavor" even means. All linkers have some kind of command line interfaces and rustc needs to know which commands to use with each of them. Technically, it's not even necessary, we can nearly always infer the flavor from linker name and target properties like The minimal set of linker flavors could look something like this // Unix-like linker with GNU extensions (both naked and compiler-wrapped forms)
// Besides similar "default" Linux/BSD linkers this also include Windows/GNU, which is somewhat different.
Gnu { cc: bool },
// Basic Unix-like linker, possibly with non-GNU extensions aka "any other Unix" (both naked and compiler-wrapped forms)
// Apple targets, Wasm, Solaris/illumos, l4re, msp430 - very different targets.
// Why this exists separately from GNU - the `linker_is_gnu` target property (which I will include into linker flavor in this post)
// is annoying to infer using other target properties.
Unix { cc: bool },
// MSVC linker has a unique interface
Msvc,
// Other linker-like tools with unique interfaces for exotic targets
EmCc,
Bpf,
Ptx, Then LLD appears (#48125) and real life forces our hand to increase the number of clusters to be a bit less minimal. This changes our set of linker flavors to something like this // Unix-like linker with GNU extensions (both naked and compiler-wrapped forms)
// Besides similar "default" Linux/BSD linkers this also include Windows/GNU, which is somewhat different.
Gnu { lld: bool, cc: bool },
// Unix-like linker for Apple targets (both naked and compiler-wrapped forms)
// Why it was extracted from "umbrella" Unix - due to the corresponding LLD flavor.
Darwin { lld: bool, cc: bool },
// Unix-like linker for Wasm targets (both naked and compiler-wrapped forms)
// Why it was extracted from "umbrella" Unix - due to the corresponding LLD flavor.
// Non-LLD version does not exist, so the lld flag here is currently hardcoded and not boolean.
WasmLld { cc: bool },
// Basic Unix-like linker, possibly with non-GNU extensions aka "any other Unix" (both naked and compiler-wrapped forms)
// Solaris/illumos, l4re, msp430 - very different targets.
// LLD doesn't support any of these.
Unix { cc: bool },
// MSVC linker has a unique interface
// LLD supports it
Msvc { lld: bool },
// Other linker-like tools with unique interfaces for exotic targets
EmCc,
Bpf,
Ptx, Then we could increase the number of clusters even more, e.g. to cover most of conditions in Gnu { lld: bool, cc: bool },
Mingw { lld: bool, cc: bool }, // split from GNU
Darwin { lld: bool, cc: bool },
WasmLld { cc: bool },
Solaris { cc: bool }, // split from Unix
L4Re { cc: bool }, // split from Unix
Unix { cc: bool }, // "other Unix" still needs to exist
Msvc { lld: bool },
EmCc,
Bpf,
Ptx, We can realistically do this, but it may be too much for my taste. It would still not eliminate all the target-specific logic in the rustc_codegen_ssa though. So what conclusions I draw from all of this.
|
I'll review the code in this PR a bit later, I expect that we can mostly land it as is. |
Since the free form component is removed, (*) Although I'd prefer to use the scheme from #96827 (comment) eventually. |
"Using `lld`, self-contained linking, and coverage or profile generation has known \ | ||
issues. See issue #79555 for more details, at \ | ||
https://github.com/rust-lang/rust/issues/79555", | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh.
Is it really a compiler's job to do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same about other cases of copypasting issue tracker into the compiler's source code.
cmd.arg(format!("-Wl,-rustc-lld-flavor={}", sess.target.lld_flavor.as_str())); | ||
} else { | ||
// Otherwise, we were asked to use `lld` but not `rust-lld`. | ||
cmd.arg("-fuse-ld=lld"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this PR should wait for #100200, in addition to fixing the regression it basically makes the "self-contained" and "lld" aspects of -Zgcc-ld
orthogonal and removes useless checks like
// - checking the `lld-wrapper`s exist in the sysroot
above, that check something that is not necessarily true, and will prevent finding system lld instead.
// compile-flags: -Zgcc-ld=lld -Clinker-flavor=em -Zunstable-options | ||
|
||
// Test ensuring that until the unstable flag is removed (if ever), if both the linker-flavor and | ||
// `gcc-ld` flags are used, they ask for the same linker. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If making these two options incompatible helps to remove at least some code or conditions in fn handle_cli_linker_flavors
then please let's do that instead.
rustc_target: Add a compatibility layer to separate internal and user-facing linker flavors I want to do some refactorings in `rustc_target` - merge `lld_flavor` and `linker_is_gnu` into `linker_flavor`, support combination gcc+lld (rust-lang#96827). This PR adds some compatibility infra that makes that possible without making any changes to user-facing interfaces - `-Clinker-flavor` values and json target specs. (For json target specs this infra may eventually go away since they are not very stable.) The second commit does some light refactoring of internal linker flavors (applies changes from petrochenkov@53eca42 that don't require mass-editing target specs).
rustc_target: Add a compatibility layer to separate internal and user-facing linker flavors I want to do some refactorings in `rustc_target` - merge `lld_flavor` and `linker_is_gnu` into `linker_flavor`, support combination gcc+lld (rust-lang#96827). This PR adds some compatibility infra that makes that possible without making any changes to user-facing interfaces - `-Clinker-flavor` values and json target specs. (For json target specs this infra may eventually go away since they are not very stable.) The second commit does some light refactoring of internal linker flavors (applies changes from petrochenkov@53eca42 that don't require mass-editing target specs).
rustc_target: Add a compatibility layer to separate internal and user-facing linker flavors I want to do some refactorings in `rustc_target` - merge `lld_flavor` and `linker_is_gnu` into `linker_flavor`, support combination gcc+lld (rust-lang#96827). This PR adds some compatibility infra that makes that possible without making any changes to user-facing interfaces - `-Clinker-flavor` values and json target specs. (For json target specs this infra may eventually go away since they are not very stable.) The second commit does some light refactoring of internal linker flavors (applies changes from petrochenkov@53eca42 that don't require mass-editing target specs).
rustc_target: Add a compatibility layer to separate internal and user-facing linker flavors I want to do some refactorings in `rustc_target` - merge `lld_flavor` and `linker_is_gnu` into `linker_flavor`, support combination gcc+lld (rust-lang#96827). This PR adds some compatibility infra that makes that possible without making any changes to user-facing interfaces - `-Clinker-flavor` values and json target specs. (For json target specs this infra may eventually go away since they are not very stable.) The second commit does some light refactoring of internal linker flavors (applies changes from petrochenkov@53eca42 that don't require mass-editing target specs).
☔ The latest upstream changes (presumably #101318) made this pull request unmergeable. Please resolve the merge conflicts. |
In accordance with the design from rust-lang#96827 (comment)
rustc_target: Refactor internal linker flavors In accordance with the design from rust-lang#96827 (comment) `lld_flavor` and `linker_is_gnu` fields are removed from internal target specs, but still parsed from JSON specs using compatibility layer introduced in rust-lang#100552. r? `@lqd`
superseded by #112910 |
Implement most of MCP510 This implements most of what remains to be done for MCP510: - turns `-C link-self-contained` into a `+`/`-` list of components, like `-C link-self-contained=+linker,+crto,+libc,+unwind,+sanitizers,+mingw`. The scaffolding is present for all these expected components to be implemented and stabilized in the future on their own time. This PR only handles the `-Zgcc-ld=lld` subset of these link-self-contained components as `-Clink-self-contained=+linker` - handles `-C link-self-contained=y|n` as-is today, for compatibility with `rustc_codegen_ssa::back::link::self_contained`'s [explicit opt-in and opt-out](https://github.com/lqd/rust/blob/9eee230cd0a56bfba3ce65121798d9f9f4341cdd/compiler/rustc_codegen_ssa/src/back/link.rs#L1671-L1676). - therefore supports our plan to opt out of `rust-lld` (when it's enabled by default) even for current `-Clink-self-contained` users, with e.g. `-Clink-self-contained -Clink-self-contained=-linker` - turns `add_gcc_ld_path` into its expected final form, by using the `-C link-self-contained=+linker` CLI flag, and whether the `LinkerFlavor` has the expected `Cc::Yes` and `Lld::Yes` shape (this is not yet the case in practice for any CLI linker flavor) - makes the [new clean linker flavors](rust-lang#96827 (comment)) selectable in the CLI in addition to the legacy ones, in order to opt-in to using `cc` and `lld` to emulate `-Zgcc-ld=lld` - ensure the new `-C link-self-contained` components, and `-C linker-flavor`s are unstable, and require `-Z unstable-options` to be used The up-to-date set of flags for the future stable CLI version of `-Zgcc-ld=lld` is currently: `-Clink-self-contained=+linker -Clinker-flavor=gnu-lld-cc -Zunstable-options`. It's possible we'll also need to do something for distros that don't ship `rust-lld`, but maybe there are already no tool search paths to be added to `cc` in this situation anyways. r? `@petrochenkov`
Implement most of MCP510 This implements most of what remains to be done for MCP510: - turns `-C link-self-contained` into a `+`/`-` list of components, like `-C link-self-contained=+linker,+crto,+libc,+unwind,+sanitizers,+mingw`. The scaffolding is present for all these expected components to be implemented and stabilized in the future on their own time. This PR only handles the `-Zgcc-ld=lld` subset of these link-self-contained components as `-Clink-self-contained=+linker` - handles `-C link-self-contained=y|n` as-is today, for compatibility with `rustc_codegen_ssa::back::link::self_contained`'s [explicit opt-in and opt-out](https://github.com/lqd/rust/blob/9eee230cd0a56bfba3ce65121798d9f9f4341cdd/compiler/rustc_codegen_ssa/src/back/link.rs#L1671-L1676). - therefore supports our plan to opt out of `rust-lld` (when it's enabled by default) even for current `-Clink-self-contained` users, with e.g. `-Clink-self-contained -Clink-self-contained=-linker` - turns `add_gcc_ld_path` into its expected final form, by using the `-C link-self-contained=+linker` CLI flag, and whether the `LinkerFlavor` has the expected `Cc::Yes` and `Lld::Yes` shape (this is not yet the case in practice for any CLI linker flavor) - makes the [new clean linker flavors](rust-lang/rust#96827 (comment)) selectable in the CLI in addition to the legacy ones, in order to opt-in to using `cc` and `lld` to emulate `-Zgcc-ld=lld` - ensure the new `-C link-self-contained` components, and `-C linker-flavor`s are unstable, and require `-Z unstable-options` to be used The up-to-date set of flags for the future stable CLI version of `-Zgcc-ld=lld` is currently: `-Clink-self-contained=+linker -Clinker-flavor=gnu-lld-cc -Zunstable-options`. It's possible we'll also need to do something for distros that don't ship `rust-lld`, but maybe there are already no tool search paths to be added to `cc` in this situation anyways. r? `@petrochenkov`
This PR is extracted from #96401 for easier review.
It implements half of MCP #510: adding a
gcc:lld
linker-flavor on the CLI, as a prerequisite for supportingrust-lld
directly via a command similar to-Clinker-flavor=gcc:lld -Clink-self-contained=linker
.The option is unstable and requires
-Z unstable-options
to be used.When used without
-Clink-self-contained=linker
, it's equivalent to-Clink-arg=-fuse-ld=lld
.r? @petrochenkov