Fix cross-compiling i686-pc-windows-gnu from Linux

[neersighted]

This is still very rough and serves as a proof-of-concept for fixing the Linux -> 32-bit MinGW cross compilation workflow. Currently, clang and GCC's MinGW targets both only support DW2 (DWARF) or SJLJ (Set Jump Long Jump) unwinding on 32-bit Windows.

The default for GCC (and the way it is shipped on every major distro) is to use SJLJ on Windows, as DWARF cannot traverse non-DWARF frames. This would work fine, except for the fact that libgcc (our C runtime on the MinGW platform) exports symbols under a different name when configured to use SJLJ-style unwinding, and uses a preprocessor macro internally to alias them.

Because of this, we have to detect this scenario and link to the correct symbols ourselves.

This serves as a proof of concept, and has been tested with a full bootstrap and test suite run on both x86_64-unknown-linux-gnu and i686-pc-windows-gnu, as well as cross-compilation of some of my own projects.

Obviously, the detection is a bit unrefined. Right now we unconditionally use SJLJ when compiling Linux -> 32-bit MinGW. I'd like to add feature detection using compiler build flags or autotools-style compilation and object analysis. Input on the best way to proceed here is welcome.

Also, currently there is copy-pasted/duplicated code in libunwind. Ideally, this could be reduced, but this would likely require a rethinking of how iOS is special-cased above, to avoid further duplication. Input on how to best structure this file is requested.

Resolves #32859

r? @alexcrichton

[neersighted]

I've also removed a reduced, copy-pasted version of cfg_if! that appears to predate the full (still copy-pasted) version in this crate. I'm not sure what the convention is with stdlib dependencies. Would adding a dependency on cfg_if! as published in Cargo be acceptable, or do we wish to avoid such dependencies in the stdlib?

[alexcrichton]

Hm does this produce working binaries in the sense that destructors are run? I'd expect that because LLVM isn't doing setjmp/longjmp whenever you panicked you'd skip destructors, right?

[bors]

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

[emilyalbini]

Thank you for this PR @neersighted! @alexcrichton asked some questions, could you answer them soon? Also, there are some conflicts that needs to be resolved.

[neersighted]

Apologies for the delay here. Yeah, on further review, conditionals probably need to be revised for the personality function. I'll follow up once I can test those changes in a few days.

[emilyalbini]

Ping from triage @neersighted! Will you have some time to work on this again in the near future?

[neersighted]

After some more testing, I've discovered this approach will not work with Rust as-shipped, as the pre-compiled stdlib binaries shipped to rustup are compiled on their native platforms. With the way Rust is currently distributed, I don't think fixing this will be possible at the moment (until Xargo functionality is merged into Cargo, most likely).