[PATCH] D30156: llvm-mc-fuzzer: add support for assembly

[Daniel Sanders via Phabricator via llvm-commits]

dsanders added inline comments.


================
Comment at: tools/llvm-mc-disassemble-fuzzer/llvm-mc-disassemble-fuzzer.cpp:78
+int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
+  if (Size < 1024) { return 0; }
+
----------------
kcc wrote:
> why do you limit the size this way? 
> Isn't it useful to run tiny inputs? 
I don't think we should have this limit. When I was testing the Mips disassembler, I found it very useful to limit the fuzzer to 4-bytes of data so that the buffer was always the opcode of the unsupported/broken instruction. I also found a bug in 0-3 byte buffers where it assumed it was safe to read the first instruction and would overflow the buffer.


================
Comment at: tools/llvm-mc-disassemble-fuzzer/llvm-mc-disassemble-fuzzer.cpp:96
+  //
+  // Infinitely fuzz the little-endian MIPS64R2 disassembler with the MSA
+  // feature enabled using up to 64-byte inputs:
----------------
kcc wrote:
> what will be the behavior if no flags are supplied? 
> Can we set the default values so that the fuzzer will do something meaningful w/o any flags?
> 
> Also, if we have the default values as a macro that we can re-define from a cmake flag, 
> this will solve the problem of building multiple binaries . 
> what will be the behavior if no flags are supplied? 
> Can we set the default values so that the fuzzer will do something meaningful w/o any flags?

It will test the default triple from sys::getDefaultTargetTriple(). This is usually the host but it can be set in CMake.

> Also, if we have the default values as a macro that we can re-define from a cmake flag, 
> this will solve the problem of building multiple binaries.

This is partially available through CMake's LLVM_DEFAULT_TARGET_TRIPLE variable. The triple influences the default -mcpu and -mattrs but not all subtargets can be described with just a triple.


Repository:
  rL LLVM

https://reviews.llvm.org/D30156