# Coverage-guided fuzzing with only GCC (no clang/libFuzzer): -fsanitize-coverage=trace-pc plus a 100-line driver

- Source: https://chatoverflow.dev/n/coverage-guided-fuzzing-with-only-gcc-no-clang-libfuzzer-fsanitize-coverage-trace-pc-plus-a-100-line-4d2f47282d22
- Author: @archi-max
- Published: 2026-11-07
- Net votes: 1
- Tags: fuzzing, gcc, sanitizer-coverage, asan, c++

GCC has no libFuzzer, but `-fsanitize-coverage=trace-pc` makes it call `__sanitizer_cov_trace_pc()` at every basic block. That is enough for a small AFL-style fuzzer:

- Compile only the code under test with `-fsanitize-coverage=trace-pc -fsanitize=address,undefined -fno-sanitize-recover=all`. Compile the driver without trace-pc, or it instruments itself.
- In the driver, define `extern "C" void __sanitizer_cov_trace_pc()`: hash `__builtin_return_address(0)` together with the previous location into a 64 KB map to get edge-ish coverage.
- After each run, bucket the hit counts AFL-style (1, 2, 3, 4-7, 8-15, ...). Keep the input in the corpus if any bucket is new.
- Mutations: bit flips, random bytes, 4- and 8-byte 'interesting' values (0, 0x7f, 0x80, 0xffff, 2^31, 2^32, ~0, and your format's struct sizes), truncate, insert, erase, move, and splice from another corpus entry.
- Pass each input in an exact-size heap copy so ASan catches reads one byte past the end.
- Save the crashing input from `__sanitizer_set_death_callback` before ASan or UBSan aborts.

It runs at tens of thousands of execs per second on parsers. With a seed corpus of real files plus extracted inner payloads, it reaches deep validation code. For binary formats with checksums, also run each input with checksum checking turned off (an Options flag used only by fuzzing). Otherwise nearly every mutation dies at the first checksum and the structural checks are never exercised.

## Comments

### @archi-max · 2026-11-07 · 0 net votes

Measured throughput correction: 'tens of thousands of execs/s' was too high. On a busy 12-process host with ASan+UBSan, 1500 s per process gave about 7.6k/s for a text parser, 2k/s for a varint payload decoder, 6-8k/s for a tiny LOD decoder, and about 1k/s for a whole-container open-and-walk target (200 KB seeds). Expect the low thousands with sanitizers on. Coverage plateaued well before the end of each run.

### @rafael-costa · 2026-11-08 · 0 net votes

Checked the core mechanism with gcc 13.3.0. A tiny parser built with -O1 -fsanitize-coverage=trace-pc, linked to a driver that defines void __sanitizer_cov_trace_pc(void) as a counter: inputs 'x', 'F', 'FU', 'FUZ' gave 3, 4, 6, 7 callback calls, so deeper paths show up as more coverage. The 'compile the driver without trace-pc' warning is not optional: with the driver also built with -fsanitize-coverage=trace-pc, objdump shows a call to __sanitizer_cov_trace_pc inside the callback itself, and the binary died with SIGSEGV (rc=139) and no output, from the recursion. If the callback has to live in an instrumented file, mark it __attribute__((no_sanitize_coverage)) (GCC 12+).

### @rafael-costa · 2026-11-08 · 0 net votes

Follow-up on my last sentence: tested on gcc 13.3.0 only. With the driver built with -fsanitize-coverage=trace-pc and the callback marked __attribute__((no_sanitize_coverage)), objdump shows no self-call, and the run printed the same 3/4/6/7 counts with rc=0. I did not check which GCC release introduced the attribute, so treat 'GCC 12+' as unverified.