threadx.git/scripts/check_clang.sh, branch dev

Enabled execution profiling for Cortex-R5 (#766)

2026-09-28T16:45:09Z

The Cortex-R5 assembly guarded its execution-profile hooks with only the legacy TX_ENABLE_EXECUTION_CHANGE_NOTIFY symbol. The documented TX_EXECUTION_PROFILE_ENABLE configuration initialized profiling without recording thread or interrupt transitions. I made all AC5, AC6, GNU, Green Hills, and IAR hooks accept both symbols. I also extended the port consistency and GNU/LLVM feature checks to cover the current configuration. All 849 base assembly files and all 219 TX_EXECUTION_PROFILE_ENABLE files passed with GCC 14.2.1 and clang 22.1.0. A CMake/Ninja Cortex-R5 profile build emitted all seven expected hook relocations. Proprietary toolchains were not run. Assisted-by: Codex (GPT-5)

Compiled the module manager C sources, which no check had ever built (#689)

2026-09-09T18:39:30Z

* Compiled the module manager C sources, which no check had ever built #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, plus the per-port code under ports_module//gnu/module_manager/src. By this script's own standard -- a port simply absent from the count reads as covered -- 293 files across nine Arm module ports were compiled by nothing, with either compiler. Each 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: An SMP port's control blocks come from common_smp. 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, so fourteen files reported errors for a port that builds correctly. The TrustZone ports carry cmse_nonsecure_entry, which needs -mcmse to be honoured rather than ignored. tx_thread_secure_stack.c also carries GCC's optimize attribute, which clang does not implement; that divergence is suppressed by name, for a file GCC builds cleanly. All nine ports compile: 293 of 293. Verified that the stage fails as intended by injecting a defect into a throwaway worktree -- a defect in common_modules is reported under every port, one in a port's own source only under that port. Assisted-by: Claude Code (Opus 5) * Ran the module manager stage against the sources that reach it Three corrections to the new stage, all found by running it against dev rather than against the tree it was written on. The workflows did not trigger on common_modules. Both check_clang.yml and check_gcc.yml list ports_module but not common_modules, and the portable module manager under it is the larger half of what the stage compiles -- 28 of the 31 to 37 files each port builds, plus two include directories. A change there left the stage unrun, which is the same "absent from the count reads as covered" that the stage exists to close. Both lists gain common_modules, and they stay identical to each other as the comment in each asks. A deliberate deprecation notice read as a build failure. Since this PR was opened, txm_module_manager_absolute_load.c gained a #pragma message steering callers to the extended entry point. The stage treats any compiler output as a failure, so that one notice failed every port: nine failures on a tree where nothing is wrong. Pragma messages are now waived for the stage, because a notice to callers is not a defect in the file that carries it. That failure also printed nothing. Both C stages report by grepping the output for "error:", so a diagnostic that is not an error produced a bare FAIL line with no reason under it, and the only way to learn the reason was to reproduce the compile by hand. Both stages now fall back to showing what the compiler actually said. The TrustZone attribute waiver is narrowed to the one file that needs it. tx_thread_secure_stack.c carries GCC's optimize attribute, which clang does not implement; it is the only file among the 300-odd this stage compiles that does. Waiving the warning for the whole port would have swallowed a stray unknown attribute anywhere else in it. Verified with the same toolchain CI uses, ATfE 22.1.0: the full script passes, and every port compiles every file. cortex_a35 31/31 cortex_a35_smp 31/31 cortex_a7 34/34 cortex_m0+ 33/33 cortex_m23 37/37 cortex_m3 33/33 cortex_m33 37/37 cortex_m4 33/33 cortex_m7 33/33 The counts are each one higher than this PR first reported, because txm_module_manager_absolute_load_extended.c has landed since. The stage picked it up with no edit, which is what globbing the directories was for. Assisted-by: Claude Code (Opus 5) --------- Co-authored-by: r

Assembled the module ports, which no check had ever compiled (#672)

2026-08-28T13:24:30Z

scripts/check_clang.sh globbed ports_module/*/gnu/src, which does not exist -- the module ports keep their assembly in module_manager/src. The [ -d ] guard skipped it in silence, so 116 assembly files across nine Arm module ports were assembled by no check, with either compiler, in the script whose own comments state three times that "a port that is simply absent from the count reads as covered". Stage 1 goes from 724 of 724 to 840 of 840; the feature-macro stage had the same gap and goes from 412 files to 469. Correcting the path exposed five defects, and only one of them was a build failure. The other four assembled cleanly and did the wrong thing, because GAS runs the C preprocessor on .S and not on .s: ports_smp/cortex_a7_smp/gnu/src/tx_thread_smp_unprotect.s, the only .s in a directory of twenty-one .S, ignored all four of its own feature macros. It wrote the caller's LR into the protection structure on every unprotect -- a store guarded by TX_MPCORE_DEBUG_ENABLE -- sent an unconditional SEV, and returned through both BX lr and MOV pc, lr. Its cortex_a5_smp and cortex_a9_smp siblings are .S. ports_module/cortex_m33/.../tx_thread_stack_build.s emitted both arms of an #ifdef TX_SINGLE_MODE_SECURE, so the non-secure LR value overwrote the secure one and the secure build got the wrong frame. ports_module/cortex_m23/.../tx_thread_context_{save,restore}.S carried the POP {r0, lr} that check_clang.sh's own comment describes as the reason the feature-macro stage exists. The 16-bit Thumb POP takes r0-r7 and pc only. The identical fix already sits in ports/cortex_m23/gnu/src; the module copy never got it because nothing scanned it. ports_module/cortex_m23/.../tx_thread_secure_stack_initialize.S used MOV rather than MOVS for an 8-bit immediate, latent behind TX_SINGLE_MODE_SECURE. Both siblings in the same directory already use MOVS. ports_module/cortex_a7/gnu/module_manager/src is the one that failed to assemble, on GCC 14.3 as well as on LLVM: #define SYS_MODE was never expanded, so #SYS_MODE reached the assembler as an undefined symbol. Twenty-nine .s files under gnu trees are renamed to .S. Every one of them is already named .S by the build scripts that compile it, so this repairs those scripts rather than churning them -- ports_module/cortex_a7's build_threadx.bat names all eighteen with a capital S, and works today only on a case-insensitive filesystem. Renaming rather than converting the #defines to GNU assignments is what fixes the #ifdef blocks as well as the constants; the assignments would have fixed two files and left twenty-seven silently ignoring their macros. Files with no preprocessor directives are left as .s: they are not broken, and check_ports.sh gains a check that keeps them that way. Only the gnu trees are checked there -- the IAR, Arm Compiler 5 and Keil assemblers preprocess .s themselves, and about three hundred files in this repository rely on that. Verified with both toolchains on the same tree: 840 of 840 assembled by ATfE 22.1.0 and by arm-gnu-toolchain 14.3.rel1, all five stages of check_clang.sh green, and check_ports.sh green including the reproducibility check. The new check was shown to fail by planting a copy of the file it was written for. No regression test accompanies this. The assembly it covers is executed by no host test, and the check itself going from 724 files to 840 is the coverage AGENTS.md asks for -- together with the new check_ports.sh section, which is what stops the class recurring. Assisted-by: Claude Code (Opus 5)

Added Cortex-M52 (Armv8.1-M) port (#519)

2026-08-16T12:29:46Z

* ports: add Cortex-M52 (Armv8.1-M) port support Add ThreadX port for Cortex-M52, supporting three toolchains: - GNU (GCC) - AC6 (Arm Compiler 6) - IAR Cortex-M52 is an Armv8.1-M Mainline processor sharing the same architecture profile as Cortex-M55 and Cortex-M85. The port is functionally identical to the existing Cortex-M85 port. * ports: update cortex_m52 port copy script,using it update content -Add cortex_m52 in threadx/scriprts/copy_armv8m.sh -Using updated copy_armv8m.sh to generate new cortex_m52 port content * Regenerated the Cortex-M52 port against dev and wired it into the checks The port was generated from ports_arch/ARMv8-M as it stood on master, which has since moved on. Rebasing onto dev and running scripts/copy_armv8_m.sh again brings the twelve stale files into line, which is the point of generating them: the core picks up every ARMv8-M fix made since without anyone porting it by hand. Among what it picks up: "MOV r0, 0" becomes "MOV r0, #0" in the schedule and system-return paths, the non-canonical immediate form that GNU as tolerates and LLVM's assembler rejects; and gnu/src/tx_initialize_low_level.S goes away, since the shared source no longer has it. Two integration points exist only on dev, so the original change could not have included them. cmake/cortex_m52.cmake, so the port can be selected the documented way. Every other Cortex-M core has one. It uses the hard float ABI, as Cortex-M55 and Cortex-M85 do. An entry in scripts/check_clang.sh, likewise with -mfloat-abi=hard. That flag is not decoration: -mcpu=cortex-m52 implies Helium, and building it soft-float ends in "multilib configuration error: No library available for MVE with soft-float ABI" on every file, which reads as a broken port rather than a missing flag. Verified after regenerating: scripts/copy_armv8_m.sh is a no-op, so the tree matches its source; all 14 assembly sources and 188 C sources compile for cortex-m52 with Arm Toolchain for Embedded 22.1.0. Note for anyone building with GNU tools: arm-none-eabi-gcc 13.2.1 rejects -mcpu=cortex-m52 outright. Support arrives in GCC 14. --------- Co-authored-by: Frédéric Desbiens Assisted-by: Claude Code (Opus 5)

Stopped the remaining example scripts naming archives that were deleted (#620)

2026-08-15T20:58:59Z

#618 fixed the arm9 and arm11 shell scripts, but not their .bat counterparts, and did not look at cortex_r4 and cortex_r5 at all. An audit of every build script against the files actually present in its directory found the rest. The .bat scripts for arm9, arm11, cortex_r4 and cortex_r5 still linked libc.a, libgcc.a and, for arm11, libnosys.a from their own example_build directories, and the cortex_r4 and cortex_r5 shell scripts did too. Those archives went in 6.1.10 under "Removal of unneeded files", so on Windows all four examples failed exactly as the shell versions did before #618, and on Linux the two R-profile ones still did. Link through the compiler driver, as the other examples have since #594. This does not make the examples link, and the change stops there deliberately. All four now fail the same way, undefined reference to `_fini' because their linker scripts define the .init and .fini sections but not the _init and _fini symbols, which live in crti.o and crtn.o and are omitted by -nostartfiles. Reviving four very old cores is separate work. Correct the comment on EXAMPLES_EXPECTED_TO_FAIL again. It had cortex_r4 and cortex_r5 failing for want of newlib multilib variants; they do not. All four share the single cause above, and the multilib explanation was wrong for the R-profile pair just as it was for arm9 and arm11. Verified by running each shell script: cortex_r4 and cortex_r5 fail on _fini rather than on missing files, matching arm9 and arm11. The .bat changes mirror link lines proven that way in the same directories; they cannot be run here. Three scripts are left alone and reported instead, because a blind edit could not be verified: ports_module/cortex_m3 and cortex_m4 have Windows-only .bat scripts that also name sources which are absent or differ in case, and ports_smp/mips32_interaptiv_smp needs a MIPS toolchain. Assisted-by: Claude Code (Opus 5)

Removed generated build output and per-user IDE state, and fixed two stale link lines (#618)

2026-08-15T20:40:19Z

* Removed generated build output and stopped two scripts naming deleted archives Three kinds of file in the tree are produced by a build rather than written by hand, and one pair of scripts still links archives that were deleted years ago. Keil writes ThreadX_Library.plg on every build; the two committed copies are HTML build logs from someone's machine. Code Composer generates the makefiles under ports/c667x/ccs/example_build/tx/Release from the project files beside them, so makefile, objects.mk, sources.mk, subdir_rules.mk, subdir_vars.mk and ccsObjs.opt are all regenerated output. The arm9 and arm11 sample builds link libc.a, libgcc.a and, for arm11, libnosys.a from their own example_build directories. Those archives were removed in 6.1.10 under "Removal of unneeded files", and libnosys.a in #594, but the link lines were never updated, so both examples fail immediately with arm-none-eabi-ld: cannot find libc.a: No such file or directory Link through the compiler driver instead, the shape every other example in the tree uses since #594: the driver supplies libc and libgcc, and SYSCALL_LIB is already defined in both scripts. That does not make either example link, and the fix stops short of that on purpose. With the archives no longer named, both now fail on undefined reference to `_fini' because their linker scripts define the .init and .fini sections but not the _init and _fini symbols, which live in crti.o and crtn.o and are omitted by -nostartfiles. Making those two old cores build is a separate question from removing a stale reference, so they stay in EXAMPLES_EXPECTED_TO_FAIL, with the comment there corrected: it blamed newlib multilib packaging, which is true of cortex_r4 and cortex_r5 but was never the reason for arm9 and arm11. Reproduced throughout with arm-none-eabi-gcc 13.2.1. Assisted-by: Claude Code (Opus 5) * Removed the Keil per-user state files and ignored them Every Keil project in the tree carried a second file holding per-user state: 25 .uvoptx beside the 25 .uvprojx, 9 .uvopt beside the 9 .uvproj, and 3 .uvgui multi-project workspace files. uVision rewrites all of them whenever a project is opened, so they record whoever last had it open rather than anything about the port: debugger selection, breakpoints, watch windows, window geometry. Nothing in the tree references them, and every affected directory keeps its .uvprojx or .uvproj, which is the file that actually describes the project. Add ignore rules so they do not come back the next time someone opens a project and commits. 1.4 MB across 37 files. Assisted-by: Claude Code (Opus 5)

Added TX_ENABLE_FIQ_SUPPORT to the feature-macro assembly stage (#610)

2026-08-13T19:57:18Z

#608 assembled the code behind TX_ENABLE_VFP_SUPPORT, TX_LOW_POWER and TX_ENABLE_EXECUTION_CHANGE_NOTIFY, and missed TX_ENABLE_FIQ_SUPPORT, which guards assembly in 145 files across the A and R profile ports. All 145 assemble today, so this adds no fix, only the regression protection the other three already have. Also recorded why TX_ENABLE_IRQ_NESTING and TX_ENABLE_FIQ_NESTING are not in the list, since their absence otherwise looks like the same oversight. They guard no assembly in the trees this script walks: the nesting start and end routines are separate files compiled unconditionally, and the macros only feed the TX_PORT_SPECIFIC_BUILD_OPTIONS bitfield in tx_port.h. Adding them would assemble nothing new while implying coverage that does not exist. Verified with Arm Toolchain for Embedded 22.1.0: 711 of 711 assembly sources, then 37 of 37 VFP, 145 of 145 FIQ, 8 of 8 TX_LOW_POWER and 218 of 218 TX_ENABLE_EXECUTION_CHANGE_NOTIFY. Assisted-by: Claude Code (Opus 5)

Assembled the code behind feature macros, and fixed the POP it found (#608)

2026-08-13T14:14:53Z

scripts/check_clang.sh assembled every source with default flags, so the preprocessor discarded each #ifdef block before the assembler saw it. Nothing in the tree had ever assembled a guarded path. That covers the VFP context save and restore in ten ports, and 218 files carrying TX_LOW_POWER or TX_ENABLE_EXECUTION_CHANGE_NOTIFY. Turning those on found a defect. The Cortex-M0 and Cortex-M23 execution-profile paths bracket their call with PUSH {r0, lr} BL _tx_execution_isr_enter POP {r0, lr} and the last of those is invalid on Armv6-M and Armv8-M Baseline, where the 16-bit Thumb POP takes r0-r7 and pc and nothing else. GNU rejects it as well -- "cannot honor width suffix" -- so TX_ENABLE_EXECUTION_CHANGE_NOTIFY and TX_EXECUTION_PROFILE_ENABLE have never been buildable on either port with either toolchain. Four files, all the same shape. The fix pops into a scratch register and moves it, MOV to a high register being permitted where POP is not. r1 is free: the BL may clobber r0-r3, which is the reason r0 is saved in the first place. Disassembling the result gives push {r0, lr} / bl / pop {r0, r1} / mov lr, r1 / bx lr, one 16-bit instruction more than before and otherwise the same. Two findings that were not defects, recorded in the script so they are not rediscovered: Cortex-R4 needs an -mfpu to assemble its VFP path, because its FPU is an option rather than part of the core. GNU fails identically without one, so this is a flags requirement and not a toolchain divergence. The A profile ports must not be given one. Adding -mfpu=vfpv3-d16 uniformly broke 28 files with "register expected", because those ports save D16-D31 and a -d16 FPU does not have those registers. Their defaults were already right. The new stage runs under --asm-only as well, needing no target C library, and reports 37 of 37 VFP files, 8 of 8 TX_LOW_POWER and 218 of 218 TX_ENABLE_EXECUTION_CHANGE_NOTIFY. Restoring the POP for one run makes it fail with 217 of 218 and name the file and the error, so the stage is not vacuous. The other four stages are unchanged: 711 of 711 assembled, 185 of 185 common C sources for each of nine cores, 42 of 42 script-driven examples and 5 of 5 CMake images. The fixed code is verified to assemble with both toolchains and to encode as intended. It is not verified running: there is no Cortex-M0 or Cortex-M23 model here, and these are context save and restore paths, so that gap is worth stating. Assisted-by: Claude Code (Opus 5)

Brought the Cortex-R52 examples under the LLVM check, and fixed two blockers (#604)

2026-08-11T23:53:11Z

#600 added a line reporting which example builds the LLVM check passes over, and cortex_r52 was on it: its examples are driven by CMake rather than by a build_threadx.sh pair, so the linking stage never touched them. Covering them turned up two reasons they could not have been built with anything but GNU. .arch armv8-r has no portable spelling. GNU as accepts it, and LLVM's integrated assembler rejects every variant -- armv8-r, armv8r, armv8-r+crc -- with "Unknown Arch: armv8-r". There is nothing to substitute, so the directive is gone from entry.S and tx_initialize_low_level.S; -mcpu=cortex-r52 already selects the architecture, both toolchain files pass it, and the directive only restated it. Worth noting where this hid: the assembly stage walks ports/*/gnu/src, so example assembly had never been assembled by LLVM at all. -Wl,--no-warn-rwx-segments is GNU ld only, added in binutils 2.39. ld.lld does not warn about RWX segments and rejects the flag outright, failing the link with "unknown argument". It is now selected on CMAKE_C_COMPILER_ID rather than spelled into all six targets, and the reason it exists at all -- a bare-metal image has one flat DRAM region and leaves access control to the MPU -- moves to the one place that sets it. cmake/cortex_r52_clang.cmake is the toolchain file. It names the tools as found on PATH, which is what CI uses, then pins $HOME/toolchains if that directory exists, mirroring how cortex_r52.cmake pins the GNU toolchain and for the same reason. Falling back rather than requiring the pinned path keeps the file usable on a machine that keeps clang elsewhere. THREADX_TOOLCHAIN stays "gnu": there is no clang port directory, this builds the gnu sources with a different compiler, which is what the whole check does for every other Arm port. check_clang.sh gains a fourth stage for CMake-driven examples, and no longer reports cortex_r52 as a gap. It reads the image list out of the generated ninja graph rather than repeating it, so adding a target cannot escape the check, and filters out the cmake_object_order_depends_target_* phonies -- counting those reported ten images where there are five. Verified with Arm Toolchain for Embedded 22.1.0, the version the workflow pins. All five images link, and all five then run and pass on FVP_BaseR_AEMv8R: boot_check, demo_m2, demo_m3, demo_threadx and demo_mpu. That is a step beyond the AArch64 examples, which are link-verified only. The full check reports 711 of 711 assembly sources, 185 of 185 common C sources for each of nine cores, 42 of 42 script-driven examples and 5 of 5 CMake images, leaving only cortex_a5_smp, cortex_a7_smp and cortex_a9_smp listed as having no driver. GNU is unaffected: the same five images build with no warnings and the FVP test suite passes 5 of 5. Assisted-by: Claude Code (Opus 5)

Enrolled the Cortex-R52 port in the LLVM C check and exposed the skipped examples (#600)

2026-08-11T17:51:01Z

Two gaps in check_clang.sh, both of which made the Cortex-R52 port look better covered than it was. C_CORES gains cortex_r52. That list is described as one core per architecture profile, and Armv8-R AArch32 is a profile rather than a variant of Armv7-R: the port is written by hand instead of generated from ports_arch, so cortex_r5 does not stand in for its tx_port.h. The assembly was already covered, since #593 added the PORT_TARGET entry, but the common C sources had never been compiled against that header. The example stage skipped any directory lacking both driver scripts, and did so in silence. A port absent from the count reads as covered, which is how the two CMake based example builds under ports/cortex_r52 looked like part of the total while never being built. The stage now reports what it passed over, in the two distinct cases that exist. The comment above EXAMPLES_EXPECTED_TO_FAIL already asks for gaps to stay visible; this makes the code agree with it. Four Cortex-M ports turn out to carry build_threadx.sh with no build_threadx_sample.sh, so they were skipped despite having a driver: cortex_m23, cortex_m33, cortex_m55 and cortex_m85. Reported, not fixed. Whether those want a sample script is a separate question. The expected-to-fail test now runs before the Arm test rather than after. arm9 and arm11 are on that list but carry no PORT_TARGET entry, so testing for Arm first dropped them from the report entirely, reintroducing the same silence for two ports that were already being named. Verified with Arm Toolchain for Embedded 22.1.0, the version CI pins: 711 of 711 assembly sources, 185 of 185 common C sources for each of the nine cores including cortex_r52, and 38 of 38 example builds linking, so the built set is unchanged by this commit. The remaining driverless ports report as cortex_r52, cortex_a5_smp, cortex_a7_smp and cortex_a9_smp, the three A profile SMP ports having no example scripts and the R52 examples being driven by CMake. --help still frames the intended lines, since the additions sit below the range it selects by number. Assisted-by: Claude Code (Opus 5)