Stream: git-wasmtime

Topic: wasmtime / PR #1742 [WIP] Add support for Windows x32 ABI

Wasmtime GitHub notifications bot (May 21 2020 at 19:53):

whitequark opened PR #1742 from windows-x32-abi to master:

As it stands the patch in this PR is as minimal as it is hair-raising, and it's really not going to be merged in the current state. However, with it and #1740 I can actually run simple programs on x32!

(The -Cpanic=abort, plus a dummy #[no_mangle] pub extern fn _Unwind_Resume() { unimplemented!() }, are there to work around the fact that Linux distributions all build MinGW with SjLj exceptions, but Rust expects a MinGW toolchain with DWARF exceptions.)

Let me explain the reasons this PR looks like it does.

First, currently target-lexicon considers Windows as always using fastcall. However that's not the case on x32, where C code uses cdecl by default, and Win32 APIs use stdcall by default. This is why Windows x32 is special-cased in cranelift in this PR. To fix this, I believe that default_calling_convention for Windows x32 should return cdecl so that it matches the behavior of the Rust c calling convention, but that's where we get to the second issue...

Second, there is actually no way to express "Windows cdecl" in either target-lexicon or cranelift. AFAICT this calling convention is functionally identical to the System V one; LLVM calls it ccc to avoid naming it in either a *nix-specific way ("System V") or a Windows-specific way ("cdecl"). The way this should be handled is purely subjective though (the options being "rename SystemV to Ccc", "rename SystemV to Cdecl", "add Cdecl as an alias of SystemV for Windows alone", and "do nothing and just use SystemV on Windows x32") so I'm going to implement whatever the maintainers ask me to.

Wasmtime GitHub notifications bot (May 21 2020 at 21:23):

whitequark updated PR #1742 from windows-x32-abi to master:

As it stands the patch in this PR is as minimal as it is hair-raising, and it's really not going to be merged in the current state. However, with it and #1740 I can actually run simple programs on x32!

(The -Cpanic=abort, plus a dummy #[no_mangle] pub extern fn _Unwind_Resume() { unimplemented!() }, are there to work around the fact that Linux distributions all build MinGW with SjLj exceptions, but Rust expects a MinGW toolchain with DWARF exceptions.)

Let me explain the reasons this PR looks like it does.

First, currently target-lexicon considers Windows as always using fastcall. However that's not the case on x32, where C code uses cdecl by default, and Win32 APIs use stdcall by default. This is why Windows x32 is special-cased in cranelift in this PR. To fix this, I believe that default_calling_convention for Windows x32 should return cdecl so that it matches the behavior of the Rust c calling convention, but that's where we get to the second issue...

Second, there is actually no way to express "Windows cdecl" in either target-lexicon or cranelift. AFAICT this calling convention is functionally identical to the System V one; LLVM calls it ccc to avoid naming it in either a *nix-specific way ("System V") or a Windows-specific way ("cdecl"). The way this should be handled is purely subjective though (the options being "rename SystemV to Ccc", "rename SystemV to Cdecl", "add Cdecl as an alias of SystemV for Windows alone", and "do nothing and just use SystemV on Windows x32") so I'm going to implement whatever the maintainers ask me to.

Wasmtime GitHub notifications bot (Jun 25 2020 at 18:49):

alexcrichton edited PR #1742 from windows-x32-abi to main:

As it stands the patch in this PR is as minimal as it is hair-raising, and it's really not going to be merged in the current state. However, with it and #1740 I can actually run simple programs on x32!

(The -Cpanic=abort, plus a dummy #[no_mangle] pub extern fn _Unwind_Resume() { unimplemented!() }, are there to work around the fact that Linux distributions all build MinGW with SjLj exceptions, but Rust expects a MinGW toolchain with DWARF exceptions.)

Let me explain the reasons this PR looks like it does.

First, currently target-lexicon considers Windows as always using fastcall. However that's not the case on x32, where C code uses cdecl by default, and Win32 APIs use stdcall by default. This is why Windows x32 is special-cased in cranelift in this PR. To fix this, I believe that default_calling_convention for Windows x32 should return cdecl so that it matches the behavior of the Rust c calling convention, but that's where we get to the second issue...

Second, there is actually no way to express "Windows cdecl" in either target-lexicon or cranelift. AFAICT this calling convention is functionally identical to the System V one; LLVM calls it ccc to avoid naming it in either a *nix-specific way ("System V") or a Windows-specific way ("cdecl"). The way this should be handled is purely subjective though (the options being "rename SystemV to Ccc", "rename SystemV to Cdecl", "add Cdecl as an alias of SystemV for Windows alone", and "do nothing and just use SystemV on Windows x32") so I'm going to implement whatever the maintainers ask me to.

Wasmtime GitHub notifications bot (Oct 21 2020 at 06:00):

whitequark closed without merge PR #1742.

Last updated: Dec 23 2024 at 13:07 UTC