-
Notifications
You must be signed in to change notification settings - Fork 839
More fuzz fixes #1095
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
More fuzz fixes #1095
Changes from all commits
cf6c4cf
485166f
26b2f33
b85e8b5
f755250
29cf873
00dd3b9
9792a40
908a74b
7bc2ed7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -217,7 +217,7 @@ struct WasmValidator : public PostWalker<WasmValidator> { | |
|
|
||
| void validateAlignment(size_t align, WasmType type, Index bytes, bool isAtomic, | ||
| Expression* curr); | ||
| void validateMemBytes(uint8_t bytes, WasmType ty, Expression* curr); | ||
| void validateMemBytes(uint8_t bytes, WasmType type, Expression* curr); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Heh... I seem to have absorbed LLVM's aversion to using 'type' in variable names. |
||
| void validateBinaryenIR(Module& wasm); | ||
| }; | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -237,14 +237,17 @@ void WasmValidator::visitAtomicRMW(AtomicRMW* curr) { | |
| void WasmValidator::visitAtomicCmpxchg(AtomicCmpxchg* curr) { | ||
| validateMemBytes(curr->bytes, curr->type, curr); | ||
| } | ||
| void WasmValidator::validateMemBytes(uint8_t bytes, WasmType ty, Expression* curr) { | ||
| void WasmValidator::validateMemBytes(uint8_t bytes, WasmType type, Expression* curr) { | ||
| if (type == unreachable) { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does unreachable type mean the node is allowed to be completely invalid? How does this sort of thing arise?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Stuff like (as before, this is normally removed by dce, but i was fuzzing with dce disabled on purpose)
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, but this function validates the immediate bytes field, not the pointer. Regardless of what's in the pointer, a load with a bogus size should never happen. I guess we have to fix the comparison based on the type size to handle unreachable, but it still seems wrong to allow a totally different value for size. Can we remove the early-return and mabye use
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the core issue here is that we use the type when we do This is actually an issue with printing such a load as well, we print
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right, that's why I suggested
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, we could check for 5-byte loads etc. Would still need an explicit unreachable check though. I'll make a PR. |
||
| return; // nothing to validate in this case | ||
| } | ||
| switch (bytes) { | ||
| case 1: | ||
| case 2: | ||
| case 4: | ||
| break; | ||
| case 8: { | ||
| shouldBeEqual(getWasmTypeSize(ty), 8U, curr, "8-byte mem operations are only allowed with 8-byte wasm types"); | ||
| shouldBeEqual(getWasmTypeSize(type), 8U, curr, "8-byte mem operations are only allowed with 8-byte wasm types"); | ||
| break; | ||
| } | ||
| default: fail("Memory operations must be 1,2,4, or 8 bytes", curr); | ||
|
|
||
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.
Do we want to remove all the unreachable concrete elements at the tail? Why just one?
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.
this change to this pass is just to make it correct - it's trying to merge blocks, and it's not valid to do so without removing a value flowing out on the final element (because it becomes a non-final element after the merge).
it's also worth removing all the unreachable elements, the dce pass does that (this bug was only noticeable by fuzzing this pass directly, without running all opts, where dce would have run)