Use inline asm for Windows instead of external assembly

[mmastrac]

The external assembly files for aarch64 Windows (aarch64_armasm.asm and the GAS fallback aarch_aapcs64.s) are problematic when cross-compiling from non-Windows hosts: MASM isn't available, and the GAS fallback doesn't receive the necessary preprocessor defines when cc-rs detects an MSVC compiler.

To simplify Windows support, we can just move to inline asm for all the supported platforms - they don't actually support stack switching anyways. x86_64 and aarch64 are ported, but i686's switching code is left as a placeholder (32-bit windows might die off before someone has a chance to get it working...).

There were a few clang-cl matrix jobs that were failing because of deprecated i686 support in msys. They are no longer an issue because we're just using asm! for that platform and could be removed.

Ideally we'd use naked on the SP functions but the MSRV is too high for that. Instead we make them inline(always). I don't believe that the exact SP is required, regardless of this.

I added nostack on the sp-reader function because that seems to be correct:

nostack: The assembly code does not push data to the stack, or write to the stack red-zone (if supported by the target). If this option is not used then the stack pointer is guaranteed by the compiler at the start of the assembly code to be suitably aligned (according to the target ABI) for a function call.

Fixes #143

[nagisa]

I'm not 100% keen on this specific approach. At the very least I believe the implementation should be using global_asm rather than inline assembly for some things. I explored global inline assembly to an extent in #77 and while I do think it would be an improvement, I believe it has to be approached as a rule rather than as an exception.

[mmastrac]

That's a fair point - global_asm! would give us exact behavior for stack_pointer (no prologue/epilogue concern) without needing #[naked], and would be a cleaner match for the external assembly semantics.

The inline asm approach here was pragmatic (solving a cross-compilation blocker), but I agree it's better as a comprehensive migration.

Our current blocker is solved by using a temporary fork to work around the issue so we wouldn't be in a rush to land this. If you'd like I can specifically chop out pieces from #77 and have you review them (maybe one platform at a time) and gradually move towards a global_asm! approach?

I've got some bandwidth to assist with this, so let me know what the most effective way might be (or if you'd like to discuss more directly than GH comments)!

EDIT: Also, given the low-level nature of the crate, bumping the MSRV for this crate might be an interesting discussion to have before that.

[nagisa]

EDIT: Also, given the low-level nature of the crate, bumping the MSRV for this crate might be an interesting discussion to have before that.

This set of crates is first and foremost built for the purposes of rustc, so MSRV for this crate is what rustc needs, which is basically the current beta. We can definitely opt even for unstable features (although I'd do that under a feature flag.)

---

I've got some bandwidth to assist with this, so let me know what the most effective way might be (or if you'd like to discuss more directly than GH comments)!

I don't really have the bandwidth currently to keep a super close attention to this effort, mostly just a bit of time to review changes on some of the weekends. In that sense a larger PR that encompasses more of the stuff at once would be better.

Fortunately, it seems like there are potentially easy first steps forward with global_asm! at least. The migration could be a relatively straightforward "copy .s contents into `global_asm!", and leave everything else intact and that should be mostly it for the first stab at it, right?

We can explore fancier improvements such as specific ways to construct the stack_pointer function with inline assembly such that it remains precise as follow-ups.