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

Fix unwinding on 32-bit watchOS ARM #124494

Merged
merged 1 commit into from
May 5, 2024

Conversation

madsmtm
Copy link
Contributor

@madsmtm madsmtm commented Apr 28, 2024

Found while doing #124491, I wanted to unify the code under target_vendor = "apple", and found that Clang actually specifies that watchOS ARM 32-bit does not use SjLj.

I don't have an Apple Watch from that generation at hand to test this myself (series 1 to 3), and I don't think it will be sufficient to test it in the simulator (as it's architecture-specific), so maybe someone else could do so?

N.B. The code is written in a way to support 32-bit iOS and tvOS ARM devices (which do use SjLj) for future compatibility even though we currently only have a target for 32-bit iOS ARM (if you think that's excessive, then I'll change it).

CC target maintainers @deg4uss3r, @vladimir-ea, @leohowell.
CC @simlay, @thomcc whom might have more insight into this than I.

@rustbot label O-watchos

@rustbot
Copy link
Collaborator

rustbot commented Apr 28, 2024

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. O-watchos Operating System: watchOS labels Apr 28, 2024
@rust-log-analyzer

This comment has been minimized.

The code is written in a way to support 32-bit iOS and tvOS ARM devices,
for future compatibility even though we currently only have a target for
32-bit iOS ARM.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 30, 2024
…ngjubilee

Use `target_vendor = "apple"` instead of `target_os = "..."`

Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`.

The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific.
Note that `target_vendor` will [be deprecated in the future](rust-lang#100343), but not before an alternative (like `target_family = "apple"`) is available.

While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: rust-lang#124494

Since you've talked about using `target_vendor = "apple"` in the past:
r? workingjubilee

CC `@simlay,` `@thomcc`
`@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
bors added a commit to rust-lang-ci/rust that referenced this pull request May 1, 2024
…ngjubilee

Use `target_vendor = "apple"` instead of `target_os = "..."`

Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`.

The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific.
Note that `target_vendor` will [be deprecated in the future](rust-lang#100343), but not before an alternative (like `target_family = "apple"`) is available.

While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: rust-lang#124494

Since you've talked about using `target_vendor = "apple"` in the past:
r? workingjubilee

CC `@simlay,` `@thomcc`
`@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request May 3, 2024
Use `target_vendor = "apple"` instead of `target_os = "..."`

Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`.

The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific.
Note that `target_vendor` will [be deprecated in the future](rust-lang/rust#100343), but not before an alternative (like `target_family = "apple"`) is available.

While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: rust-lang/rust#124494

Since you've talked about using `target_vendor = "apple"` in the past:
r? workingjubilee

CC `@simlay,` `@thomcc`
`@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
@deg4uss3r
Copy link
Contributor

Everything in here looks good to me, approving from the toolchain perspective, but likewise I cannot test as I don't have a device old enough.

@Mark-Simulacrum
Copy link
Member

@bors r+

Looks like this is just affecting tier 3 targets, so going to go ahead and approve.

@bors
Copy link
Contributor

bors commented May 4, 2024

📌 Commit 39dc6c1 has been approved by Mark-Simulacrum

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 May 4, 2024
@bors
Copy link
Contributor

bors commented May 5, 2024

⌛ Testing commit 39dc6c1 with merge 1867f48...

@bors
Copy link
Contributor

bors commented May 5, 2024

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 1867f48 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 5, 2024
@bors bors merged commit 1867f48 into rust-lang:master May 5, 2024
11 checks passed
@rustbot rustbot added this to the 1.80.0 milestone May 5, 2024
@Kobzol
Copy link
Contributor

Kobzol commented May 5, 2024

This PR has been merged by accident, without the full test suite being run. It was my fault (#124631 got merged and it broke our CI). @madsmtm Could you please create a new PR with your branch against the latest version of origin/master? Thank you, and sorry for the mess.

@madsmtm
Copy link
Contributor Author

madsmtm commented May 5, 2024

Sure, I've opened #124748

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request May 5, 2024
…r=Mark-Simulacrum

Fix unwinding on 32-bit watchOS ARM (v2)

This PR is identical to rust-lang#124494, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F).

r? Mark-Simulacrum

Original PR description:

---

Found while doing rust-lang#124491, I wanted to unify the code under `target_vendor = "apple"`, and found that [Clang actually specifies that watchOS ARM 32-bit does not use SjLj](https://github.com/llvm/llvm-project/blob/llvmorg-18.1.4/clang/lib/Driver/ToolChains/Darwin.cpp#L3107-L3119).

I don't have an Apple Watch from that generation at hand to test this myself (series 1 to 3), and I don't think it will be sufficient to test it in the simulator (as it's architecture-specific), so maybe someone else could do so?

N.B. The code is written in a way to support 32-bit iOS and tvOS ARM devices (which do use SjLj) for future compatibility even though we currently only have a target for 32-bit iOS ARM (if you think that's excessive, then I'll change it).

`@rustbot` label O-watchos
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request May 5, 2024
Rollup merge of rust-lang#124748 - madsmtm:fix-32bit-watchos-unwind, r=Mark-Simulacrum

Fix unwinding on 32-bit watchOS ARM (v2)

This PR is identical to rust-lang#124494, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F).

r? Mark-Simulacrum

Original PR description:

---

Found while doing rust-lang#124491, I wanted to unify the code under `target_vendor = "apple"`, and found that [Clang actually specifies that watchOS ARM 32-bit does not use SjLj](https://github.com/llvm/llvm-project/blob/llvmorg-18.1.4/clang/lib/Driver/ToolChains/Darwin.cpp#L3107-L3119).

I don't have an Apple Watch from that generation at hand to test this myself (series 1 to 3), and I don't think it will be sufficient to test it in the simulator (as it's architecture-specific), so maybe someone else could do so?

N.B. The code is written in a way to support 32-bit iOS and tvOS ARM devices (which do use SjLj) for future compatibility even though we currently only have a target for 32-bit iOS ARM (if you think that's excessive, then I'll change it).

`@rustbot` label O-watchos
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Sep 11, 2024
…ingjubilee

Fix linking error when compiling for 32-bit watchOS

In rust-lang#124494 (or rust-lang#124748), I mistakenly conflated "not SjLj" to mean "ARM EHABI", which isn't true, 32-bit watchOS uses a third unwinding method called "DWARF CFI".

So this PR is effectively a revert of rust-lang#124494, with a few more comments explaining what's going on.

Fixes rust-lang#130071.

r? Mark-Simulacrum (since you reviewed the original)
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Sep 11, 2024
…ingjubilee

Fix linking error when compiling for 32-bit watchOS

In rust-lang#124494 (or rust-lang#124748), I mistakenly conflated "not SjLj" to mean "ARM EHABI", which isn't true, 32-bit watchOS uses a third unwinding method called "DWARF CFI".

So this PR is effectively a revert of rust-lang#124494, with a few more comments explaining what's going on.

Fixes rust-lang#130071.

r? Mark-Simulacrum (since you reviewed the original)
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Sep 11, 2024
…ingjubilee

Fix linking error when compiling for 32-bit watchOS

In rust-lang#124494 (or rust-lang#124748), I mistakenly conflated "not SjLj" to mean "ARM EHABI", which isn't true, 32-bit watchOS uses a third unwinding method called "DWARF CFI".

So this PR is effectively a revert of rust-lang#124494, with a few more comments explaining what's going on.

Fixes rust-lang#130071.

r? Mark-Simulacrum (since you reviewed the original)
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Sep 12, 2024
Rollup merge of rust-lang#130077 - madsmtm:watchos-arm-unwind, r=workingjubilee

Fix linking error when compiling for 32-bit watchOS

In rust-lang#124494 (or rust-lang#124748), I mistakenly conflated "not SjLj" to mean "ARM EHABI", which isn't true, 32-bit watchOS uses a third unwinding method called "DWARF CFI".

So this PR is effectively a revert of rust-lang#124494, with a few more comments explaining what's going on.

Fixes rust-lang#130071.

r? Mark-Simulacrum (since you reviewed the original)
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Sep 12, 2024
Fix linking error when compiling for 32-bit watchOS

In rust-lang/rust#124494 (or rust-lang/rust#124748), I mistakenly conflated "not SjLj" to mean "ARM EHABI", which isn't true, 32-bit watchOS uses a third unwinding method called "DWARF CFI".

So this PR is effectively a revert of rust-lang/rust#124494, with a few more comments explaining what's going on.

Fixes rust-lang/rust#130071.

r? Mark-Simulacrum (since you reviewed the original)
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. O-watchos Operating System: watchOS S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants