Skip to content

Tracking issue for abi-checker failures #1261

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bjorn3 opened this issue Aug 13, 2022 · 4 comments
Closed

Tracking issue for abi-checker failures #1261

bjorn3 opened this issue Aug 13, 2022 · 4 comments
Labels
A-abi Area: ABI handling C-bug Category: This is a bug.

Comments

@bjorn3
Copy link
Member

bjorn3 commented Aug 13, 2022

Todo: add list of all failures. See https://github.com/bjorn3/rustc_codegen_cranelift/pull/1255

@bjorn3 bjorn3 added C-bug Category: This is a bug. A-abi Area: ABI handling labels Aug 13, 2022
@afonso360
Copy link
Contributor

afonso360 commented Aug 18, 2022

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 bytecodealliance/wasmtime#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

@bjorn3
Copy link
Member Author

bjorn3 commented Aug 18, 2022

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 bytecodealliance/wasmtime#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

❤️

@bjorn3
Copy link
Member Author

bjorn3 commented Aug 22, 2022

Updated to Cranelift 0.87.0 in bjorn3@b14c733.

@bjorn3
Copy link
Member Author

bjorn3 commented Apr 22, 2024

The latest Cranelift update realigns the 128bit int abi with cg_llvm.

@bjorn3 bjorn3 closed this as completed Apr 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-abi Area: ABI handling C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

2 participants