Insufficient compiler directives to disable coverage instrumentation result in both less performance and worse fuzzing experience (due to messing up real coverage).
I compiled luzer in two different environments. First, as per CONTRIBUTION.md, a Debian (trixie, as only trixie has clang-17 in repos) with liblua-dev version 5.1. Second, as per GitHub Actions yaml file, Ubuntu 22.04 with liblua-dev version 5.2, and whatever clang were in that yaml (15?)
As we can see from disassembly, both times inline 8bit counters are instrumented into code that logically should not cause libfuzzer to get any new features (at least as a side effect).
On average luzer.so produce around 250 parasitic counters. With related PR, I managed to brought it down to 150, and same disassembly now looks like this on debug build under Debian:
Please see PR https://github.com/ligurio/luzer/pull/10 with a small fix.
Insufficient compiler directives to disable coverage instrumentation result in both less performance and worse fuzzing experience (due to messing up real coverage).
I compiled luzer in two different environments. First, as per
CONTRIBUTION.md
, a Debian (trixie, as only trixie has clang-17 in repos) with liblua-dev version5.1
. Second, as per GitHub Actions yaml file, Ubuntu 22.04 with liblua-dev version5.2
, and whatever clang were in that yaml (15?)This is objdump from Debian/selfbuild version:
This is from Ubuntu/luarocks:
As we can see from disassembly, both times inline 8bit counters are instrumented into code that logically should not cause libfuzzer to get any new features (at least as a side effect).
On average
luzer.so
produce around 250 parasitic counters. With related PR, I managed to brought it down to 150, and same disassembly now looks like this on debug build under Debian: