Compiled the module manager C sources, which no check had ever built

[fdesbiens]

Follow-up to #672.

Problem

#672 corrected this script's assembly glob and brought the module ports into the count — but only their assembly. Their C stayed outside every check:

• 27 files of portable module manager under common_modules/module_manager/src
• the per-port code under ports_module/<core>/gnu/module_manager/src

By this script's own standard, stated three times in its comments — a port that is simply absent from the count reads as covered — 293 files across nine Arm module ports were compiled by nothing, with either compiler.

Change

A sixth stage compiles the portable module manager plus each port's own C, once per Arm module port. Every module port ships its own tx_port.h and txm_module_port.h carrying the control-block extensions the dispatch code needs, so a port is compiled against its own headers rather than the base port's.

Two details the ports themselves dictate, both found by running the stage rather than by reading:

SMP ports take common_smp/inc. Pairing cortex_a35_smp with the single-core headers hid _tx_thread_smp_protect and _tx_thread_smp_unprotect behind implicit declarations and lost tx_thread_smp_core_executing from TX_THREAD — fourteen files reporting errors for a port that builds correctly. That was the harness being wrong, not the port.

TrustZone ports need -mcmse, or cmse_nonsecure_entry is silently ignored rather than honoured. tx_thread_secure_stack.c additionally carries GCC's optimize attribute, which clang does not implement. That one is a genuine toolchain divergence in a file GCC builds cleanly, so it is suppressed by name rather than left to fail.

Result

== Module manager C sources, one per Arm module port ==
  cortex_a35: 30 of 30 compiled
  cortex_a35_smp: 30 of 30 compiled
  cortex_a7: 33 of 33 compiled
  cortex_m0+: 32 of 32 compiled
  cortex_m23: 36 of 36 compiled
  cortex_m3: 32 of 32 compiled
  cortex_m33: 36 of 36 compiled
  cortex_m4: 32 of 32 compiled
  cortex_m7: 32 of 32 compiled

Full run green, all stages, including the example builds.

The stage was verified to actually fail

A check that only ever passes proves nothing, so defects were injected into a throwaway worktree: one in common_modules, one in a single port's own source. The shared defect is reported under every port; the port-specific one only under that port; counts decrement correspondingly.

Interaction with #639

The stage globs ports_module/*/gnu/module_manager/src, so a new module port is picked up automatically with no edit here — which is the point, but it means #639 (Cortex-R52 module manager port) is affected.

Running this stage against #639's head, nine ports pass and R52 reports:

ports_module/cortex_r52/gnu/module_manager/src/txm_module_manager_offset_check.c:58:
  fatal error: 'mpu.h' file not found

mpu.h exists only under ports/cortex_r52/gnu/example_build/{fvp_baser_aemv8r,s32z280_evb}/. With either on the include path the file compiles cleanly, so it is not broken — it is a port source depending on a board-specific header from an example build directory, and it cannot be compiled as a port source on its own. Worth noting that the two board copies of mpu.h differ, and this file exists to statically assert offsets the port's assembly hard-codes, so which board is reachable is not obviously immaterial.

That is for #639 to resolve; flagging it here because merging this first will surface it there.

[fdesbiens]

Merged dev and pushed three corrections, all found by running the stage against current dev rather than the tree it was written on. Verified with the same toolchain CI uses, ATfE 22.1.0.

The stage would have failed on merge

Run against dev as it stands, every port failed on txm_module_manager_absolute_load.c — nine failures, rc=1:

== Module manager C sources, one per Arm module port ==
  FAIL: cortex_a35: common_modules/module_manager/src/txm_module_manager_absolute_load.c
  cortex_a35: 30 of 31 compiled
  ...
9 LLVM toolchain check(s) failed.

Nothing is wrong with the file. Since this PR was opened, #699 gave it a #pragma message steering callers to the extended entry point:

warning: txm_module_manager_absolute_load() is deprecated. Use
txm_module_manager_absolute_load_extended() ... [-W#pragma-messages]

The stage treats any compiler output as a failure, and it compiles that file once per port, so one deliberate notice failed all nine. Pragma messages are now waived for the stage — a notice to callers is not a defect in the file carrying it.

This is the check doing its job before it even lands: the interaction only exists because the green atfe run on this PR predates #699, and nothing else in CI compiles these files.

That failure printed no reason

Both C stages report by grepping the output for error:, so a diagnostic that is not an error gave a bare FAIL: line with nothing under it. Working out why cost a hand-reproduced compile, and would have cost the same in CI. Both stages now fall back to showing what the compiler actually said.

The workflows did not trigger on common_modules

clang_check.yml and gcc_check.yml both list ports_module but not common_modules. The portable module manager under it is the larger half of what this stage compiles — 28 of the 31–37 files per port, plus two include directories — so a change there left the stage unrun. That is the same "absent from the count reads as covered" this stage exists to close. Both lists gain it, and stay identical as the comment in each asks.

The TrustZone waiver is narrowed

-Wno-unknown-attributes applied to every file of the m23 and m33 ports. tx_thread_secure_stack.c is the only file among the 300-odd compiled here that carries GCC's optimize attribute (checked), so the waiver is now scoped to it; a stray unknown attribute anywhere else in those ports is still reported. Confirmed load-bearing — without it that file warns, with it the port is silent.

Result

Full script green, rc=0, all stages:

  cortex_a35: 31 of 31        cortex_a35_smp: 31 of 31    cortex_a7: 34 of 34
  cortex_m0+: 33 of 33        cortex_m23: 37 of 37        cortex_m3: 33 of 33
  cortex_m33: 37 of 37        cortex_m4: 33 of 33         cortex_m7: 33 of 33

Each count is one higher than first reported, because txm_module_manager_absolute_load_extended.c has landed since. The stage picked it up with no edit here, which is what globbing the directories was for.

Still open

check_gcc.sh has no equivalent stage, so GCC — the project's default compiler — still does not build these files. Its module port handling reaches assembly only. Worth a follow-up rather than widening this PR to two compilers; the common_modules path entry added to gcc_check.yml here is already in place for it.