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

rustc_target: Refactor internal linker flavors #101988

Merged
merged 1 commit into from
Oct 7, 2022

Conversation

petrochenkov
Copy link
Contributor

In accordance with the design from #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 #100552.
r? @lqd

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 18, 2022
@rust-highfive
Copy link
Collaborator

⚠️ Warning ⚠️

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 18, 2022
@bors

This comment was marked as resolved.

@lqd
Copy link
Member

lqd commented Sep 22, 2022

(I've already started looking at this and will finish this weekend)

Copy link
Member

@luqmana luqmana left a comment

Choose a reason for hiding this comment

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

Woo! Thanks for starting to untangle the mess! Looks good overall, a couple small comments

compiler/rustc_target/src/spec/mod.rs Outdated Show resolved Hide resolved
| LinkerFlavor::Darwin(Cc::Yes, _)
| LinkerFlavor::WasmLld(Cc::Yes)
| LinkerFlavor::Unix(Cc::Yes) => LinkerFlavorCli::Gcc,
LinkerFlavor::Gnu(_, Lld::Yes) => LinkerFlavorCli::Lld(LldFlavor::Ld),
Copy link
Member

Choose a reason for hiding this comment

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

Explicit Cc::No here since that's what we want here semantically vs "anything"? Makes it a little more resilient in-case the match arms get moved around in the future. Similarly for Darwin.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That applies to Lld::No too, so you'd have to fill in all the redundant info in variants below to stay consistent. My initial thought was to not fill the redundant info to make it shorter and do not distract attention from the "important" part.

compiler/rustc_target/src/spec/mod.rs Show resolved Hide resolved
} else if stem == "lld" || stem == "rust-lld" {
LinkerFlavor::Lld(sess.target.lld_flavor)
let lld_flavor = sess.target.linker_flavor.lld_flavor();
LinkerFlavor::from_cli(LinkerFlavorCli::Lld(lld_flavor), &sess.target)
} else {
Copy link
Member

Choose a reason for hiding this comment

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

Given we already have cases for ld.lld, lld-link and wasm-ld is there any reason not to have one for ld64.lld as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just didn't change any logic here, the linker name heuristic can be improved in multiple ways, e.g. accounting for cc and c++/g++/clang++ as well.

Copy link
Member

Choose a reason for hiding this comment

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

Yea, that was just a small thing I noticed while reading through that bit. More for completeness sake since I don't think i've seen any complaints about that case missing

LinkerFlavor::WasmLld(Cc::No)
} else if stem == "ld" || stem.ends_with("-ld") {
LinkerFlavor::from_cli(LinkerFlavorCli::Ld, &sess.target)
} else if stem == "ld.lld" {
Copy link
Member

Choose a reason for hiding this comment

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

Come to think of it, does this case even work as expected? file_stem on ld.lld would return ld meaning we never take this branch.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's reachable if it full file name was ld.lld.exe :)

Copy link
Member

Choose a reason for hiding this comment

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

True but you'd think ld.lld is a lot more common than ld.lld.exe 😛

Copy link
Contributor Author

@petrochenkov petrochenkov Sep 24, 2022

Choose a reason for hiding this comment

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

Not impossible though!

we@we-pc MINGW64 ~
$ where ld.lld
C:\msys64\mingw64\bin\ld.lld.exe

compiler/rustc_target/src/spec/wasm32_wasi.rs Outdated Show resolved Hide resolved
compiler/rustc_target/src/spec/wasm64_unknown_unknown.rs Outdated Show resolved Hide resolved
Copy link
Member

@lqd lqd left a comment

Choose a reason for hiding this comment

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

OK that was a mouthful. It's unfortunate that lld is forcing our hand to make things more complex, but they're also sometimes simpler/clearer than today with the new explicitness (albeit also more verbose).

I left a couple comments in addition to Luqman's (and an if that needs clarification or fixing), and with these done: r=me after rebase.

compiler/rustc_target/src/spec/mod.rs Outdated Show resolved Hide resolved
compiler/rustc_target/src/spec/mod.rs Show resolved Hide resolved
compiler/rustc_codegen_ssa/src/back/link.rs Outdated Show resolved Hide resolved
compiler/rustc_target/src/spec/wasm32_wasi.rs Outdated Show resolved Hide resolved
@lqd
Copy link
Member

lqd commented Sep 28, 2022

(Note that Github duplicated comments added to existing conversations when it posted the review, so they lost the context of what they're replying to, but that's present in the original conversations...)

@lqd
Copy link
Member

lqd commented Sep 28, 2022

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 28, 2022
@petrochenkov
Copy link
Contributor Author

@bors r=lqd

@bors
Copy link
Contributor

bors commented Oct 5, 2022

📌 Commit 708874a7f704c5f6e85cb65a4ba488d03ea5603d has been approved by lqd

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 5, 2022
@bors
Copy link
Contributor

bors commented Oct 5, 2022

⌛ Testing commit 708874a7f704c5f6e85cb65a4ba488d03ea5603d with merge 2a0993ab9e0963429b6f47804e74f8975ef0ea08...

@bors

This comment was marked as resolved.

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 6, 2022
@rust-log-analyzer

This comment was marked as resolved.

@petrochenkov
Copy link
Contributor Author

Fixed an access to unsynchronized json fields in LinkerFlavor::from_cli.
@bors r=lqd

@bors
Copy link
Contributor

bors commented Oct 6, 2022

📌 Commit 572b6a9 has been approved by lqd

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 6, 2022
@bors
Copy link
Contributor

bors commented Oct 7, 2022

⌛ Testing commit 572b6a9 with merge cf0fa76...

@bors
Copy link
Contributor

bors commented Oct 7, 2022

☀️ Test successful - checks-actions
Approved by: lqd
Pushing cf0fa76 to master...

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (cf0fa76): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This 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.

mean1 range count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
2.3% [2.1%, 2.5%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.1% [-4.4%, -2.2%] 3
All ❌✅ (primary) - - 0

Cycles

This benchmark run did not return any relevant results for this metric.

Footnotes

  1. the arithmetic mean of the percent change

  2. number of relevant changes

@yuriks
Copy link
Contributor

yuriks commented Oct 8, 2022

I believe that this change has broken the parsing of pre-link-args in custom json targets:

PS C:\Users\yuriks\projects\mkos> rustc +nightly-2022-10-07 -Z unstable-options --target ..\rust-bootloader\x86_64-bootloader.json --print target-spec-json
{
  "arch": "x86_64",
  "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128",
  "disable-redzone": true,
  "features": "-mmx,-sse,+soft-float",
  "linker": "rust-lld",
  "linker-flavor": "ld.lld",
  "llvm-target": "x86_64-unknown-none-gnu",
  "panic-strategy": "abort",
  "pre-link-args": {
    "ld.lld": [
      "--script=linker.ld",
      "--gc-sections",
      "--some-invalid-argument"
    ]
  },
  "relocation-model": "static",
  "target-pointer-width": "64"
}
PS C:\Users\yuriks\projects\mkos> rustc +nightly-2022-10-08 -Z unstable-options --target ..\rust-bootloader\x86_64-bootloader.json --print target-spec-json
{
  "arch": "x86_64",
  "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128",
  "disable-redzone": true,
  "features": "-mmx,-sse,+soft-float",
  "linker": "rust-lld",
  "linker-flavor": "ld.lld",
  "llvm-target": "x86_64-unknown-none-gnu",
  "panic-strategy": "abort",
  "relocation-model": "static",
  "target-pointer-width": "64"
}

I am unable to bisect the breakage down to a specific commit, but this is the only that changed relevant parts of the compiler between the two nightlies, and it seems that this change in particular would cause this breakage:

LinkerFlavor::Gnu(_, Lld::Yes)
| LinkerFlavor::Darwin(_, Lld::Yes)
| LinkerFlavor::Msvc(Lld::Yes) => {}

cf0fa76#diff-aa810a3be0834da891b171a8b04b09d0d3bbb76ac27c757cd232235099e062d2R1742

Is this intentional? If so, what's the new way of passing custom linker arguments via the target?

@petrochenkov
Copy link
Contributor Author

@yuriks
No, the breakage is not intentional, this PR was supposed to keep backward compatibility with old target specs, I'll check what happens.

@petrochenkov
Copy link
Contributor Author

@yuriks
Fixed in #102836.

JohnTitor added a commit to JohnTitor/rust that referenced this pull request Oct 12, 2022
rustc_target: Fix json target specs using LLD linker flavors in link args

Fixes rust-lang#101988 (comment) (a regression introduced by rust-lang#101988).
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Oct 13, 2022
rustc_target: Fix json target specs using LLD linker flavors in link args

Fixes rust-lang#101988 (comment) (a regression introduced by rust-lang#101988).
Andy-Python-Programmer added a commit to Andy-Python-Programmer/aero that referenced this pull request Oct 27, 2022
Revert to using latest nightly as the rust toolchain since the blocker issue
(rust-lang/rust#101988 (comment)) has
been resolved.

Signed-off-by: Andy-Python-Programmer <andypythonappdeveloper@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.

9 participants