[PATCH] D70738: [libFuzzer] Add custom output function

Max Moroz via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 9 07:57:05 PST 2019


Dor1s added a comment.

In D70738#1773658 <https://reviews.llvm.org/D70738#1773658>, @Manishearth wrote:

> In D70738#1773624 <https://reviews.llvm.org/D70738#1773624>, @Dor1s wrote:
>
> > If you're running fuzz targets manually, then it makes sense -- you need to type one command less to print the crash input. Although it seems like `cargo fuzz` can do that for you as well, so it will be still a single command.
>
>
> Kind of, `cargo fuzz` doesn't know how to format your code, only the fuzz target (written by the user) does, since `cargo-fuzz` is unaware of the types being used. Due to the way libFuzzer works -- it replaces your main function -- we can't add another code path that just loads the string from a specified file and formats it because no matter what libFuzzer will still be run.


Sorry, I wasn't clear. I mean if you write fuzz targets with the `getenv()` based solution I proposed, `cargo fuzz` can be extended so that it will execute the crashing input with the necessary env variable set. That way we achieve the following:

1. a single `cargo fuzz` command for your users
2. no changes to libFuzzer's public interface
3. instead of defining a new function, users can inject the printing code anywhere under `if getenv()` condition

now I look at this and realize that 3) is even better than having a separate function, e.g. when you initialize a complex object or a protocol packet, you could print it right away from the `LLVMFuzzerTestOneInput`, rather than duplicating / refactoring out data processing code in order to support an additional printing routine.


Repository:
  rCRT Compiler Runtime

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70738/new/

https://reviews.llvm.org/D70738





More information about the llvm-commits mailing list