Persistent Fuzzing API LibFuzzer

[zi0Black]

I'm developing a fuzzer that would strongly benefit from persistent fuzzing, since it requires many configuration steps, and doing them once per fuzzing instance can accelerate the process, but I see no macro to interact with LLVMFuzzerInitialize.
http://www.wilfred.me.uk/llvm/LibFuzzer.html#startup-initialization

https://github.com/rust-fuzz/libfuzzer/blob/c8275d1517933765b56a6de61a371bb1cc4268cb/src/lib.rs#L81C1-L98C2, I also noticed that the issue mentioned here in the comments has been resolved.

[fitzgen]

Is there a reason you cannot use std::sync::OnceLock to do the one-time initialization?

[hanna-kruppe]

Lazy initialization is an okay workaround but I'd still like a way to run initialization code outside of the fuzz target. The LibFuzzer documentation recommends either global static initialization (not really available in Rust for good reasons) or LLVMFuzzerInitialize instead and following this advice seems prudent. I don't know if and when it makes a big difference, but if the initialization-only code is very large then I have a bad feeling about incorrectly attributing that much coverage to whatever element of the corpus is tested first. For example, I'd like to fuzz a hand-written lexer against an oracle using regular expressions to define what the tokens should be. In this case the entire regex parser/compiler runs (only) during initialization and might easily involve more code than the entire actual fuzz target, including regex matching for the oracle.

[fitzgen]

Just thought of how we could do user initialization inside LLVMFuzzerInitialize without any breaking changes after some brainstorming with @alexcrichton:

• Move our existing LLVMFuzzerInitialize definition into the fuzz_target! macro, rather than having it be ambient in the crate source
• Add a new pattern to the fuzz_target! macro to optionally take user-initialization code, and the macro would paste that user-initialization code into the LLVMFuzzInitialize function that we generate

This does mean that the initialization would be part of the fuzz_target! macro rather than a new fuzz_init! or whatever macro, but that doesn't feel too bad.

Happy to take a PR if you want to try your hand at it.