eclipse-score / eclipse-score/tooling
coverage: on-target (QNX) coverage support in the shared coverage module
- Dominant language
- Rust
- Stars
- 8
- Forks
- 37
- Avg merge
- 2d 13h
- Merged PRs (30d)
- 22
Description
## Context
PR #394 centralizes the Linux/LLVM coverage pipeline (unified C++ + Rust, exact 0% baselines, justification gating) into `@score_tooling//coverage`. On-target (QNX) coverage was deliberately left out of that PR and is tracked here instead.
**Current state across S-CORE** (as of 2026-08-17):
- No repository enforces QNX coverage in CI. QNX *tests* run everywhere (QNX images built by the IFS toolchain, executed under qemu-system on the runners), but coverage is measured on Linux only.
- `communication` is the only repo with a QNX coverage capability at all: manual `bazel coverage --config=qnx` — C++ only, gcov-based (QCC/GCC → `.gcda` → Bazel default LCOV pipeline → `lcov_to_html.py`/gcovr rendering). It already reuses three shared components (the `coverage_scope` allowlist, `justify.py --platform qnx`, and `effective_coverage.py`, which auto-detects gcovr vs llvm-cov HTML). Untested-file baselines exist there via hand-maintained `baseline_coverage_test` helper targets.
- Rust coverage on QNX exists nowhere: rustc is an LLVM compiler and cannot emit gcov data, so it can never ride the gcov path; and until `ferrocene_toolchain_builder` 1.3.1 the LLVM profile runtime did not work on QNX at all (missing profile bitmap symbols; `madvise(MADV_DONTNEED)` crash — both fixed by the 1.3.1 compiler-rt patches). It has never been validated end-to-end.
## Goal
Make on-target coverage a first-class, CI-enforceable capability of the shared module, available to all modules (persistency and lifecycle already run QNX tests under QEMU — only the collection/reporting flow is missing).
## Track 1 — C++ via gcov (available today)
Move the gcov flow from `communication` into `@score_tooling//coverage` as an optional path:
- [ ] `lcov_to_html.py` (LCOV → gcovr JSON v0.14 → gcovr HTML; adds a `gcovr` pip dependency)
- [ ] the `coverage:qnx_x86_64` bazelrc block (QCC toolchain, Bazel default lcov_merger/report generator, LLVM options reset)
- [ ] the baseline-collection logic from `generate_coverage_html.sh` (merging Bazel's `baseline_coverage.dat` + `baseline_coverage_test` `_cc_coverage.dat` records) and documentation of the helper-target pattern
- [ ] a QNX case in the integration test workspace, then a consumer (e.g. communication) migrating its QNX flow to the shared module
## Track 2 — Rust (and eventually C++) via the LLVM pipeline
- [ ] End-to-end validation: a Rust QNX test built with `-Cinstrument-coverage` (builder >= 1.3.1 toolchain), executed under QEMU, `.profraw` copied back through the same channel that today carries `.gcda`, processed by the host llvm-cov pipeline. The transport is proven for gcov; only the profraw leg is unverified.
- [ ] If validated: stop resetting the Rust instrumentation flags in the QNX coverage config and report Rust-on-QNX through the standard pipeline (exact baselines, branch coverage, justification gate).
- [ ] C++ on QNX via covmap remains blocked until an LLVM-based QNX C++ toolchain exists in S-CORE (QCC is GCC-based); revisit if/when one appears.
## Non-goals
- Real-hardware (HIL) collection — same model (copy counter files back, process on host) but out of scope until QEMU-based collection is established.
Refs: #394 and its review discussion on `lcov_to_html.py` scope.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.