Published 2026-08-29Last technically reviewed 2026-08-16Evidence basis: Published measurement, Primary specifications, Engineering analysis

---

Coverage by instrumentation is the default for good reasons. It is well-understood, it works on any target, the tooling is mature, and for a large class of projects it is exactly right.

It is also the thing trace-based measurement is usually positioned against, often with an argument that no longer holds as strongly as it once did. Here is the honest version.

In brief

Coverage instrumentation adds counters to the program. Its costs are of three different kinds: runtime perturbation, code and RAM footprint, and the structural fact that the measured artifact differs from the shipped one. The first two are workload-dependent and sometimes small; the third does not get weaker. A measured, real-scale SQLite -O3 comparison below shows all three at once.

What instrumentation does

Instrumentation schemes insert observation code and state according to their own model. For example, GCC -fprofile-arcs instruments selected CFG arcs outside a spanning tree and reconstructs the remaining arc counts; condition coverage records exercised condition effects in compiler-generated state. Other tools may instrument statements, blocks, branches, paths or conditions differently. Resource and semantic claims must therefore identify the exact tool, version and options. The program updates that state as it runs; afterwards it is read out and turned into a report.

Three costs follow, and they are of different kinds.

Cost 1: runtime, and why this argument got weaker

The intuitive objection is that counters cost time. They do - and not always by much. In cases we have observed, generated counter updates and layout changes produced a net runtime effect within the observed variation, and one instrumented build measured marginally faster than the uninstrumented one: at that magnitude, layout effects dominate the counters. The mechanism behind such a result belongs in the object code and the measurement record, not in a generic claim about register retention.

So the blunt form of the argument - “instrumentation is slow” - is not reliably true, and stating it as a general claim invites a fair rebuttal. Some optimized counter implementations have little measurable runtime effect in particular loops or workloads. That finding should be reported, not hidden. It does not establish zero effect for the complete application, and it does not remove code-size, layout or artifact-identity questions.

The precise form survives: the cost is workload- and layout-dependent, up to changing sign. That is exactly what limits its value as timing evidence for the production binary. An instrumented timing result is not a direct measurement of the shipped binary. Any transfer requires an explicit probe-effect/equivalence analysis with stated bounds; where that cannot be established, report the production timing as unknown from this run.

Cost 2: memory

Counters live somewhere. On a host, irrelevant. On a target with a fixed RAM budget and a linker script that is already tight, the instrumented build may simply not fit - and the amount is predictable enough to plan for, which is why this cost is the least controversial of the three.

Cost 3: the artifact is a different artifact

This is the one that does not get weaker.

The build you measured has different code, different layout, different timing and different memory behavior from the build you ship. Everything you conclude from it transfers by argument, not by measurement.

For unit-level testing that argument is easy and nobody objects. At integration and system level, on real hardware, with timing-dependent behavior, it is the argument an assessor pushes on.

All three costs can be seen together in one measured, real-scale example: SQLite at -O3, measured on a Cortex^®-M7 target directly after the two-run argument below.

The two-run counter-argument

There is a well-established practice that addresses this: run the tests twice, once instrumented and once not, compare the outputs, and if they agree, argue that the coverage measured in the first run applies to the second.

It is a reasonable method and it is used in certified projects. It is worth being precise about what it establishes: output equivalence, not coverage transfer. Structure was observed only in the instrumented run. The transfer step is a representativeness argument - a good one, often accepted, and still an argument rather than a measurement.

It also has four places where it does not reach:

• Residual object code that exists only in the shipped binary, and is absent or relocated in the instrumented build.
• MC/DC under optimization, where the two builds do not have the same condition structure to begin with.
• Timing-dependent interleavings - interrupts, DMA - where two runs are not the same execution regardless of output equality.
• Integration level with binary-only components, where the instrumented build cannot be produced at all.

A measured comparison: SQLite at -O3

One benchmark cannot predict the overhead of another program. It can, however, show where each observation method pays and which evidence remains available after optimization.

The example below uses a real-scale SQLite 3.45.3-based workload compiled at -O3 for an Arm^® Cortex^®-M7 target. The complete record - setup, evidence status, source-attribution results and machine-readable dataset downloads - is the SQLite -O3 Evidence Record. It compares the original target binary, CEDARtools.Anchor and GCC coverage across four separate dimensions:

• code size;
• static RAM;
• observed runtime;
• source attribution.

These dimensions must be read separately. A method may have little runtime effect while substantially increasing code or RAM. A complete machine-level trace may still be insufficient to identify every source-level coverage obligation.

Three ways to observe the same workload

Native trace and DWARF

The native variant is the original optimized target binary, built without coverage counters or anchors. Hardware instruction trace records the executed machine-level control flow. Debug information is then used to attribute that execution to source-level structures.

This path leaves the application instruction stream unchanged. Its limitation is not necessarily trace completeness: compiler optimization may merge, predicate, clone or remove source-level structures so that an observed machine branch no longer identifies one source obligation unambiguously.

CEDARtools.Anchor

The Anchor* variants supplement selected source-level paths and conditions with named control-flow anchors. The anchors preserve source identity in the generated object code and symbol information. Their execution is observed through hardware trace and evaluated outside the target.

