Published 2026-08-17Last technically reviewed 2026-08-17

---

In brief

This Evidence Record compares an optimized SQLite 3.45.3-based workload on an Arm^® Cortex^®-M7 target using three observation paths: the native binary observed through instruction trace, the CEDARtools^® product CEDARtools.Anchor with its named control-flow anchors, and GCC coverage instrumentation.

In this configuration, Anchor* increased code size while leaving static RAM effectively unchanged. The complete GCC coverage images were projected to exceed the available target memory and therefore produced no on-target runtime result. The experiment also shows why complete machine-level observation and unambiguous source attribution are separate properties.

What this record establishes

• the code and static-RAM effects measured or projected for this exact workload and target configuration;
• the observed native and Anchor* runtimes from the documented target campaign;
• whether each comparison artifact fits the configured target memory;
• the distinction between machine-level trace completeness and source-level attribution;
• the source-attribution result reported for native trace and Anchor*.

What this record does not establish

• a universal overhead for Anchor*, GCC coverage or hardware trace;
• that anchors make software execute faster;
• that GCC coverage always exceeds target memory;
• that GCC condition coverage is semantically identical to every certification-oriented interpretation of MC/DC;
• that complete source attribution means complete coverage has been achieved;
• that the same result applies to another compiler, optimization level, workload or target.

Experimental setup

• Workload: SQLite 3.45.3-based target workload 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 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. Native and Anchor* code and RAM values are static artifact measurements. Runtime values come from a documented on-target campaign. The GCC code and RAM values are projections from measured translation-unit deltas because the complete GCC images do not fit the target configuration. Source attribution is derived from source-to-object analysis rather than elapsed-time measurement.

The two comparison panels below show the reviewed values; every number carries its evidence badge.

The runtime ledger

Runtime was measured with an iteration-rate method on the target (campaign of 3 July 2026, Board A, workload health-checked per run): the workload iteration counter is read over fixed windows, and the per-iteration time is the reciprocal of the rate. The unrounded ledger values:

The two repeated native windows and the two repeated L4 windows each differed by approximately 0.04%. The anchored variants were non-monotonic and measured faster than native in this campaign.

This experiment does not isolate intrinsic anchor cost from code layout, cache alignment, binary differences or other build-to-build effects. The values are therefore observations for the named campaign and configuration, not a per-anchor cost estimate and not evidence that anchors accelerate the workload.

Two display notes for reviewers comparing this record against the RA-Studio overview snapshot of 13 July 2026: the overview displayed the L4 time as 37.5 ms where the ledger rates give 37.4 ms, and it displayed runtime percentages (95.3%/89.8%) that are not reproducible from the ledger rates. This record therefore publishes the rate-derived values above; the snapshot files remain unmodified in the evidence set.

Source attribution

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

It is separate from trace completeness and from coverage achieved. The concept has its own reference page: source attribution in trace-based code coverage.

A machine-level trace can be complete while compiler optimization has merged, predicated, cloned or removed the source structures needed to assign an observed branch or path to one source obligation.

In this experiment, native trace supported unambiguous source attribution for 77% (5,667 of 7,356) of the decision obligations linked into the image - the L0/L1 anchor-set catalog minus functions the linker stripped from this build. Statement obligations are not part of this ratio. At the L4 condition level, attribution was available for 48.2% (1,470 of 3,047) of the conditions in multi-condition (“compound”) decisions, while 51.6% (646 of 1,251) of the compound decisions were completely derivable from the branch trace.

This does not mean that the remaining execution was absent from the trace. It means that the observed machine event could not always be assigned to one source-level obligation without ambiguity.

Anchor* preserves selected source identities through named control-flow anchors. GCC instrumentation preserves observation identities through compiler-generated counters. Their attribution mechanisms and target-side resource effects must be evaluated separately.

Reading the result

For the statement and decision class, Anchor* increased .text from 413,512 B to 448,352 B, an increase of 8.4%. Static RAM remained effectively unchanged.

The GCC coverage image is projected at 777,399 B of code and 233,760 B of static RAM. Together with the 54,420 B of the native image that these two figures do not include - dominated by ITCM-resident code and the reserved heap/stack block, and held constant by the projection - the projected complete image is 1,065,579 B (approximately 1,041 KiB) and does not fit this target configuration. Because there is no launchable target image, no GCC runtime value is reported.

For the condition/MC/DC-class comparison, Anchor* increased .text to 461,160 B, 11.5% above native, again without a material static-RAM increase.

The corresponding GCC image is projected at 986,938 B of code and 364,568 B of static RAM. Together with the same unchanged 54,420 B remainder of the native image, its projected complete image is 1,405,926 B (approximately 1,373 KiB) and does not fit this target configuration.

The observed Anchor* runtimes were 39.4 ms (L0), 36.9 ms (L1) and 37.4 ms (L4) per iteration, compared with 41.2 ms for the native runtime campaign - rate-derived observations from the ledger above. The campaign did not separate anchor execution cost from code-layout, cache-alignment and binary variation effects; no causal speedup or per-anchor runtime cost is inferred.

The static-size values on this record come from the snapshot build of 13 July 2026; the runtime campaign of 3 July 2026 ran its own campaign images. The two are separate evidence paths, as stated above, and are not values extracted from one identical binary artifact.

Evidence status

The attribution labels in this record do not establish that every source-level obligation is represented, nor that GCC condition coverage is semantically identical to every certification-oriented MC/DC interpretation. For the Anchor* condition/MC/DC class, attribution is available for the complete anchored obligation set linked into the image; obligations the compiler proves infeasible are reported as a named, detected exclusion class rather than as a silent gap.

Download the data

• JSON dataset
• CSV dataset

The files preserve the method, units and evidence status for each value. The data may be freely cited and reused with attribution to Accemic Technologies GmbH and a reference to this record.

Where the data below comes from

All numerical inputs on this page originate from Accemic measurements, taken from the RA-Studio snapshot of 13 July 2026 and reviewed into a versioned data module in this repository. Values labeled PROJECTED are calculated from measured translation-unit deltas; they are not measurements of a successfully linked and executed full-target GCC coverage image. The measurement snapshots themselves are internal evidence inputs; the reviewed values, their evidence classes and the machine-readable dataset downloads below are the public record. The mapping basis behind these values is described on object-to-source mapping; the concepts behind the comparison are explained in what instrumentation costs and why the object-to-source mapping breaks under optimization.