-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Linker flavors next steps: linker features #123656
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
Some changes occurred in run-make tests. cc @jieyouxu These commits modify compiler targets. |
Let's land it separately, before or after this PR. |
What happens if |
Or maybe not, the rest of the PR is noncontroversial, so I'm basically ready to r+ with #123656 (comment) addressed. |
It's fine, we can land such a thing in the next PRs. I had removed it from my branch already by the time you added the other comment :)
Right now nothing spectacularly amazing, in particular I was thinking whether MCP rust-lang/compiler-team#731 would need to be taken into account. I think we could at least make So I will:
|
0058079
to
a490b17
Compare
Updated to:
@rustbot ready |
/// - when the self-contained linker flag is active: the build of `lld` distributed with rustc, | ||
/// - or any `lld` available to `cc`. | ||
#[instrument(level = "debug", skip(cmd, sess))] | ||
fn add_lld_args( |
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.
There's one more place where the distinction between lld and non-lld is important - fn get_linker
, it will add -flavor <FLAVOR>
to the command line if the linker is lld.
Right now it won't be added even if -Clinker-features=+lld
is specified.
Ideally fn linker_and_flavor
would return a flavor already adjusted for -Clinker-features
, then everything would automatically work correctly after that.
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 that's the case then I'm not sure if we ever had -flavor <FLAVOR>
for -Zgcc-ld=lld
either, anything it did was way after get_linker
, but I guess you may be talking about using -Clinker=lld
directly and not via cc.
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.
-flavor <FLAVOR>
is not needed when lld is called through cc.
It's only needed when lld is called directly, and with an "improper" name not conveying the flavor, e.g. "rust-lld".
They are a flexible complementary mechanism to linker flavors, that also avoid the combinatorial explosion of mapping linking features to actual linker flavors.
but don't expose `+/-cc` yet
While they're isomorphic, we can flip the lld component where applicable, so that downstream doesn't have to check both the flavor and the linker features.
Done. It feels like we'd want some kind of consistency check when features are toggled for flavors that wouldn't support them though: right now such adjustment would be a no op, but maybe we could be emitting errors in some cases. Probably not in all cases though, as the flavor can be inferred and could be wrong. I'll mark this @rustbot ready but I'd like your thoughts on errors here. Maybe we can check for consistency when falling back to the unhinted target flavor. Maybe when we use both a modern linker flavor and the linker features on the CLI, so there's no inference/hinting involved. |
I'll think about the consistency checks later during stabilization. |
☀️ Test successful - checks-actions |
Finished benchmarking commit (7106800): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. 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. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 675.908s -> 677.551s (0.24%) |
This is my understanding of the first step towards @petrochenkov's vision for the future of linker flavors, described in #119906 (comment) and the discussion that followed.
To summarize: having
Cc
andLld
embedded in linker flavors creates tension about naming, and a combinatorial explosion of flavors for each new linker feature we'd want to use. Linker features are an extension mechanism that is complementary to principal flavors, with benefits described in #119906.The most immediate use of this flag would be to turn self-contained linking on and off via features instead of flavors. For example,
-Clinker-features=+/-lld
would toggle using lld instead of selecting a precise flavor, and would be "generic" and work cross-platform (whereas linker flavors are currently more tied to targets). Under this scheme, MCP510 is expected to be-Clink-self-contained=+linker -Zlinker-features=+lld -Zunstable-options
(though for the time being, the original flags using lld-cc flavors still work).I purposefully didn't add or document CLI support for
+/-cc
, as it would be a noop right now. I only expect that we'd initially want to stabilize+/-lld
to begin with.r? @petrochenkov
You had requested that minimal churn would be done to the 230 target specs and this does none yet: the linker features are inferred from the flavor since they're currently isomorphic. We of course expect this to change sooner rather than later.
In the future, we can allow targets to define linker features independently from their flavor, and remove the cc and lld components from the flavors to use the features instead, this actually doesn't need to block stabilization, as we discussed.
(Best reviewed per commit)