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

It doesn't appear that the data section is being generated for a particular wast file when running run-gen-spec-test.py #256

Closed
saambarati opened this issue Dec 24, 2016 · 4 comments

Comments

@saambarati
Copy link
Contributor

I'm compiling the memory.wast test from the spec to JS code:
https://github.com/WebAssembly/spec/blob/b055d01ea1dfdd7a5231ae779095435f836de97f/interpreter/test/memory.wast

The output I get is this:
https://gist.github.com/saambarati/74490ce6882d121ffd5933f288e9e69d

If you look at the 3rd, 4th, and 5th call to assert_invalid, assert_invalid is called with the same binary. This doesn't appear to contain the "data" section at all; compare it to the .wast file's 3rd, 4th, 5th assert_invalid which does have a data section. I think wabt is miscompiling these.

@saambarati saambarati changed the title It doesn't appear that the data section is being generated when running run-gen-spec-test.py It doesn't appear that the data section is being generated for a particular wast file when running run-gen-spec-test.py Dec 24, 2016
@saambarati
Copy link
Contributor Author

It looks like the code is doing some validation on its own, and failing silently:

I think this line of code (inside binary-writer.c):
if (module->memories.size && module->data_segments.size)

should become:
if (module->data_segments.size)

That said, I'm not sure what the intention of the wabt tool. Is it to do some kind of verification? If so, then this verification should stay in (and perhaps be an error). If the purpose is to translate a (potentially invalid module), then it shouldn't do this verification. My understanding is that the tool should just translate the wast even if it's invalid.

@saambarati
Copy link
Contributor Author

Another place that fails to translate the wast in arbitrary ways:

(assert_invalid
  (module (memory 1) (data (i32.ctz (i32.const 0))))
  "constant expression required"
)

Won't get properly compiled in this loop (because of I think the write_init_expr):

    for (i = 0; i < module->data_segments.size; ++i) {
      const WasmDataSegment* segment = module->data_segments.data[i];
      write_header(ctx, "data segment header", i);
      int memory_index =
          wasm_get_memory_index_by_var(module, &segment->memory_var);
      wasm_write_u32_leb128(&ctx->stream, memory_index, "memory index");
      write_init_expr(ctx, module, segment->offset);
      wasm_write_u32_leb128(&ctx->stream, segment->size, "data segment size");
      write_header(ctx, "data segment data", i);
      wasm_write_data(&ctx->stream, segment->data, segment->size,
                      "data segment data");
    }

@binji
Copy link
Member

binji commented Dec 24, 2016

Good catch!

That said, I'm not sure what the intention of the wabt tool.

Well, the binary writer is one of the older parts of the code. It used to be that wabt was just a text -> binary converter, and it would always validate the module before writing. Now that wabt does a lot more, it makes sense to allow writing invalid modules.

binji added a commit that referenced this issue Dec 24, 2016
The binary writer should write invalid modules. This change allows
writing data/element segments if there is no memory/table segment,
respectively. It also writes the full init_expr, even if that would be
invalid.

Fixes issue #256.
@saambarati
Copy link
Contributor Author

Thanks for the fix. Works for me.

hubot pushed a commit to WebKit/WebKit-http that referenced this issue Dec 29, 2016
…uce certain kinds of invalid modules

https://bugs.webkit.org/show_bug.cgi?id=166491
<rdar://problem/29814999>

Reviewed by Yusuke Suzuki.

Based off these revisions:
- spec: b055d01ea1dfdd7a5231ae779095435f836de97f
- wabt: d0d44702c753f851b094615298a2f4d4e3c21035

The reason for the rebase is that wabt was updated to stop
silently rejecting invalid modules. This was needed because
some of the spec tests check to make sure that the module
is invalid, but wabt was silently ignoring the errors and
generating valid modules:
WebAssembly/wabt#256

