Pros and cons of compiling dependencies with instrumentation

[szhorvat]

Suppose we are fuzzing a function from library A, which depends on library B. What are the pros and cons of compiling B with full fuzzer instrumentation as well? Will this make the fuzzer less effective in exploring A, as the algorithm might spend most time on exploring a potentially larger B?

igraph got into this situation somewhat unintentionally. It depends on libxml2, which we compile from sources in order to be able to exclude a buggy dependency of libxml2 (ICU), which may crash. Compiling libxml2 with instrumentation does in fact seem to be necessary when using MSan, so this setup became convenient. A drawback is that performance is much worse, even leading to occasional timeouts. Are there other drawbacks? Does including libxml2 make the fuzzer less efficient at increasing the coverage in igraph code, as larger libxml2 codebase may dominate, "hogging" the fuzzing algorithm's attention?

[DavidKorczynski]

Another drawback, although related, is that this can cause performance issues for the core fuzzing engine itself. Envoy has written about how this affected their OSS-Fuzz set up:
A stroll down fuzzer optimisation lane and why instrumentation policies matter

The issues is that each "instrumentation point" needs to be processed by the fuzzing engine. If there are a lot of instrumentation points this will make a lot of the fuzzing process spend time in the engine itself, rather than exploring the target code.