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

[Brian Cain via Phabricator via llvm-commits]

bcain 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; }
+
----------------
dsanders wrote:
> 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.
Agreed: this was an error, I was experimenting and I will remove it.


================
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:
----------------
dsanders wrote:
> 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.
>> 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.

I believe Kostya was referring to building the set of all dis/assemblers.  I think archs are available in CMake -- we could use that to iterate over, but I think what we really need are the set of all triples.  And I suspect that there is no such facility.


Repository:
  rL LLVM

https://reviews.llvm.org/D30156