Skip to content

Implement return_call_ref, ref.as_non_null, br_on_[non_]null instructions #2567

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

zherczeg
Copy link
Contributor

Depends on #2562

Another 1000 lines addition. Depends on the previous work. Currently implements 3 opcodes, but I might add the remaining opcode (return_call_ref).

@sbc100
Copy link
Member

sbc100 commented Mar 20, 2025

Which proposal are these instruction part of?

@zherczeg
Copy link
Contributor Author

Thank you for checking the patch.

These are the instructions:
https://github.com/WebAssembly/function-references/blob/main/proposals/function-references/Overview.md#instructions-1

I am working on function references phase 5 proposal at the moment, which is requirement for the (latest) GC proposal. The work is split into two parts:

#2562 adds the concepts of (ref ...) and (ref null ...) to many parts of the engine. The big change is that references has an extra argument, and the code needs to handle these non primitive types.

This patch adds the instructions from the proposal.

This is the generic testsuite, also used by wabt:
https://github.com/WebAssembly/testsuite/tree/main/proposals/function-references

My aim is to make all test pass in this directory.

@zherczeg zherczeg changed the title Implement ref.as_non_null, br_non_null, br_on_non_null instructions Implement return_call_ref, ref.as_non_null, br_on_[non_]null instructions Mar 21, 2025
@zherczeg zherczeg force-pushed the more_instructions branch 2 times, most recently from 92898bd to bce48df Compare March 21, 2025 07:10
@zherczeg zherczeg marked this pull request as ready for review March 21, 2025 07:21
@zherczeg
Copy link
Contributor Author

zherczeg commented Mar 21, 2025

What can I do with this test on s390x:

- test/spec/function-references/return_call_ref.txt
    TIMEOUT

The test is also slow on x86. It does a lot of recursion. I did not write the test, it is a spec test.

@SoniEx2
Copy link
Collaborator

SoniEx2 commented Mar 21, 2025

you might be able to add ;;; SLOW: to it. hopefully that gives it enough time to run.

@zherczeg zherczeg force-pushed the more_instructions branch from bce48df to 758858b Compare March 21, 2025 13:24
@zherczeg
Copy link
Contributor Author

Great idea! Thanks it worked!

@zherczeg zherczeg force-pushed the more_instructions branch from 758858b to ef7290e Compare April 5, 2025 06:02
@zherczeg
Copy link
Contributor Author

zherczeg commented Apr 5, 2025

This patch is also updated. It is top of #2571 / #2562 It is a large patch, but easy to review.
Still missing: tables with initializers. I plan to do it like globals, since a table in theory is a global with multiple elements. The initializers returns with the default element.

@zherczeg zherczeg force-pushed the more_instructions branch 2 times, most recently from 1184506 to 10500a7 Compare April 25, 2025 06:07
@zherczeg
Copy link
Contributor Author

zherczeg commented Apr 25, 2025

Ok the fuzzer using this patch found another issue in the code, which is not related to this patch.

Example code:
(module (global $a i32 (i32.const -2)) )

The compiled code is

0000000: 0061 736d                                 ; WASM_BINARY_MAGIC
0000004: 0100 0000                                 ; WASM_BINARY_VERSION
; section "Global" (6)
0000008: 06                                        ; section code
0000009: 00                                        ; section size (guess)
000000a: 01                                        ; num globals
000000b: 7f                                        ; i32
000000c: 00                                        ; global mutability
000000d: 41                                        ; i32.const
000000e: 7e                                        ; i32 literal
000000f: 0b                                        ; end
0000009: 06                                        ; FIXUP section size

With a hexeditor I changed the 0x41 (i32.const) to 0x11 (call_indirect). Then I run objdump:

wasm-objdump: .../wabt/wabt/src/binary-reader-objdump.cc:661: void wabt::{anonymous}::BinaryReaderObjdumpDisassemble::LogOpcode(const char*, ...): Assertion `in_function_body' failed.

The reason is that init expressions are not validated by objdump. If I change 0x41 to 0x45 (i32.eqz), there is no crash, since the in_function_body is not checked by simple opcodes. But this code has an assert check for whatever reason.

What shall we do?

@zherczeg
Copy link
Contributor Author

My suggestion: I suspect objdump does not validate the code intentionally, just dumps it. Then validation related sanity checks does not make sense, so maybe setting in_function_body to true even for init expressions is a valid solution.

sbc100 pushed a commit that referenced this pull request Apr 25, 2025
Fixes the fuzzer bug in #2567

I noticed all objdump logs are guarded by `if (!in_function_body)`. The
code crashes without this check.
@zherczeg zherczeg force-pushed the more_instructions branch 2 times, most recently from ec09f77 to 69054bf Compare April 28, 2025 04:57
@zherczeg zherczeg force-pushed the more_instructions branch 3 times, most recently from 13fc7b7 to d03887c Compare May 8, 2025 10:29
@zherczeg zherczeg force-pushed the more_instructions branch 3 times, most recently from 2c092e7 to 126985f Compare May 14, 2025 07:54
@zherczeg zherczeg force-pushed the more_instructions branch 2 times, most recently from ab7cd3c to c652aee Compare May 22, 2025 03:14
Zoltan Herczeg added 2 commits May 22, 2025 04:42
Support named references for globals, locals, tables, elems
Support named references for call_ref, ref_null
Extend Var variables with an optional type field
@zherczeg zherczeg force-pushed the more_instructions branch from c652aee to 5855654 Compare May 22, 2025 05:01
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 this pull request may close these issues.

3 participants