Add support for link-flavor rust-lld for iOS, tvOS and watchOS by marysaka · Pull Request #98771 · rust-lang/rust (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation20 Commits1 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

marysaka

This adds support for rust-lld for Apple *OS targets.

This was tested against targets aarch64-apple-ios and aarch64-apple-ios-sim with a simple test program.

It currently doesn't work with targets armv7-apple-ios and armv7s-apple-ios because of symbols.o not being generated with the correct CPU subtype. This will require changes in the object crate to expose an API.

As ld64.lld requires -platform_version with the minimal version supported and an sdk version, I made rustc_target::apple_base public to get access to *os_deployment_target helper functions and also added tvos_deployment_target as it was missing.

@rustbot rustbot added the T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

label

Jul 1, 2022

@rust-highfive

@rust-highfive

@compiler-errors

@petrochenkov

Sorry for the delay, I should be able to review this some time this week.

@petrochenkov

@Thog
Any logic that cannot fail is supposed to go to target definitions in rustc_target.
That's why the *_deployment_target are currently private - they are used from rustc_target and that's enough.

Only get_apple_sdk_root really needs to be delayed until link time.
(Even the pre-existing cmd.args(&["-target", llvm_target]) and cmd.args(&["-arch", arch_name]) are misplaced and can be moved to rustc_target, I think.)

@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

Aug 1, 2022

@marysaka

@Thog Any logic that cannot fail is supposed to go to target definitions in rustc_target. That's why the *_deployment_target are currently private - they are used from rustc_target and that's enough.

Only get_apple_sdk_root really needs to be delayed until link time. (Even the pre-existing cmd.args(&["-target", llvm_target]) and cmd.args(&["-arch", arch_name]) are misplaced and can be moved to rustc_target, I think.)

@rustbot author

I was not sure where to put that part initially, I will address this hopefully this week 👍

@marysaka

@petrochenkov

After a quick look it seems that ios_llvm_target, ios_sim_llvm_target and watchos_sim_llvm_target are used for iOS and watchOS simulator target definitions.

However, at the time of writing arm64_32-apple-watchos and arm64-apple-tvos doesn't select the llvm target with the deployment target.

Should I change those definitions in this PR to make them conform to watchos_deployment_target and tvos_deployment_target respectively?

@petrochenkov

@Thog
I'm not sure, I'm more familiar with the compiler infrastructure around rustc_target than with details of Apple targets specifically.
You can ping people who added those targets, or maybe PRs adding those targets have some answers.

@marysaka

@petrochenkov I did a refactoring of the linker arguments as suggested and rebased. However, the unit tests that you introduced with #98212 are failing here.

As I understand it, the test checks that the flavor of every LinkArg match the linker_flavor of the target. That's unwanted here as I'm targeting ld.64 specifically and result on a failure.

Shouldn't this actually check that at least one flavor match the linker_flavor?

@Thog I'm not sure, I'm more familiar with the compiler infrastructure around rustc_target than with details of Apple targets specifically. You can ping people who added those targets, or maybe PRs adding those targets have some answers.

I think I will try to handle those changes in a separated PR later

@petrochenkov

The unit test needs to be updated, to something like

--- a/compiler/rustc_target/src/spec/tests/tests_impl.rs +++ b/compiler/rustc_target/src/spec/tests/tests_impl.rs @@ -46,7 +46,10 @@ fn check_consistency(&self) { ) } (LinkerFlavor::Gcc, LldFlavor::Ld64) => {

This case just didn't occur previously.

@marysaka

@rustbot label -S-waiting-on-author +S-waiting-on-review

@rustbot rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

and removed S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

Aug 3, 2022

petrochenkov

@petrochenkov

Could you also squash commits into one after addressing the comments?
@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

Aug 3, 2022

@marysaka

This adds support for rust-lld for Apple *OS targets.

This was tested against targets "aarch64-apple-ios" and "aarch64-apple-ios-sim".

For targets "armv7-apple-ios" and "armv7s-apple-ios", it doesn't link because of "symbols.o" not being generated with the correct CPU subtype (changes in the "object" crate needs to be done to support it).

@marysaka

@rustbot label -S-waiting-on-author +S-waiting-on-review

@rustbot rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

and removed S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

Aug 3, 2022

@petrochenkov

@bors

📌 Commit 78bbe57 has been approved by petrochenkov

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

Aug 3, 2022

bors added a commit to rust-lang-ci/rust that referenced this pull request

Aug 4, 2022

@bors

…iaskrgr

Rollup of 6 pull requests

Successful merges:

Failed merges:

r? @ghost @rustbot modify labels: rollup

wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request

Oct 11, 2022

@he32

Pkgsrc changes:

Upstream changes:

Version 1.64.0 (2022-09-22)

Language

Compiler

Libraries

Stabilized APIs

These types were previously stable in std::ffi, but are now also available in core and alloc:

These types were previously stable in std::os::raw, but are now also available in core::ffi and std::ffi:

These APIs are now usable in const contexts:

Cargo

Misc

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request

Nov 16, 2022

@he32

Pkgsrc changes:

Upstream changes:

Version 1.64.0 (2022-09-22)

Language

Compiler

Libraries

Stabilized APIs

These types were previously stable in std::ffi, but are now also available in core and alloc:

These types were previously stable in std::os::raw, but are now also available in core::ffi and std::ffi:

These APIs are now usable in const contexts:

Cargo

Misc

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

Labels

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.