Fixed the coverage report's paths and scoping

[fdesbiens]

The Cobertura XML embeds absolute machine paths, and the flag that looks like it scopes the report to one build configuration is doing nothing at all. Both coverage.sh scripts carry the defect; both are fixed here, because the SMP report is published to the same Pages site as the ThreadX one.

Paths

-r was the build directory and -f pointed outside it, so gcovr could not express the sources relative to the root and fell back to absolute paths:

<source>build/default_build_coverage</source>
<class filename="/home/fdesbiens/code/threadx-fd/common/src/tx_block_allocate.c" ...>

The two halves of the same file disagree, and on a runner those paths are /home/runner/work/threadx/threadx/..., so nothing that maps coverage back to the repository — PR annotations, Codecov, SonarQube — can follow them. irongut/CodeCoverageSummary only sums totals, which is why this has survived.

-r is the repository root now and -f an absolute path beneath it, giving filename="common/src/tx_block_allocate.c" under a <source> that agrees with it.

Both have to be absolute. -r ../../.. -f common/src produces a report of zero files and exits 0 — the worst failure mode available here, a green run carrying an empty report.

Scoping

--object-directory does not restrict which .gcda files are found. It tells gcovr how to get from a .gcda file back to the compiler's working directory. Pointed at an empty directory it still produced the full 177-file report, because gcovr searches -r as well.

That was harmless only by accident: -r build/$1 constrained the search instead. Moving -r to the repository root removes the accident, so the two changes have to land together. Measured with a second instrumented configuration deliberately made sparser than the first:

invocation	lines covered
scoped by the positional search path	3221 / 3827 — the truth
no search path, -r at the repo root	3827 / 3827 — silently merged the other configuration in
--object-directory at the sparse tree	3827 / 3827 — scopes nothing

So the positional search path is load-bearing, and it matters ahead of instrumenting all five configurations: without it, each configuration would report the union as its own.

An empty report reads as 100%

An empty report is not an error to gcovr — it warns and exits 0 — and it carries line-rate="1.0" beside lines-valid="0":

<coverage line-rate="1.0" branch-rate="1.0" lines-covered="0" lines-valid="0" ...>
  <packages/>

So a consumer reads no data at all as fully covered, and no coverage threshold can catch it, because an empty report passes any threshold. Hence the explicit assertion that the report has content. It fires with exit 1 on an object directory that exists but is empty — where the old shape returned 177 files and exit 0.

Also

Says out loud that ports/linux/gnu/src is deliberately outside the filter. .gcno files exist for it and it is dropped today without a word.

Verification

Number-neutral, and that was the test. Over the same frozen .gcda, changing only the gcovr invocation:

	before	after
ThreadX lines	3827 / 3827	3827 / 3827
ThreadX branches	1993 / 1994	1993 / 1994
ThreadX files	177	177
SMP lines	4739 / 4791	4739 / 4791
SMP branches	2417 / 2430	2417 / 2430
SMP files	185	185

Comparing over frozen .gcda rather than fresh runs is deliberate: the numerator moves run to run on its own. A later full run of the SMP suite reported 4741 rather than 4739 with lines-valid unchanged at 4791, which is that same flicker and not this change.

Same answers on gcovr 7.0, 8.3 and 8.6, so the change is not wedged to the current pin. End to end through run.sh: 96 of 96 and 110 of 110 pass with the reports written.