[PATCH] D12723: llvm-mc-fuzzer: A fuzzing tool for the MC layer.

Daniel Sanders via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 10 02:30:45 PDT 2015

dsanders marked 3 inline comments as done.

Comment at: tools/llvm-mc-fuzzer/llvm-mc-fuzzer.cpp:62
@@ +61,3 @@
+  uint8_t *DataCopy = new uint8_t[Size];
+  memcpy(DataCopy, Data, Size);
kcc wrote:
> why not vector? 
I didn't give it much thought. I'll switch it to a vector.

Comment at: tools/llvm-mc-fuzzer/llvm-mc-fuzzer.cpp:103
@@ +102,3 @@
+    strcpy(Arg, I.c_str());
+    FuzzerArgv.push_back(Arg);
+  }
kcc wrote:
> Do you really need to copy these here? 
> Why not just pass I.c_str()? 
Unfortunately, yes but there is an alternate solution. The problem is that c_str() returns a const char * but fuzzer::FuzzerDriver() expects an array of char *. It's unsafe to just drop the const-ness so I make a non-const copy.

If fuzzer::FuzzerDriver's second was const char ** then I could avoid the copy.

Comment at: tools/llvm-mc-fuzzer/llvm-mc-fuzzer.cpp:109
@@ +108,3 @@
+  if (Action == AC_Assemble)
+    errs() << "error: -assemble is not implemented\n";
+  else if (Action == AC_Disassemble)
kcc wrote:
> Do you need it to be this complex? 
> For assembling you can write a separate target binary
My thinking was that it would be nice if llvm-mc-fuzzer had a similar command line to llvm-mc. If it's preferred to use a separate binary then I don't mind doing that.


More information about the llvm-commits mailing list