Code coverage from processor trace
Structural coverage from processor trace on the optimized build.
In brief
Processor trace can provide coverage evidence without inserting software counters into the application. Object-code execution, source statements and branches can often be reconstructed passively. Source-level condition or MC/DC evidence depends on the optimized control-flow structure; where a required condition outcome is no longer observable, CEDARtools.Anchor provides an explicit supplementation route.
Coverage levels reported by Accemic
- Object-code execution: whether identified object-code regions or obligations were observed within the valid trace scope.
- Source statement coverage: object-code observations mapped to source statements using the corresponding compiler information.
- Decision or branch coverage: reconstructed control-flow outcomes mapped to source decisions where the mapping is supportable.
- Condition and MC/DC evidence: condition outcomes and independence pairs established from observable control flow or, where declared, Hybrid Runtime Analysis anchors.
CEDARtools.Anchor implements the Hybrid Runtime Analysis approach described in the published application; the two terms are used interchangeably on this page.
The report identifies the mapping basis and does not treat unresolved source obligations as uncovered object code or silently remove them from the denominator.
What each metric requires - trace semantics, program image, compiler mapping, timing or context options, and the causes that can leave an obligation unresolved - is listed per configuration in the capability matrix.
How the analysis route is selected
For each obligation, the workflow first asks whether the executed outcome is visible in the trace-reconstructed object control flow. If it is, the obligation is evaluated passively. If source mapping is incomplete, the result is marked unresolved. If the object control flow does not distinguish a required source-level condition outcome, the project can use a declared Hybrid Runtime Analysis anchor or retain the obligation for another verification method.
Instrumentation and trace-based observation
Software instrumentation remains an effective technique, particularly at unit level. Its execution-time effect can be small in some compiler and workload configurations, but it can also change code size, layout, register allocation and memory behavior. Trace-based observation is valuable where the project needs evidence from the executable used in its integration or system context and wants to avoid application-side coverage-state updates.
What you get
- Statement and branch coverage on the optimized build.
- MC/DC with the condition-level detail the metric requires. A single aggregate percentage is the wrong number here: it lets one well-tested decision with many conditions hide several untested ones. We report the condition level as the primary figure.
- Object code to source mapping, with code that cannot be attributed to source flagged rather than silently dropped.
- Exports into TESSY Hyper Coverage and Teamscale, plus HTML and CSV.
The denominator policy
A headline percentage is only as honest as its denominator. The report retains uncovered, unresolved, deactivated and excluded obligations as distinct categories, each with its count and disposition. Mapping gaps and justified exclusions therefore cannot improve the number silently - they stay visible next to it. If you are comparing tools, this is one of the five questions worth asking every vendor.
No application-side coverage counters
Passive trace analysis does not insert coverage counters, logging calls or a measurement runtime into the application instruction stream. Trace infrastructure still has to be configured, and the physical trace path consumes pins, bandwidth and power. Where Anchor* is used, the added observation anchors and their measured effects are disclosed with the result.
Measured comparison
A measured comparison is available for a real-scale SQLite workload compiled
at -O3. It compares the original target binary, Anchor* and GCC
coverage across code size, static RAM, observed runtime and source
attribution.
In this target configuration, the complete GCC coverage images do not fit the available memory. Their code and RAM figures are therefore reported as projections from measured translation-unit deltas, and no runtime value is invented.
Coverage evidence remains subject to the project’s tool-assurance strategy. See the qualification and assurance boundary for the responsibilities of CEDARtools®, import interfaces and downstream tools.
Sources
The requirements referred to on this page are stated in:
- RTCA DO-178C / EUROCAE ED-12C, cited by section (licensed publication);
- ISO 26262-6, cited by table (licensed publication).
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.