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

aarch64 windows backend forces panic=abort #65313

Closed
jdm opened this issue Oct 11, 2019 · 2 comments · Fixed by #70704
Closed

aarch64 windows backend forces panic=abort #65313

jdm opened this issue Oct 11, 2019 · 2 comments · Fixed by #70704
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-enhancement Category: An issue proposing an enhancement or a PR with one. O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state O-windows-msvc Toolchain: MSVC, Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jdm
Copy link
Contributor

jdm commented Oct 11, 2019

The aarch64-pc-windows-msvc and aarch64-uwp-windows-msvc targets force panic=abort. @alexcrichton said this:

The AArch64 Windows backend didn't implement SEH unwinding when the aarch64-pc-windows-msvc target was first added, so I suspect this is the same as that. I haven't checked the LLVM backend recently to see if this works.

This looks related to #54291, which points at these now-merged LLVM changes:

It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?

@jonas-schievink jonas-schievink added A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-enhancement Category: An issue proposing an enhancement or a PR with one. O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state O-windows-msvc Toolchain: MSVC, Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 11, 2019
@alexcrichton
Copy link
Member

Theoretically the way to fix this issue is:

If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.

@jdm
Copy link
Contributor Author

jdm commented Oct 15, 2019

I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jan 15, 2020
…crichton

Update to a version of cmake with windows arm64 support

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jan 15, 2020
…crichton

Update iovec to a version with no winapi dependency

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jan 15, 2020
…r=alexcrichton

Update libssh2-sys to a version that can build for aarch64-pc-windows…

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jan 15, 2020
…, r=alexcrichton

Better support for cross compilation on Windows.

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.

Without the libpath changes we were trying to link a mix of amd64 and arm64 binaries.

Without the cmake system name change, the llvm build was trying to run an arm64 build tool on the x86_64 build machine.

That said, I haven't tested all different combinations here and am very open to resolving this a different way.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jan 15, 2020
…tins, r=alexcrichton

Update compiler_builtins with changes to fix 128 bit integer remainder for aarch64 windows.

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jan 15, 2020
…, r=alexcrichton

Better support for cross compilation on Windows.

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.

Without the libpath changes we were trying to link a mix of amd64 and arm64 binaries.

Without the cmake system name change, the llvm build was trying to run an arm64 build tool on the x86_64 build machine.

That said, I haven't tested all different combinations here and am very open to resolving this a different way.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jan 15, 2020
…tins, r=alexcrichton

Update compiler_builtins with changes to fix 128 bit integer remainder for aarch64 windows.

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jan 15, 2020
…crichton

Update to a version of cmake with windows arm64 support

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jan 15, 2020
…crichton

Update iovec to a version with no winapi dependency

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jan 15, 2020
…r=alexcrichton

Update libssh2-sys to a version that can build for aarch64-pc-windows…

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jan 15, 2020
…, r=alexcrichton

Better support for cross compilation on Windows.

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.

Without the libpath changes we were trying to link a mix of amd64 and arm64 binaries.

Without the cmake system name change, the llvm build was trying to run an arm64 build tool on the x86_64 build machine.

That said, I haven't tested all different combinations here and am very open to resolving this a different way.
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jan 15, 2020
…tins, r=alexcrichton

Update compiler_builtins with changes to fix 128 bit integer remainder for aarch64 windows.

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
@bors bors closed this as completed in da87316 Apr 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-enhancement Category: An issue proposing an enhancement or a PR with one. O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state O-windows-msvc Toolchain: MSVC, Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants