Reliable object to source code mapping

Last technically reviewed 2026-08-16Evidence basis: Primary specifications, Peer-reviewed literature, Engineering analysis

In brief

Anchor* supplements processor-trace observation where optimization removes the control-flow distinctions needed to establish a source-level condition outcome. It introduces bounded, semantically neutral control-flow anchors before compilation, records their identity in an anchor manifest, and evaluates the resulting executable from trace. The method does not write coverage state from the application, but the anchors are part of the measured executable and their effects must be characterized.

The idea

At the points of interest - the places a coverage metric needs to tell apart - the source is supplemented with control-flow blocks that are

• functionally neutral - they do not change what the program computes;
• preserved through optimization - preservation is verified rather than assumed, per compiler, version and optimization setting;
• free of memory operations on analysis state - the application maintains no coverage counters and no software trace buffer.

Preservation of the anchors is verified for each supported compiler, version, optimization setting and target configuration. The build process checks the generated object code against the anchor manifest and rejects a configuration in which an anchor is missing, merged or mapped ambiguously.

The third property is the one that matters. Conventional instrumentation writes coverage state from the application, and those writes can touch caches, timing and the memory budget, depending on configuration. An anchor produces no store to analysis state. The anchors still execute as part of the program and therefore have an instruction-level effect that is measured separately.

The anchors are visible in the trace stream. Evaluation happens outside the target and is mapped back to source through the anchor manifest - a static observation mapping between source-level points and their binary representations - together with symbol-table associations. As disclosed in the published application, that mapping metadata can draw on debugging data, symbol-table data, or both; the anchor attribution does not have to rest on DWARF debug information.

Where CEDARtools.Anchor fits

Passive processor trace is an excellent observation channel - but compiler optimization can remove source-level distinctions that a verification obligation still needs.

For a human expert, that creates an interpretation problem. For an automated feedback loop, it creates a machine-readability problem: the loop needs a stable, reviewable relationship between the requirement-level obligation and what is observable in the optimized executable.

Anchor* restores selected observability only where it is needed. Bounded, trace-visible control-flow anchors preserve the distinctions required for the analysis without maintaining coverage state in application memory. Their effect is measured and reported as part of the evidence.

This makes Anchor* not only a coverage technique, but an enabling layer for reliable, source-attributed feedback from highly optimized embedded software.

What CEDARtools.Anchor changes - and what it does not

Anchor* changes the program representation by adding observation anchors. It does not add coverage counters, a logging runtime or application-side trace-buffer writes. The anchors are intended not to change the functional result, but they can change code size, layout and execution timing. Functional equivalence and perturbation therefore remain project evidence, not assumptions.

What comes out

• MC/DC on the optimized build, with condition-level detail - which pairs were exercised and which are still missing. Not a single percentage that averages the answer away.
• Object code to source mapping through the anchor manifest and symbol-table associations - a mapping that does not have to rest on DWARF debug information.
• Orphan object code flagged explicitly. Machine code that cannot be attributed to any source line is marked as such rather than quietly dropped. For a DO-178C or ED-12C review that distinction is the point - an assessor needs to see what was not accounted for, not a report that looks complete because the awkward parts were omitted.
• No custom compiler build required. The supported workflow does not require a custom compiler build. It remains compiler-dependent in the ordinary assurance sense: anchor preservation, object mapping and perturbation are verified for named compiler versions, targets and optimization settings. The supplemented source stays readable, and you can diff it against the original.

Status

Patent applications covering the relevant aspects of the technology have been filed. A patent application describes the claimed invention at a legal level of generality; implementation details and measured product behavior are documented separately. The application status and our granted patent families are listed on the patents page.

Anchor* is used in the documented TESSY Hyper Coverage integration for the tested versions and artifact flow listed on the integration page.

The method was developed at Accemic before 2024 and is documented in our peer-reviewed work on trace-based coverage; see publications.