rustc_codegen_cranelift
                                
                                
                                
                                    rustc_codegen_cranelift copied to clipboard
                            
                            
                            
                        Tracking issue for abi-checker failures
Todo: add list of all failures. See https://github.com/bjorn3/rustc_codegen_cranelift/pull/1255
STATUS_ACCESS_VIOLATION for MSVC on pair rustc_calls_cgclif:
generating bool::c::rustc_calls_rustc
compiling  bool::c::rustc_calls_rustc
running    bool::c::rustc_calls_rustc
error: process didn't exit successfully: `target\debug\abi-checker.exe --pairs cgclif_calls_rustc --add-rustc-codegen-backend cgclif:C:\Users\Afonso\CLionProjects\rustc_codegen_cranelift\build\bin\rus
tc_codegen_cranelift.dll` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)
Discovered in #1255 (and possibly #1249)
I've been investigating this, and I think this is related to missing stack probes. I don't understand why this wasn't triggering earlier, since some tests did show up as completed.
This crashes on the first stack access that is "far" away (about 0x17D70 bytes away from the last stack write).
It doesn't even call the first test function, it crashes allocating some stack for it.
If I isolate the tests down to just calling convention "c" and the "bool" test suite it crashes. And if i isolate it down to just "f32" and calling convention "c" it starts crashing as well (which it didn't while running in y.exe, but we may have had some more leeway there due to previous stack usage?).
I confirmed this by doing a sort of stack probe before starting the test, I just allocated a 256k array in stack and wrote to it from bottom to top, and the tests now pass!
With this fix the entire ABI suite passes, for all calling conventions (that we test)!
I think a nice way of fixing this properly would be to work on https://github.com/bytecodealliance/wasmtime/issues/2299 and solve it that way. Its a really nice coincidence that this ended up being related to missing stack probes, since I've been wanting to enable inline stack probing for a while
Right, I believe on Windows the stack is almost completely unmapped, but still reserved, by default and you need to hit the guard page for windows to grow the stack. Still interesting that stack probes are mandatory on Windows. I never would have thought of that.
I think a nice way of fixing this properly would be to work on https://github.com/bytecodealliance/wasmtime/issues/2299 and solve it that way. Its a really nice coincidence that this ended up being related to missing stack probes, since I've been wanting to enable inline stack probing for a while
:heart:
Updated to Cranelift 0.87.0 in https://github.com/bjorn3/rustc_codegen_cranelift/commit/b14c7337db5861288afc3b26ba006859ed052d39.
The latest Cranelift update realigns the 128bit int abi with cg_llvm.