Skip to content
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

Is global.get allowed in element segments? #2201

Closed
TethysSvensson opened this issue Apr 16, 2023 · 2 comments · Fixed by #2288
Closed

Is global.get allowed in element segments? #2201

TethysSvensson opened this issue Apr 16, 2023 · 2 comments · Fixed by #2288

Comments

@TethysSvensson
Copy link

As far as I can tell from the webassembly spec, it should be valid to use the global.get instruction in an element segment.

However I am unable to use wat2wasm on this module

(module
  (import "m" "f" (global funcref))
  (table 0 10 funcref)
  (elem 0 (offset (i32.const 0)) funcref (global.get 0)))

If I try, I get this error:

foo.wat:4:43: error: invalid elem expression expression; must be either ref.null or ref.func.
  (elem 0 (offset (i32.const 0)) funcref (global.get 0)))
                                          ^^^^^^^^^^

If I use the --no-check flag I am able to override the check and generate a resulting .wasm file.

Looking at the generated file in a hexdump, it looks exactly like I would expect it to. However I am unable to get wasm2wat to accept this generated module, even if I use the --no-check flag.

Am I misreading the spec, or is this a bug in wabt?

@TethysSvensson TethysSvensson changed the title Is global.get in element segment? Is global.get allowed in element segments? Apr 16, 2023
@sbc100
Copy link
Member

sbc100 commented Apr 16, 2023

Interesting, that does look like a bug in the support for the reference types proposal, but it also must represent a hole in the spec tests since wabt runs all the spec tests tests for reference types.

@sbc100
Copy link
Member

sbc100 commented Apr 17, 2023

I added a spec test to cover this case, but it will take a bit of work on the wabt side to fix it I think.

keithw added a commit that referenced this issue Aug 30, 2023
This continues the work from #1783 and reduces special handling of elem
exprs, by treating them the same as other const expressions (init
expressions).

Fixes #2201 (now allows global.get in an elem expr)
keithw added a commit that referenced this issue Aug 30, 2023
This continues the work from #1783 and reduces special handling of elem
exprs, by treating them the same as other const expressions (init
expressions).

Fixes #2201 (now allows global.get in an elem expr)
keithw added a commit that referenced this issue Aug 30, 2023
This continues the work from #1783 and reduces special handling of elem
exprs, by treating them the same as other const expressions (init
expressions).

Fixes #2201 (now allows global.get in an elem expr)
keithw added a commit that referenced this issue Aug 31, 2023
This continues the work from #1783 and reduces special handling of elem
exprs, by treating them the same as other const expressions (init
expressions).

Fixes #2201 (now allows global.get in an elem expr)
keithw added a commit that referenced this issue Sep 6, 2023
This continues the work from #1783 and reduces special handling of elem
exprs, by treating them the same as other const expressions (init
expressions).

Fixes #2201 (now allows global.get in an elem expr)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants