-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 target specifications related to Windows and UEFI #71030
Conversation
r? @varkor (rust_highfive has picked a reviewer for you, use r? to override) |
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.
Gnu part looks OK.
@@ -1,6 +1,9 @@ | |||
use crate::spec::{LinkArgs, LinkerFlavor, TargetOptions}; | |||
|
|||
pub fn opts() -> TargetOptions { | |||
let base = super::windows_gnu_base::opts(); | |||
|
|||
// FIXME: Consider adding `-nostdlib` and inheriting from `windows_gnu_base`. |
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.
Yeah, this probably doesn't work great right now.
There is only one prebuilt C toolchain that advertises UWP support but it cannot be easily tested until LLD can link Rust...
// FIXME: This should likely be `true` inherited from `msvc_base` | ||
// because UEFI follows Windows ABI and uses PE/COFF. | ||
// The `false` is probably causing ABI bugs right now. | ||
is_like_msvc: false, |
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.
I am not even sure what these two are supposed to mean. They show up in the rustc code all over the place, but there is no real explanation to what they exactly control. When I wrote the UEFI target, I checked all their usages and was quite sure they do not effect any behavior on UEFI. However, checking again now, either their usage has increased or I missed some places back them.
I guess we should set them to true? I am quite certain that either way we will end up with code not meant for UEFI (either now or in the future when someone picks that option to toggle one more knob).
Regardless, I think it is independent of your PR. So I am definitely fine with adding these 2 comments. Thanks a lot for digging through 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.
They show up in the rustc code all over the place, but there is no real explanation to what they exactly control.
is_like_msvc
and is_like_windows
are some ad-hoc flags controlling target-dependent behavior (introduced in #16156, #25350).
Sometimes it may mean "uses Windows ABI", sometimes "the produced executable is PE/COFF", sometimes "search libraries in directories specific to visual studio", or something else like "uses PDB as debuginfo".
I'm not sure all of these aspects apply to UEFI, so enabling them may both fix something and break something.
These flags likely need to be split into multiple more specific flags, but nobody bothered to do it yet because we had only windows-msvc and windows-gnu targets until recently.
], | ||
); | ||
pre_link_args.insert(LinkerFlavor::Msvc, pre_link_args_msvc.clone()); | ||
pre_link_args.insert(LinkerFlavor::Lld(LldFlavor::Link), pre_link_args_msvc); |
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.
I am really unsure what this commit does. Can you explain? Your commit message says Make sure lld-link is treated as link.exe by default
, which I don't understand. What is wrong with lld-link
? You can compile with lld-link
on linux machines just fine, no need for link.exe
.
Also, here you add support for MSVC-linking, right? Can you explain how this is related to this commit? I think it looks correct, but I am quite a bit lost with these changes. Sorry.
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.
The goal of this commit is to make sure that if something can be linked with link.exe
then it can be linked with lld-link
as well, and vice versa (assuming good enough LLD's feature-parity with link.exe
).
UEFI was one of the targets that supported linking with lld-link
but not with link.exe
for no good reason.
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.
Right, that makes sense. Looks good! Thanks!
☔ The latest upstream changes (presumably #71031) made this pull request unmergeable. Please resolve the merge conflicts. |
ec5383b
to
1c04d33
Compare
// Non-standard subsystems have no default entry-point in PE+ files. We have to define | ||
// one. "efi_main" seems to be a common choice amongst other implementations and the | ||
// spec. | ||
"/entry:efi_main".to_string(), |
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.
Hmm, FWIW the #[start]
function still generates main
symbol for the entry point.
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.
But appears to be pre-existing, so nvmd.
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.
/entry
specifies the binary entry point which main
is not.
@bors r+ |
📌 Commit 1c04d33b7505bff06bbf12313865f903c7982498 has been approved by |
☔ The latest upstream changes (presumably #71023) made this pull request unmergeable. Please resolve the merge conflicts. |
The differences if they are discovered will need to be explicitly documented
as much as possible.
The old naming is from ancient times when there was no MSVC support. Also `uefi_base` -> `uefi_msvc_base`. It will inherit from `msvc_base` in a future commit, plus a GNU UEFI target is also potentially possible.
and inherit both `windows_msvc_base` and `uefi_msvc_base` from it.
1c04d33
to
8392e47
Compare
@bors r=nagisa |
📌 Commit 8392e47 has been approved by |
rustc_target: Refactor target specifications related to Windows and UEFI - LLD support is improved. - Code is cleaned up. - Target specs are organized in a more hierarchical way. - Possible issues in UWP and UEFI platforms are identified (see FIXMEs). The code is better read per-commit.
Rollup of 4 pull requests Successful merges: - rust-lang#70891 (unit rvalue, use constant `()` instead of tuple) - rust-lang#71030 (rustc_target: Refactor target specifications related to Windows and UEFI) - rust-lang#71100 (Miri: expand frame hooks) - rust-lang#71116 (Entirely remove `DUMMY_HIR_ID`) Failed merges: r? @ghost
rustc_target: Mark UEFI targets as `is_like_windows`/`is_like_msvc` And document what `is_like_windows` and `is_like_msvc` actually mean in more detail. Addresses FIXMEs left from rust-lang#71030. r? `@nagisa`
rustc_target: Mark UEFI targets as `is_like_windows`/`is_like_msvc` And document what `is_like_windows` and `is_like_msvc` actually mean in more detail. Addresses FIXMEs left from rust-lang#71030. r? ``@nagisa``
rustc_target: Mark UEFI targets as `is_like_windows`/`is_like_msvc` And document what `is_like_windows` and `is_like_msvc` actually mean in more detail. Addresses FIXMEs left from rust-lang#71030. r? ```@nagisa```
rustc_target: Mark UEFI targets as `is_like_windows`/`is_like_msvc` And document what `is_like_windows` and `is_like_msvc` actually mean in more detail. Addresses FIXMEs left from rust-lang#71030. r? `@nagisa`
The code is better read per-commit.