Conversation
So, this can definitely work without changes to libfuzzer itself, as it is written today. There are a couple pieces to it: 1. Don't compile `FuzzerMain.cpp` at all; 2. Use `LLVMFuzzerRunDriver` defined in `FuzzerDriver.cpp` to kick off the fuzzing process in the macro. I think with those and something like the `inventory` crate we also open ourselves to having interface that's more like `libtest`. That said, `LLVMFuzzerRunDriver` requires `argc` and `argv`, which at that point requires one to manually convert them back into C layout from `std::env::args_os`. I also don't believe this change is meaningful as is, without an otherwise major rework of the libfuzzer API. It doesn't achieve anything much as it is, and only serves to complicate the implementation of libfuzzer crate itself.
|
(it doesn't build right now because there are some changes wrt visibility within macro, which I didn't consider a good expenditure of time, given the other observations) |
|
Returning to this, I think it might be worthwhile to do this. Among other things that this can enable is e.g. an ability to specify certain fuzzing-related parameters within the test case itself. So e.g. they could specify sensible defaults for the fuzz target from within the source. |
|
I think you can make this available without breaking the existing libfuzzer crate API by splitting the crate into two parts. One crate links in the "no-main" version of libFuzzer (which is apparently a standard build configuration these days). That crate should just export bindings to functions like The other crate exposes the current I'm not actually sure how that would work. I had C-compatible |
|
Alternatively, you can apply the strategy of #106 and feature-gate the linkage. |
So, this can definitely work without changes to libfuzzer itself, as it
is written today. There are a couple pieces to it:
FuzzerMain.cppat all;LLVMFuzzerRunDriverdefined inFuzzerDriver.cppto kick offthe fuzzing process in the macro.
I think with those and something like the
inventorycrate we also openourselves to having interface that's more like
libtest.That said,
LLVMFuzzerRunDriverrequiresargcandargv, which atthat point requires one to manually convert them back into C layout from
std::env::args_os.I also don't believe this change is meaningful as is, without an
otherwise major rework of the libfuzzer API. It doesn't achieve
anything much as it is, and only serves to complicate the implementation
of libfuzzer crate itself.
cc #46