Skip to content

Fix checking of ref.func index declarations #1894

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.

Sign up for GitHub

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

Jump to bottom
Merged
sbc100 merged 2 commits into from
Apr 13, 2022
Merged

Fix checking of ref.func index declarations #1894

sbc100 merged 2 commits into from
Apr 13, 2022

Conversation

@takikawa
Copy link
Contributor

@takikawa takikawa commented Apr 12, 2022

The validation was overly strict for ref.func index uses. In the spec, the ref index just needs to appear in

the set of function indices occurring in the module, except in its functions or start function.

(https://webassembly.github.io/spec/core/valid/modules.html#valid-module)

which includes uses in the global and export sections. There were some test failures in the spec tests that were fixed by this, so the PR also changes test expectations.

Fixes issue #1893

@takikawa
Fix checking of ref.func index declarations
22c2b65 
The validation was overly strict for ref.func index uses. In the spec,
the ref index just needs to appear in

  "the set of function indices occurring in the module, except in its
   functions or start function."

which includes uses in the global and export sections.

Fixes issue WebAssembly#1893
@keithw
Copy link
Member

keithw commented Apr 12, 2022

This looks right to me (you may have seen #1888 where I tried to work around this).

What do you think about https://github.com/WebAssembly/wabt/blob/main/test/spec/unreached-valid.txt , which seems to be the other test with failed validation?

@keithw keithw requested review from kripken and sbc100 April 12, 2022 22:41
sbc100
sbc100 approved these changes Apr 12, 2022
View reviewed changes
Copy link
Member

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this. I do wonder if we are lacking in test coverage (in the spec repo) given that the overall number of passing/failing tests stayed the same here (only the specific outout text changed).

@takikawa
Copy link
Contributor Author

takikawa commented Apr 13, 2022

What do you think about https://github.com/WebAssembly/wabt/blob/main/test/spec/unreached-valid.txt , which seems to be the other test with failed validation?

The problem there seems to be that the validation semantics of br_table was not totally clear (see WebAssembly/relaxed-dead-code-validation#4) and had been revised in 2021. I think in any case, wabt should change to implement the current algorithm in https://webassembly.github.io/spec/core/appendix/algorithm.html#validation-of-opcode-sequences for br_table, which only checks that the current stack matches each target, rather than that all targets have equal type.

@takikawa
Copy link
Contributor Author

takikawa commented Apr 13, 2022

Thanks for working on this. I do wonder if we are lacking in test coverage (in the spec repo) given that the overall number of passing/failing tests stayed the same here (only the specific outout text changed).

Thanks for the feedback, I think I've addressed the comments.

Re: tests, I think the issue here is that a spec test command like (module ...) that doesn't assert anything and just checks that the module parses/validates doesn't currently count as a pass/fail test case for the wabt spec test runner.

@sbc100
Copy link
Member

sbc100 commented Apr 13, 2022

Thanks for working on this. I do wonder if we are lacking in test coverage (in the spec repo) given that the overall number of passing/failing tests stayed the same here (only the specific outout text changed).

Thanks for the feedback, I think I've addressed the comments.

Re: tests, I think the issue here is that a spec test command like (module ...) that doesn't assert anything and just checks that the module parses/validates doesn't currently count as a pass/fail test case for the wabt spec test runner.

OK, that sounds like maybe something we should fix but is not related to this change.

Are you saying that if wabt can fail to validate such a (module ...) and that won't case a test failure? That sounds like something we should fix.

@sbc100 sbc100 merged commit d08b0d9 into WebAssembly:main Apr 13, 2022
@keithw keithw mentioned this pull request Apr 13, 2022
Closed
@takikawa
Copy link
Contributor Author

takikawa commented Apr 13, 2022

Are you saying that if wabt can fail to validate such a (module ...) and that won't case a test failure? That sounds like something we should fix.

Right, because just a (module ...) on its own won't count as a test case. It will just have the stderr printout.

Just adding a TallyCommand here might solve this: https://github.com/WebAssembly/wabt/blob/main/src/tools/spectest-interp.cc#L1277 (and then many spec test expecations would need to be updated)

@takikawa takikawa mentioned this pull request Apr 13, 2022
Closed
@keithw keithw mentioned this pull request Apr 13, 2022
Merged
@keithw
Copy link
Member

keithw commented Apr 13, 2022

#1895 is my attempt to address this with the smallest possible change (bombing out on error instead of adding TallyCommand and updating all tests).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@sbc100 sbc100 sbc100 approved these changes

@kripken kripken Awaiting requested review from kripken

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@takikawa @keithw @sbc100