Instrumented every build configuration and merged their coverage

[fdesbiens]

Only default_build_coverage carried -fprofile-arcs, because the gate was the build type and it is the only one of five whose name ends in _coverage. The other four build and run every test and their coverage was discarded.

That is not redundancy thrown away. Each configuration selects a different set of TX_ feature macros, so the code the other four compile is absent from the denominator rather than uncovered in it — a figure taken from one of them is the executable-line count of one configuration, not of the kernel.

What this does

TX_COVERAGE instruments a build regardless of its name, defaulting to OFF so a single configuration built by hand behaves exactly as before. coverage.sh gains a --merge mode that unions the per-configuration JSON tracefiles, and cmake_bootstrap.sh runs it after the test loop so a local run produces the same merged report CI reads.

Expect the percentage to drop, and expect that to be correct

Measured on the ThreadX suite, all 480 tests passing:

configuration	lines-valid	lines-covered
default_build_coverage	3827	3827
disable_notify_callbacks_build	3767	3766
stack_checking_build	3857	3856
stack_checking_rand_fill_build	3862	3861
trace_build	4123	4108
merged	4503	4487

The denominator grows by 676 lines — 17.7% — and the reported figure moves from 99.97% to 99.64%. The second number is the honest one; the denominator now includes code the old report never counted at all.

The union also contains a file the old report did not contain at all: tx_thread_stack_error_handler.c compiles only under TX_ENABLE_STACK_CHECKING, so it was not listed at 0%, it was simply absent. 177 files becomes 178.

Coverage collection is serialised, and that is load-bearing

Collection moved out of test() and now runs after the test loop, one configuration at a time.

gcov writes its intermediate .gcov files into the directory gcovr is rooted at, and coverage.sh roots every configuration at the repository root so filenames come out repo-relative. Five concurrent gcovr processes therefore share one scratch directory and delete each other's output. The first full run of this change passed all 480 tests and produced no report for three of the five configurations — a green suite with most of its coverage silently missing.

Measured both ways: two gcovr rooted at the repository root fail concurrently and both succeed in sequence. CI would not have caught it, because test_tx.sh sets CTEST_PARALLEL_LEVEL=1 and takes the serial branch — a coincidence of one caller rather than a property of the script.

The SMP question, and why it is not a blocker

An earlier run of this branch saw trace_build fail threadx_smp_time_slice_test and then hang, which raised the question of whether -fprofile-arcs perturbs a timing-sensitive test. It does not. Sixteen runs settle it.

The decisive one: threadx_smp_time_slice_test failed ERROR #31 — twice in a row under --repeat until-pass:2 — on an uninstrumented build, in the exact shape CI runs, while three instrumented runs of that shape passed 5/5.

In the CI shape, CTEST_PARALLEL_LEVEL=1 run.sh test all:

	runs	result	wall clock
TX_COVERAGE=OFF (= dev today)	3	2 green, one ERROR #31	310 s
TX_COVERAGE=ON (this PR)	3	3 green, 5/5 each	325–329 s

So the test is a pre-existing flake on dev, and instrumenting all five costs about 5% of the suite's wall clock.

Separately, and in both instrumented and uninstrumented builds, run.sh's parallel branch — what you get typing run.sh test all with no CTEST_PARALLEL_LEVEL — hangs under its own load, four times in twelve runs. Several SMP tests create 1024 ThreadX threads by construction and the Linux port backs each with a pthread, so five configurations at once put on the order of 5000 threads on the machine. CI sets CTEST_PARALLEL_LEVEL=1 and does not take that branch. Not introduced here, and not addressed here.

Reviewing

coverage_report/per_configuration/ exists because of the Pages deploy: it merges the ThreadX and SMP artifacts into one tree and every configuration directory has the same name in both suites, so left at the top level one suite's would overwrite the other's on the published site.

The one thing no PR has exercised before is the !.../per_configuration/** exclusion in the artifact upload — worth checking on this run that the uploaded coverage_report-* artifact holds only the suite directory and merged.xml.