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.
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?
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...
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?
Thanks!Sam--
--
v8-dev mailing list
v8-...@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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/2ad6b36e-9a5b-4dba-9d76-abb2e95d9f58n%40googlegroups.com.
Andreas Haas
Software Engineer
Google Germany GmbH
Erika-Mann-Straße 33
80636 München
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.
This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAELSTvcdk2Kng_R9u4qn-eyEtr4if66k0zwQYSJ9SxXVCaNbmg%40mail.gmail.com.
Matthias Liedtke
Software Engineer
Google Germany GmbH
Erika-Mann-Straße 33
80636 München
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.
Thanks all, I will try those other disassemblers. I wanted to use --wasm-fuzzer-gen-test but it seems I can't do that when running the proper fuzzer instance - and I just want to dump out a load of generated cases for inspection.Could you point me to where the memory is added? I'm still unfamiliar with the API and all I can find is this which, naively, suggests there isn't any and I'd like to inspect it.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/6ecf0e1f-6040-4264-9fee-4409574f9895n%40googlegroups.com.
Google Germany GmbH
Erika-Mann-Straße 33
80636 München
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Ah, thanks! Using wami, I now also see a memory in the module.From my limited viewing of the code, the huge offsets that are generated for the memory operations look suspicious. I will try to get some concrete numbers for successful accesses vs traps.For analysing the memory afterwards, I was hoping that memcmp would be fast enough... With the current setup, of only checking the return from main, it would suggest there could be many paths that don't affect the result.
But now I'm wondering in how many cases the target would generate a store - if we're generating the inputs, how many instructions require a 'void' input?
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/6bc78704-adce-4c7d-9842-2ee2e9344cf5n%40googlegroups.com.