-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Convert TrapCode
to a single byte
#9338
Convert TrapCode
to a single byte
#9338
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! A few nitpicks inline below.
// This is the default trap code, so don't print anything extra | ||
// for this. | ||
Some(TrapCode::HeapOutOfBounds) => {} | ||
Some(TrapCode::HEAP_OUT_OF_BOUNDS) => {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated to this PR, but it seems like we should print heap oob traps, since it is possible to not have any traps...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lack of trap though prints as notrap
, so I think we're good?
This commit refactors the representation of `cranelift_codegen::ir::TrapCode` to be a single byte. The previous enumeration is replaced with an opaque byte-sized structure. Previous variants that Cranelift uses internally are now associated `const` values on `TrapCode` itself. For example `TrapCode::IntegerOverflow` is now `TrapCode::INTEGER_OVERFLOW`. All non-Cranelift traps are now removed and exclusively live in the `wasmtime-cranelift` crate now. The representation of a `TrapCode` is now: * 0 - invalid, used in `MemFlags` for "no trap code" * 1..256-N - user traps * 256-N..256 - built-in Cranelift traps (it uses N of these) This enables embedders to have 255-N trap codes which is more than enough for Wasmtime for example. Cranelift reserves a few built-in codes for itself which shouldn't eat too much into the trap space. Additionally if Cranelift needs to grow a new trap it can do so pretty easily too. The overall intent of this commit is to reduce the coupling of Wasmtime and Cranelift further and generally refactor Wasmtime to use user traps more often. This additionally shrinks the size of `TrapCode` for storage in various locations, notably it can now infallibly be represented inside of a `MemFlags`. Closes bytecodealliance#9310
0712b62
to
cd1d0e3
Compare
This commit fixes an issue found on OSS-Fuzz for the cranelift-fuzzgen fuzzer which was caused by bytecodealliance#9338 but that PR forgot to fix.
This commit fixes an issue found on OSS-Fuzz for the cranelift-fuzzgen fuzzer which was caused by #9338 but that PR forgot to fix.
This commit refactors the representation of
cranelift_codegen::ir::TrapCode
to be a single byte. The previous enumeration is replaced with an opaque byte-sized structure. Previous variants that Cranelift uses internally are now associatedconst
values onTrapCode
itself. For exampleTrapCode::IntegerOverflow
is nowTrapCode::INTEGER_OVERFLOW
. All non-Cranelift traps are now removed and exclusively live in thewasmtime-cranelift
crate now.The representation of a
TrapCode
is now:MemFlags
for "no trap code"This enables embedders to have 255-N trap codes which is more than enough for Wasmtime for example. Cranelift reserves a few built-in codes for itself which shouldn't eat too much into the trap space. Additionally if Cranelift needs to grow a new trap it can do so pretty easily too.
The overall intent of this commit is to reduce the coupling of Wasmtime and Cranelift further and generally refactor Wasmtime to use user traps more often. This additionally shrinks the size of
TrapCode
for storage in various locations, notably it can now infallibly be represented inside of aMemFlags
.Closes #9310