panicked at 'singlepass can't emit SUB S64 GPR(X6) GPR(X6) Imm32(4)' #2959
Comments
|
That's a good point. |
Merged
bors bot
added a commit
that referenced
this issue
Jun 22, 2022
2966: Singlepass nopanic r=ptitSeb a=ptitSeb # Description Removed all panic from singlepass compiler, and implemented Result for error handling. The compiler will now return a CompileError instead of a panic when an opcode is missing or more generalt when something goes wrong in the compiler. This partly address ticket #2959 Also, tested the compiler performances with the method expalined here: https://wasmer.io/posts/wasmer-2.2 and found no speed change (good job rustc compiler) Co-authored-by: ptitSeb <[email protected]>
bors bot
added a commit
that referenced
this issue
Jun 22, 2022
2967: Fix singlepass on arm64 that was trying to emit a sub opcode with a constant as destination (for #2959) r=epilys a=ptitSeb # Description Fix singlepass/machine_arm64 that was trying to emit a sub opcode with a constant as destination (for #2959) Co-authored-by: ptitSeb <[email protected]>
|
So, wasmer should not panic anymore when something goes wrong with singlepass compiler, and also, the bug should be fixed. |
Great work. Thanks a lot. I'll try it soon. |
It works now. Thanks very much! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Wasmer panics while loading my module under an M1 MacBook.
It seems like wasmer would panic if the given wasm byte codes were not well-formed or some instructions were not supported.
This should return
CompileErrorrather than panic. Otherwise, the untrusted wasm code could DoS attack the host Application.The text was updated successfully, but these errors were encountered: