Damian Heaton (Aug 23 2022 at 14:47): Damian Heaton (Aug 23 2022 at 14:47):Hey,
As far as I can tell, there's no current infrastructure set up to allow us to assert that instructions should trap during specific runtests - is this correct, or is there something I'm not aware of?
If this is the case, do we have existing plans to introduce such infrastructure, since it currently limits testing instructions to valid inputs only (with no way of identifying cases were an instruction accepts values outside its range incorrectly)? This would be useful for (for example) some of the fcvt* instructions.
Afonso Bordado (Aug 23 2022 at 14:54):As far as I can tell, there's no current infrastructure set up to allow us to assert that instructions should trap during specific runtests - is this correct, or is there something I'm not aware of?
I think we only support == and != in run tests (see: https://github.com/bytecodealliance/wasmtime/blob/418dbc15bd2a5269b338587661387e05fc77b983/cranelift/reader/src/run_command.rs#L40-L50)
If this is the case, do we have existing plans to introduce such infrastructure, since it currently limits testing instructions to valid inputs only (with no way of identifying cases were an instruction accepts values outside its range incorrectly)? This would be useful for (for example) some of the fcvt* instructions.
I don't think there are plans for adding this currently, but it would be awesome. I have to add manual tests to the interpreter whenever I need to test a trap (this happened in a sdiv by 0 case).
Afonso Bordado (Aug 23 2022 at 15:06):Although currently we use the JIT to run runtests, does the jit handle catching traps and trapcodes properly? cc @bjorn3
bjorn3 (Aug 23 2022 at 15:07):No, it doesn't.
Afonso Bordado (Aug 23 2022 at 15:07):well, that makes things more difficult
bjorn3 (Aug 23 2022 at 15:07):You directly call the jitted code without any wrapper that catches signals or anything.
Chris Fallin (Aug 23 2022 at 15:34):@Damian Heaton we kind of get reasonable coverage in most trapping cases via the Wasm testing route: the Wasm suite can assert that a call will trap (and is able to do so because it has all of Wasmtime's trap-handling machinery available). So I don't see this as a huge gaping hole that needs to be plugged right away, though of course it would be really nice to be able to test at the CLIF level with runtests as well. If someone were to build something in the cranelift-jit / runtest environment for this I'd be happy to review it
Andrew Brown (Aug 23 2022 at 16:09):Yeah, if there's a Wasm-to-CLIF lowering for whatever instruction we want to test, we could write a WebAssembly test (*.wast) that asserts a trap and add it to tests/misc_testsuite.
Last updated: Dec 23 2024 at 13:07 UTC