The anchors occupy code space and can affect code layout. They do not maintain coverage counters or analysis state in application RAM.

GCC coverage

The GCC variants use compiler-generated software instrumentation. The statement and decision comparison uses GCC coverage counters; the L4 comparison additionally uses GCC condition coverage.

The compiler inserts counter-update code and allocates coverage state in RAM. In this SQLite configuration, the projected complete instrumented images exceed the available target memory, so no on-target GCC runtime value exists.

The term “L4 comparison” describes the condition-level configuration used in this experiment. It must not be presented as evidence that GCC condition coverage is semantically identical to every MC/DC interpretation used by certification-oriented tools or standards.

What source attribution means

Source attribution is the ability to assign observed machine-level execution to the correct source-level coverage obligation without ambiguity.

It is separate from both trace completeness and coverage achieved.

A trace can be complete at the machine level while optimization has merged, predicated or removed the source structure required to determine which source condition produced the observed event. In that case, execution was observed, but the observation cannot safely be attributed to one source-level obligation.

For the native binary, source attribution depends on the source-to-object relationship retained in debug information and in the optimized control flow.

Anchor* preserves the identity of selected paths and conditions through named anchors. Missing or colliding anchors can therefore be reported as detected attribution shortfalls rather than silently treated as covered.

GCC instrumentation preserves source identity by placing its own counters at compiler-selected observation points. That identity comes with the code, RAM and runtime effects reported separately below. It is also line-level identity: for condition-level MC/DC, GCC’s condition coverage derives condition outcomes from the optimized control-flow graph, so a condition the optimizer merges is gone from GCC’s own report as well, whereas Clang’s source-based coverage keeps the source conditions through optimization because it instruments before the optimizer runs - measured with both compilers.

Trace completeness asks: did we observe the machine execution?

Source attribution asks: can we assign that observation to the correct source obligation?

Coverage asks: which attributable obligations were exercised?

Measurement setup

• Workload: SQLite 3.45.3-based real-scale corpus; target configuration using the report’s LEMON-rebuilt subset
• Optimization: -O3
• Target: STM32H7S3L8 on NUCLEO-H7S3L8
• Processor: Arm Cortex-M7 at 600 MHz
• Target load regions: 456 KB AXISRAM, 64 KB ITCM and 64 KB DTCM
• Aggregate load-region capacity: 584 KB
• GCC toolchain used for the measured deltas: arm-none-eabi-gcc 14.2.1
• Measurement snapshot: 13 July 2026
• Test level shown: system test

Static size, runtime and source attribution have different evidence paths and are labeled accordingly. Native and Anchor* code and RAM values are static artifact measurements. Runtime values come from a documented on-target rate-mode campaign. The GCC code and RAM values are projections from measured translation-unit deltas because the complete GCC images do not fit this target configuration. Source attribution is derived from source-to-object analysis rather than from elapsed-time measurement.

The complete comparison - both levels, every value with its evidence status - follows in the data tables at the end of this page.

When each is right

An honest decision table, without a product in it:

The first two rows are the majority of testing that happens in the world. It would be dishonest to pretend otherwise.

And a caveat about our own side

CEDARtools.Anchor should be evaluated by the same discipline. It avoids application-side coverage-state writes, but the observation anchors add instructions and may change layout or timing. We do not criticize software instrumentation for perturbation while describing Anchor* as effect-free.

“Non-intrusive” is a gradient, not a switch. A trace-based approach does not touch the code, but the trace unit has to be configured, the trace port has to be routed, and enabling trace is not literally free at the silicon level. Approaches that add anything to the build - even something that writes nothing to memory - are supplementing it, and the honest word for that is supplementation, not zero cost.

We would rather write that down than let the word “non-intrusive” do work it cannot support.

Choose the observation method according to the verification question. Instrumentation is often appropriate for detailed unit-level feedback. Passive processor trace is attractive when application-side counters or a separate executable would weaken an integration or timing argument. Anchor* is an explicit trade-off where source-condition observability is required and passive reconstruction is insufficient.

Related terminology

In this context, the following expressions refer to closely related aspects of the same question: instrumentation cost; coverage instrumentation overhead; software instrumentation overhead; probe effect of coverage instrumentation. This page uses instrumentation cost as the canonical term.

What this page establishes

• the three cost classes of instrumentation and the evidence each needs;
• what the two-run practice establishes (output equivalence) and where it does not reach;
• a decision table for when instrumentation is the right answer;
• a measured comparison with its Evidence Record.

Limitations

Every number on this page is specific to its workload, compiler, optimization level and target configuration. No percentage from one program predicts another.

Sources

The instrumentation mechanism described above is documented by its own project:

• gcov, documented in the GCC manual.

Our own measured figures are labeled as such, with the build and date.

Where this becomes a product decision

• Applicable capability: CEDARtools.Coverage - passive measurement without application-side counters; CEDARtools.Anchor where source attribution needs explicit anchors.
• Configuration check: target support, answered per configuration.
• Evidence and limits: the SQLite -O3 measurement record and measurement validity.

Apply this to your target

Send the exact processor, board, trace path, compiler and metric you need. We will review feasibility at configuration level rather than answering from the core-family name alone.

Start a target feasibility review

---

Related: the mapping problem