We should compute the coverage after running fuzzing in PRs. This way we can catch if any new functions are added to the code that are not called during fuzzing, and thus we can adapt the fuzz targets.
For running coverage we will probably need to update the rust-vmm-container to add the required tools. To gather the coverage information for fuzzing for the Fosdem talk (https://fosdem.org/2023/schedule/event/vai_fuzzing_device_models/) I've used the following commands:
# Gather coverage information from fuzz corpus:
cargo +nightly fuzz coverage virtio_queue
# Get the coverage information (as a report):
llvm-cov report --instr-profile coverage/virtio_queue/coverage.profdata target/x86_64-unknown-linux-gnu/coverage/x86_64-unknown-linux-gnu/release/virtio_queue --ignore-filename-regex='/.cargo/registry'
# Show detailed information about the coverage per file:
llvm-cov show -Xdemangler=rustfilt target/x86_64-unknown-linux-gnu/coverage/x86_64-unknown-linux-gnu/release/virtio_queue -instr-profile=coverage/virtio_queue/coverage.profdata -show-line-counts-or-regions --ignore-filename-regex='/.cargo/registry'
These commands can be extended in a separate test that receives as a parameter the fuzz target name and can output the coverage details.
We should compute the coverage after running fuzzing in PRs. This way we can catch if any new functions are added to the code that are not called during fuzzing, and thus we can adapt the fuzz targets.
For running coverage we will probably need to update the rust-vmm-container to add the required tools. To gather the coverage information for fuzzing for the Fosdem talk (https://fosdem.org/2023/schedule/event/vai_fuzzing_device_models/) I've used the following commands:
These commands can be extended in a separate test that receives as a parameter the fuzz target name and can output the coverage details.