Files
threadx/.github
Akif EjazandFrédéric Desbiens 18abe103af Enabled the RISC-V regression suite in CI for QEMU targets (#717)
* Enable the RISC-V regression suite in CI

The riscv: job in regression_test.yml has been present but commented out
since the RISC-V CI infrastructure landed (scripts/install_riscv.sh,
scripts/build_tx_riscv.sh, scripts/test_tx_riscv.sh, and the CMake tree
under test/tx/cmake/riscv/). It has been gated on a note that read
're-enable when RISC-V CI is ready', with no other blocker recorded.

The suite is ready. A local run of scripts/build_tx_riscv.sh followed by
scripts/test_tx_riscv.sh against upstream/dev builds every RISC-V target
and passes every registered test across all ten build configurations:

  RV32 (five configs): 5 * 95 = 475 tests, 0 failures, 0 timeouts.
  RV64 (five configs): 5 * 96 = 480 tests, 0 failures, 0 timeouts.

The extra RV64 test is threadx_riscv_new_thread_fpu_state_test, which
lives beside test/tx/cmake/riscv/regression/CMakeLists.txt and is added
only when THREADX_ARCH is risc-v64 -- the RV32 stack builder still
leaves the mstatus slot of the frame unwritten. Every test runs on
qemu-system-riscv32 / qemu-system-riscv64 with -machine virt, and each
configuration completes in roughly thirteen to fifteen seconds.

The job is wired the same way the ThreadX, SMP and FreeRTOS suites are:
it calls .github/workflows/regression_template.yml with the RISC-V
install/build/test scripts and the RISC-V cmake_path, sets
result_affix: RISC-V so its check name and artifacts are named, and
carries skip_deploy: true because coverage publishing stays on the
Linux suites for now. skip_coverage: true is kept because the CMake
configurations under test/tx/cmake/riscv match the Linux suite's minus
the coverage instrumentation, so gcovr has nothing to read -- the same
reason the FreeRTOS lane sets it. The regression_test.yml triggers were
not touched, so the RISC-V suite now runs on push and pull_request to
master and dev alongside the other three suites.

* Said why the RISC-V suite collects no coverage, instead of implying a missing build configuration

The comment added with the job read "No coverage build configuration for the
RISC-V suite yet". Both halves of what followed are true -- the configurations
under test/tx/cmake/riscv are the Linux suite's minus the coverage one, and
gcovr has nothing to read -- but "yet" points the next reader at a fix that
would not work.

Coverage here is not one missing default_build_coverage entry. These tests are
bare-metal images run under QEMU with -bios none, and
test/tx/cmake/riscv/bsp/syscalls.c has _write to the UART, _exit through the
sifive_test device, and stubs for _close, _fstat, _isatty, _lseek, _read and
_sbrk -- but no _open. gcov emits a .gcda by opening a path, so instrumenting
these builds produces nothing regardless of how they are configured. Nor is
the template's TX_COVERAGE=OFF what holds coverage off: test/tx/cmake/riscv is
its own top-level project and never declares that option, so the value is
inert there.

Getting a figure out of this suite needs a transport off the target -- gcov's
dump routines over the UART the BSP already drives, or semihosting. Worth
stating plainly in a project that asks for 100% coverage, rather than leaving
a reader to discover it after adding a configuration that cannot help.

Comment only; the job's inputs are unchanged.

Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com>

---------

Co-authored-by: Frédéric Desbiens <frederic.desbiens@eclipse-foundation.org>
2026-09-10 09:08:11 -04:00
..
2024-05-27 09:05:29 +02:00
2024-01-11 13:48:24 -08:00