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 target specifications related to Windows and UEFI #71030

Merged
merged 9 commits into from
Apr 15, 2020

Conversation

petrochenkov
Copy link
Contributor

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

@rust-highfive
Copy link
Collaborator

r? @varkor

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 11, 2020
@petrochenkov
Copy link
Contributor Author

r? @nagisa
cc @mati865 @Amanieu because Windows/GNU
cc @retep998 because Windows/MSVC
cc @chouquette because UWP
cc @dvdhrm because UEFI

@rust-highfive rust-highfive assigned nagisa and unassigned varkor Apr 11, 2020
Copy link
Contributor

@mati865 mati865 left a 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.

src/librustc_target/spec/windows_uwp_gnu_base.rs Outdated Show resolved Hide resolved
@@ -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`.
Copy link
Contributor

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,
Copy link
Contributor

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!

Copy link
Contributor Author

@petrochenkov petrochenkov Apr 12, 2020

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.

src/librustc_target/spec/msvc_base.rs Show resolved Hide resolved
],
);
pre_link_args.insert(LinkerFlavor::Msvc, pre_link_args_msvc.clone());
pre_link_args.insert(LinkerFlavor::Lld(LldFlavor::Link), pre_link_args_msvc);
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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!

@bors
Copy link
Contributor

bors commented Apr 12, 2020

☔ The latest upstream changes (presumably #71031) made this pull request unmergeable. Please resolve the merge conflicts.

// 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(),
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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.

@nagisa
Copy link
Member

nagisa commented Apr 12, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Apr 12, 2020

📌 Commit 1c04d33b7505bff06bbf12313865f903c7982498 has been approved by nagisa

@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 Apr 12, 2020
@bors
Copy link
Contributor

bors commented Apr 13, 2020

☔ The latest upstream changes (presumably #71023) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 13, 2020
The differences if they are discovered will need to be explicitly documented
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.
@petrochenkov
Copy link
Contributor Author

@bors r=nagisa

@bors
Copy link
Contributor

bors commented Apr 13, 2020

📌 Commit 8392e47 has been approved by nagisa

@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 Apr 13, 2020
Centril added a commit to Centril/rust that referenced this pull request Apr 15, 2020
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.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 15, 2020
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
@bors bors merged commit ffafd15 into rust-lang:master Apr 15, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Nov 13, 2020
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`
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Nov 13, 2020
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``
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Nov 14, 2020
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```
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 14, 2020
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`
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants