Matched gcov to the compiler that produced the coverage data - #658
Merged
fdesbiens merged 1 commit intoAug 24, 2026
Merged
Conversation
gcov reads a data format tied to the compiler that produced it. coverage.sh took whatever gcov was first on PATH, which was fine while the compiler was also whatever was first on PATH. eclipse-threadx#656 made cmake/linux.cmake honour CC and eclipse-threadx#657 made a compiler switch actually reconfigure the build, so that assumption no longer holds, and the first person to use the new capability would have hit this. Measured on dev with both of those merged: CC=gcc-14 ./run.sh build default_build_coverage # succeeds ./coverage.sh default_build_coverage # exit 64 gcov says why, if asked directly: tx_block_allocate.c.gcno:version 'B42*', prefer 'B33*' gcovr turns that into "GCOV returncode was 3" and exits 64 through a Python traceback, after the tests have already passed. It reads like a coverage bug rather than a toolchain mismatch, which is the part that would have cost someone an afternoon. gcov is now derived from CC rather than found on PATH, so the caller sets one variable instead of remembering two. GCOV still overrides, for a toolchain that does not follow the gcc/gcov naming, and a derived gcov that does not exist is reported as such instead of surfacing as a traceback. Verified, tx and smp, before and after: CC=gcc-14 was exit 64, now exit 0, 177 files and 1527/3827 lines CC unset exit 0, 177 files and 1527/3827 lines, unchanged CC=gcc-99 exit 1 naming gcov-99 and CC, rather than a traceback GCOV=gcov-14 with CC=gcc-99, exit 0, so the override still wins A mismatched pairing still fails, deliberately: reading a gcc-14 tree with the default gcc-13 gcov is exit 64 as before. Producing a number from mismatched data would be worse than refusing. Assisted-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Companion to #656 and #657. Neither is wrong; together they open a hole that this closes.
gcovreads a data format tied to the compiler that produced it.coverage.shtook whatevergcovwas first onPATH, which was fine while the compiler was also whatever was first onPATH. #656 madecmake/linux.cmakehonourCC, and #657 made a compiler switch actually reconfigure the build — so that assumption no longer holds, and the first person to use the new capability would have hit this.Measured on
devwith both merged:gcovsays why, if asked directly:The part that would have cost someone an afternoon is where it surfaces: the tests all pass, then the coverage step dies with a Python traceback, which reads like a
gcovrbug rather than a toolchain mismatch.The change
gcovis derived fromCCinstead of found onPATH, so the caller sets one variable rather than remembering two.GCOVstill overrides, for a toolchain that does not follow thegcc/gcovnaming, and a derivedgcovthat does not exist is reported as such rather than surfacing as a traceback.Applied to both
test/tx/cmake/coverage.shandtest/smp/cmake/coverage.sh.Verified, both suites
CC=gcc-14CCunset (what CI does)CC=gcc-99gcov-99andCC, not a tracebackGCOV=gcov-14withCC=gcc-99CI is unaffected: nothing in the workflows sets
CC, so the default path is byte-for-byte the behaviour it had before.One deliberate non-fix
Reading a gcc-14 tree with the default gcc-13
gcovstill fails with exit 64. That pairing is wrong, and producing a number from mismatched coverage data would be worse than refusing. Only the case whereCCis stated is made to work.