* wasm.yaml:
* wasm/spec-tests/address.wast.js:
* wasm/spec-tests/binary.wast.js:
* wasm/spec-tests/block.wast.js:
* wasm/spec-tests/br.wast.js:
* wasm/spec-tests/br_if.wast.js:
* wasm/spec-tests/br_table.wast.js:
* wasm/spec-tests/break-drop.wast.js:
* wasm/spec-tests/call.wast.js:
* wasm/spec-tests/call_indirect.wast.js:
* wasm/spec-tests/comments.wast.js:
* wasm/spec-tests/conversions.wast.js:
* wasm/spec-tests/custom_section.wast.js:
* wasm/spec-tests/endianness.wast.js:
* wasm/spec-tests/exports.wast.js:
* wasm/spec-tests/f32.wast.js:
* wasm/spec-tests/f32_cmp.wast.js:
* wasm/spec-tests/f64.wast.js:
* wasm/spec-tests/f64_cmp.wast.js:
* wasm/spec-tests/fac.wast.js:
* wasm/spec-tests/float_exprs.wast.js:
* wasm/spec-tests/float_literals.wast.js:
* wasm/spec-tests/float_memory.wast.js:
* wasm/spec-tests/float_misc.wast.js:
* wasm/spec-tests/forward.wast.js:
* wasm/spec-tests/func.wast.js:
* wasm/spec-tests/func_ptrs.wast.js:
* wasm/spec-tests/get_local.wast.js:
* wasm/spec-tests/globals.wast.js:
* wasm/spec-tests/i32.wast.js:
* wasm/spec-tests/i64.wast.js:
* wasm/spec-tests/imports.wast.js:
* wasm/spec-tests/int_exprs.wast.js:
* wasm/spec-tests/int_literals.wast.js:
* wasm/spec-tests/left-to-right.wast.js:
* wasm/spec-tests/linking.wast.js:
* wasm/spec-tests/loop.wast.js:
* wasm/spec-tests/memory.wast.js:
* wasm/spec-tests/memory_redundancy.wast.js:
* wasm/spec-tests/memory_trap.wast.js:
* wasm/spec-tests/names.wast.js:
* wasm/spec-tests/nop.wast.js:
* wasm/spec-tests/resizing.wast.js:
* wasm/spec-tests/return.wast.js:
* wasm/spec-tests/select.wast.js:
* wasm/spec-tests/set_local.wast.js:
* wasm/spec-tests/skip-stack-guard-page.wast.js:
* wasm/spec-tests/stack.wast.js:
* wasm/spec-tests/start.wast.js:
* wasm/spec-tests/store_retval.wast.js:
* wasm/spec-tests/switch.wast.js:
* wasm/spec-tests/tee_local.wast.js:
* wasm/spec-tests/traps.wast.js:
* wasm/spec-tests/typecheck.wast.js:
* wasm/spec-tests/unreachable.wast.js:
* wasm/spec-tests/unwind.wast.js:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@210204 268f45cc-cd09-0410-ab3c-d52691b4dbfc
ryanhaddad pushed a commit to WebKit/WebKit that referenced this issue Dec 22, 2020
…uce certain kinds of invalid modules

https://bugs.webkit.org/show_bug.cgi?id=166491
<rdar://problem/29814999>

Reviewed by Yusuke Suzuki.

Based off these revisions:
- spec: b055d01ea1dfdd7a5231ae779095435f836de97f
- wabt: d0d44702c753f851b094615298a2f4d4e3c21035

The reason for the rebase is that wabt was updated to stop
silently rejecting invalid modules. This was needed because
some of the spec tests check to make sure that the module
is invalid, but wabt was silently ignoring the errors and
generating valid modules:
WebAssembly/wabt#256

* wasm.yaml:
* wasm/spec-tests/address.wast.js:
* wasm/spec-tests/binary.wast.js:
* wasm/spec-tests/block.wast.js:
* wasm/spec-tests/br.wast.js:
* wasm/spec-tests/br_if.wast.js:
* wasm/spec-tests/br_table.wast.js:
* wasm/spec-tests/break-drop.wast.js:
* wasm/spec-tests/call.wast.js:
* wasm/spec-tests/call_indirect.wast.js:
* wasm/spec-tests/comments.wast.js:
* wasm/spec-tests/conversions.wast.js:
* wasm/spec-tests/custom_section.wast.js:
* wasm/spec-tests/endianness.wast.js:
* wasm/spec-tests/exports.wast.js:
* wasm/spec-tests/f32.wast.js:
* wasm/spec-tests/f32_cmp.wast.js:
* wasm/spec-tests/f64.wast.js:
* wasm/spec-tests/f64_cmp.wast.js:
* wasm/spec-tests/fac.wast.js:
* wasm/spec-tests/float_exprs.wast.js:
* wasm/spec-tests/float_literals.wast.js:
* wasm/spec-tests/float_memory.wast.js:
* wasm/spec-tests/float_misc.wast.js:
* wasm/spec-tests/forward.wast.js:
* wasm/spec-tests/func.wast.js:
* wasm/spec-tests/func_ptrs.wast.js:
* wasm/spec-tests/get_local.wast.js:
* wasm/spec-tests/globals.wast.js:
* wasm/spec-tests/i32.wast.js:
* wasm/spec-tests/i64.wast.js:
* wasm/spec-tests/imports.wast.js:
* wasm/spec-tests/int_exprs.wast.js:
* wasm/spec-tests/int_literals.wast.js:
* wasm/spec-tests/left-to-right.wast.js:
* wasm/spec-tests/linking.wast.js:
* wasm/spec-tests/loop.wast.js:
* wasm/spec-tests/memory.wast.js:
* wasm/spec-tests/memory_redundancy.wast.js:
* wasm/spec-tests/memory_trap.wast.js:
* wasm/spec-tests/names.wast.js:
* wasm/spec-tests/nop.wast.js:
* wasm/spec-tests/resizing.wast.js:
* wasm/spec-tests/return.wast.js:
* wasm/spec-tests/select.wast.js:
* wasm/spec-tests/set_local.wast.js:
* wasm/spec-tests/skip-stack-guard-page.wast.js:
* wasm/spec-tests/stack.wast.js:
* wasm/spec-tests/start.wast.js:
* wasm/spec-tests/store_retval.wast.js:
* wasm/spec-tests/switch.wast.js:
* wasm/spec-tests/tee_local.wast.js:
* wasm/spec-tests/traps.wast.js:
* wasm/spec-tests/typecheck.wast.js:
* wasm/spec-tests/unreachable.wast.js:
* wasm/spec-tests/unwind.wast.js:


Canonical link: https://commits.webkit.org/183767@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@210204 268f45cc-cd09-0410-ab3c-d52691b4dbfc
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

No branches or pull requests

2 participants