add fuzz-coverage subcommand

[folkertdev]

I'm opening this PR now to get some early feedback on the direction.

This currently supports invocations like this one:

cargo llvm-cov --release --target x86_64-unknown-linux-gnu fuzz-coverage -- --features=disable-checksum uncompress2

At the moment, the --release and --target flags are required for llvm-cov to find the right object files: fuzzers are built with --release by default, and the artifacts are stored in target/<host target>/release by default.

The output of That command looks like this:

Generating coverage data for corpus "/home/folkertdev/fuzz/zlib-rs/fuzz/corpus/uncompress2"
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 354881940
INFO: Loaded 1 modules   (26740 inline 8-bit counters): 26740 [0x5b5a476240d0, 0x5b5a4762a944), 
INFO: Loaded 1 PC tables (26740 PCs): 26740 [0x5b5a4762a948,0x5b5a47693088), 
MERGE-OUTER: 2182 files, 0 in the initial corpus, 0 processed earlier
MERGE-OUTER: attempt 1
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 380843920
INFO: Loaded 1 modules   (26740 inline 8-bit counters): 26740 [0x613c67b200d0, 0x613c67b26944), 
INFO: Loaded 1 PC tables (26740 PCs): 26740 [0x613c67b26948,0x613c67b8f088), 
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 1048576 bytes
MERGE-INNER: using the control file '/tmp/libFuzzerTemp.Merge142277.txt'
MERGE-INNER: 2182 total files; 0 processed earlier; will process 2182 files now
#1	pulse  cov: 160 ft: 161 exec/s: 0 rss: 35Mb
#2	pulse  cov: 180 ft: 181 exec/s: 0 rss: 35Mb
#4	pulse  cov: 188 ft: 189 exec/s: 0 rss: 35Mb
#8	pulse  cov: 236 ft: 237 exec/s: 0 rss: 35Mb
#16	pulse  cov: 311 ft: 329 exec/s: 0 rss: 36Mb
#32	pulse  cov: 473 ft: 622 exec/s: 0 rss: 37Mb
#64	pulse  cov: 575 ft: 846 exec/s: 0 rss: 39Mb
#128	pulse  cov: 598 ft: 1092 exec/s: 0 rss: 42Mb
#256	pulse  cov: 607 ft: 1354 exec/s: 0 rss: 49Mb
#512	pulse  cov: 677 ft: 1728 exec/s: 0 rss: 64Mb
#1024	pulse  cov: 690 ft: 2120 exec/s: 0 rss: 102Mb
#2048	pulse  cov: 903 ft: 3005 exec/s: 0 rss: 245Mb
#2182	DONE   cov: 913 ft: 3128 exec/s: 0 rss: 304Mb
MERGE-OUTER: successful in 1 attempt(s)
MERGE-OUTER: the control file has 304161 bytes
MERGE-OUTER: consumed 0Mb (39Mb rss) to parse the control file
MERGE-OUTER: 467 new files with 3128 new features added; 913 new coverage edges
Merging raw coverage data...
Coverage data merged and saved in "/home/folkertdev/fuzz/zlib-rs/fuzz/coverage/uncompress2/coverage.profdata".
Filename                                    Regions    Missed Regions     Cover   Functions  Missed Functions  Executed       Lines      Missed Lines     Cover    Branches   Missed Branches     Cover
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
fuzz/fuzz_targets/uncompress2.rs                 14                 2    85.71%           1                 0   100.00%          62                 2    96.77%           0                 0         -
libz-rs-sys/src/lib.rs                          257               229    10.89%          48                41    14.58%         419               375    10.50%           0                 0         -
...

Some argument parsing questions

• should llvm-cov fuzz-coverage also enable --release by default? or warn when it's not specified
• should llvm-cov fuzz-coverage also enable --target <host target> by default? or warn when it's not specified

In both cases, the arguments to fuzz coverage could pick something non-default. So the proper way to do this is to parse the arguments. That's fragile, though I don't expect cargo-fuzz to make radical changes.

Alternatively, we could ask for some sort of --json output to cargo fuzz coverage that has the relevant information.

Some open questions

• this command does not really fit into how the existing set of subcommands is tested, so that'll need some custom work
• I need to figure out how the fixtures work. It seems useful to test fuzz coverage with those, right?

linking #415

[folkertdev]

@taiki-e this is not done, but does it look like a good direction to explore further?

[taiki-e]

Thanks for the PR and sorry for the late response! I haven't reviewed this in detail, but it looks like a good direction!