Consider adding LLVM/Clang support

[RivenSkaye]

So it seems like LLVM supports SEH for both i686 and x86_64 which might even allow for enabling this for use with windows-gnu toolchains, probably by setting the compiler used as clang and linking their libc and libunwind.

I'll do some more digging and experimenting soon and PR if and when I get it to work in the hopes we can get SEH support across toolchains. Some searching does make it seem like GCC has support for at least x86_64 SEH and with the relevant Borland patents for it having expired, we might yet see i686 support as well there!

[sonodima]

This would be a great addition, considering that in the future I would like to explore some way to support exception handling with Posix signals.

MicroSEH could become the only library needed for HW exception handling in Rust, on all the compilers and major OSes.

[RivenSkaye]

Good news from the GCC repos. Seems like both GCC and LLVM support it for at least x86_64 in their standard platform-specific unwind mechanics! At least up to a certain point, but that should also mean they provide the required entries in headers to register our own handler functions.

Do note, though, that "handling" some of these exceptions does not mean the environment is still in a consistent or workable state; so perhaps add a warning to the docs that some should just mean graceful teardown and exit rather than recovery. As for Windows Services, SEH is used for some signaling as well. Including the kind that tells you that your process is about to get nuked.

I think it's reasonable for a crate like this to support only the common use case - that is, for embedded someone will want a much more specific solution and for any desktop/server workload it's reasonable to assume people aren't using 32-bit architectures and OSes anymore

[sonodima]

I think it's reasonable for a crate like this to support only the common use case - that is, for embedded someone will want a much more specific solution and for any desktop/server workload it's reasonable to assume people aren't using 32-bit architectures and OSes anymore

I completely agree, this library was originally just meant to be for Win-MSVC-x64 but I'm okay with adding support for multiple architectures and compilers, as long as they don't require too much effort!

[drishal]

I think it's reasonable for a crate like this to support only the common use case - that is, for embedded someone will want a much more specific solution and for any desktop/server workload it's reasonable to assume people aren't using 32-bit architectures and OSes anymore

I completely agree, this library was originally just meant to be for Win-MSVC-x64 but I'm okay with adding support for multiple architectures and compilers, as long as they don't require too much effort!

is there any possibility for adding support of windows-gnu target?

[sonodima]

is there any possibility for adding support of windows-gnu target?

I think I have seen something about gcc having __try1 and __except1, but honestly I have very little experience with GCC, especially on Windows

[RivenSkaye]

The __try1 and __except1 macros produce pretty different code compared to MSVC's. The main issue with cross compilation is that Windows just tacks on an extra page on the stack for the exception struct to do any handler calls with. GCC's closest option is the alt stack, which you might be able to tell it is right behind the current one, but I'm nit quite sure how well that works. At that point, you might as well look into manually doing the whole handler registration so it works from any compiler

[sonodima]

That's interesting. The main reason I went with wrapping the MSVC SEH implementation was to quickly have support for all the archs supported by Windows.

Writing the handler registration ourselves would also make many of the docsrs build.rs issues we had disappear.

[RivenSkaye]

Writing handler registration manually is a lot of work and we'd be stuck manually writing them for every supported exception type. And then we'd be doing this once for every thread (though if we do that inside try_seh it'll always be the current thread). For some more info take a peek at one of the few resources on the topic. It's a 4 part series that also touches upon why the inline asm mentioned in the README here is such a pain to get working. But Wikipedia by way of WINE provides some useful information as well, if you really want to go down that path.

Though if we can assume these exceptions don't come from the calling and handler-registering frame, which should be the case here because we very explicitly register before doing anything, then LLVM seems to support all we need out of the box already! So we should be able to call the LLVM toolchain for this as well, with -fms-compatibility, and have it Just Work™ for most cases. Emit a compiler warning and call it a day I suppose?
Edit: might be worth mentioning that I have no idea how well this works on cross toolchains. This is specifically for Windows native compilation using a non-MSVC toolchain

[RivenSkaye]

Another update: it seems that at least for 64-bit, MinGW supports SEH ootb. With the patent having expired and more info becoming available, it's looking like GCC might never implement it for x86 though LLVM is now in a working state for both x86 and AMD64. I think the main difference lies in having to call into msvcrt.dll though thanks to modern resources we could just roll our own

[RivenSkaye]

Update from the future:

On Windows hosts using a full MinGW64-based toolchain, Clang support is easy. Make sure the current toolchain has the MSVC target installed and it all magically works so long as you force usage of clang (or clang-cl) and slap on the Windows support flags -fms-extensions -fms-compatibility -fdelayed-template-parsing.

For cross compilation: building the C stub with clang or clang-cl has a hard dependency on using the Windows SDK. This means it might be best to just recommend xwin (or maybe recommend building with cargo-xwin so people have the process automated?) as this seems to work smoothly for both i686 and amd64.

Offering support from within build.rs would require

• duplicating xwin efforts
• basically copying cargo-xwin build processes
• dealing with upstream changes that someone else is already dealing with

I wager just supplying a xwin-build.sh that installs and uses cargo-xwin might be the easiest solution here.