For disassembling binary Wasm modules, I recommend: - Binaryen's wasm-dis (especially if you like "nested s-expression" syntax). See https://github.com/WebAssembly/binaryen#building. - V8's own Wasm Module Inspector, compile it with `tools/dev/gm.py x64.release wami` and see `out/x64.release/wami --help`. It reuses V8's production decoder, so it's guaranteed to provide accurate insight into what V8 thinks those bits mean. I use it, among other things, to investigate cases where it's not immediately clear whether the module is invalid or V8 is decoding it incorrectly.
On Wed, Jul 5, 2023 at 3:52 PM 'Andreas Haas' via v8-dev < v8-dev@googlegroups.com> wrote: > > > On Wed, Jul 5, 2023 at 3:21 PM Sam Parker-Haynes <sam.par...@arm.com> > wrote: > >> Hi, >> >> I'm trying to find a codegen bug in aarch64, so I've been looking at the >> wasm_compile_fuzzer in the hope that it can help me. I have a number of >> questions about the current behaviour of the fuzz target. (sorry in advance >> for the list!) >> >> 1) What set of commands is best to use? I've noticed on the default >> setting a single, constant, instruction is generated and I'm not sure how >> useful that is. I've currently using -len_control=10 to get to the, >> hopefully, juicy stuff quickly. >> > Typically I use `v8_wasm_compile_fuzzer` without parameters. Libfuzzer > should automatically adjust the input size. > >> >> 2) Viewing the generated modules is difficult. I'm using `DumpModule` to >> output any valid module and there seems to be two error types that prevent >> my available tools from working. A common output from the WABT tools is: >> `error: unexpected type form (got -0x30)`. wasm-objdump tries harder but >> then often falls over with `error: expected valid local type`. I'm using >> the latest version of WABT, does anyone know what type(s) the fuzz target >> generates that could cause this issue? >> > > If you compile `v8_simple_wasm_compile_fuzzer` in V8, then you can run it > with `v8_simple_wasm_compile_fuzzer --wasm-fuzzer-gen-test`, which will > generate an mjsunit test that is equivalent to the generated test. > > >> 3) For the modules that I have successfully viewed, I've often noticed >> long chains of the same operation, i32.eqz being a very popular one. Is >> there any explanation for this? In general, I still haven't got my head >> around how the input from libfuzzer is used to generate the module... >> >> The fuzzer builds the module top down. It generates the outermost > instruction randomly, and then generates inputs for the instruction > randomly, but of the correct type. For those inputs it also generates the > inputs of the correct types, and so on. Maybe `i32.eqz` gets generated with > a `0`, which makes it more likely by the fuzzer because the fuzzer > generates long strings of `0`? > > >> 4) Is there any memory attached to the instance when it runs? And if >> there is, there doesn't seem to be an attempt to ensure addresses are in >> range. So, do most of the memory operations just crash the program? The >> differential testing seems to only test that the return of `main` is equal, >> but what about the contents of memory? >> >> A memory is attached, I think there is some logic to prefer useful memory > addresses, but I don't know the details/current state. The fuzzer could > also realize that low memory indices test better, and prefer low indices. > > >> Thanks! >> Sam >> > -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAKSzg3SJMVXxJenbEFT6CDUJPr9ip1Wi%2Brj_MhvD8VxXa1foOg%40mail.gmail.com.
