Gave the Armv8-M examples a linkable sample and fixed what stopped them (#601)

The Cortex-M23, M33, M55 and M85 examples each shipped a build_threadx.sh with
no build_threadx_sample.sh, so scripts/check_clang.sh skipped all four at its
linking stage: the whole Armv8-M family had no example-link coverage. Adding the
missing script surfaced five separate reasons why none of them could have linked.

ports/cortex_m23/gnu/src/tx_initialize_low_level.S referenced
Image$$ARM_LIB_STACK$$ZI$$Limit and __Vectors, which are Arm toolchain
scatter-load names that no GNU linker defines. This is a GNU port, so it now
uses __RAM_segment_used_end__ and _vectors, as the Cortex-M33 version already
does. The Cortex-A ports mention Image$$ZI$$Limit only inside a comment; this
was a live relocation.

The Cortex-M23 crt0 needed unified assembler syntax. The Armv7-M file it derives
from carries no .syntax directive, so GNU as reads it in the legacy divided
syntax, where a Thumb data-processing instruction sets the flags whether or not
the mnemonic says so, and "mov r2, #0" assembles to 2200, MOVS. LLVM implements
unified syntax only, where those mnemonics mean the non-flag-setting forms that
Armv8-M Baseline does not have. Disassembling the Cortex-M4 object confirms GNU
already emits 2200 movs, 1a52 subs and 3001 adds, so spelling them out changes
no encoding. The flags carry meaning: crt0_memory_copy branches on the result of
"subs r2, r2, r1" and again on "subs r2, #1".

Cortex-M23 has no SVC_Handler to name in its vector table. Its library is built
-DTX_SINGLE_MODE_NON_SECURE, and tx_thread_schedule.S defines that handler only
when neither TX_SINGLE_MODE_SECURE nor TX_SINGLE_MODE_NON_SECURE is set, so the
SVCall slot takes __tx_BadHandler. The table also uses the CMSIS handler names
throughout, because that is what the Armv8-M ports export: the Armv7-M table
references __tx_SVCallHandler and __tx_SysTickHandler, which resolve to nothing
here.

The other three needed a C library. tx_thread_secure_stack.c calls malloc and
free, which pulls the allocator in, and the sample scripts already defined
SYSCALL_LIB for exactly that without ever passing it to the linker. Their linker
scripts now also provide end and _end, which newlib's libnosys _sbrk wants, and
__heap_start and __heap_end, which picolibc wants instead.

Cortex-M55 and M85 build with the hard-float ABI now, in both the library and
the sample. Arm Toolchain for Embedded ships no soft-float MVE multilib and says
so plainly: "No library available for MVE with soft-float ABI." The library and
the sample have to agree, and -mfloat-abi=hard is what check_clang.sh already
uses for these two cores in PORT_TARGET.

Verified with GNU 13.2.1 and Arm Toolchain for Embedded 22.1.0. Every port links
under both: Cortex-M23 at 206,136 and 312,636 bytes, M33 at 305,856 and 320,696,
M55 at 306,228 and 320,664, M85 at 306,240 and 320,668. check_clang.sh now
reports 42 of 42 example builds linking, up from 38, and no longer lists any port
as carrying build_threadx.sh without build_threadx_sample.sh. The images are
link-verified only and have not been executed, as with the AArch64 examples.

Only .sh drivers are added. Cortex-M23 has a build_threadx.bat with no sample
counterpart and the other three have no .bat at all; adding untested Windows
scripts belongs in its own change.

Assisted-by: Claude Code (Opus 5) <[email protected]>

0 files changed, 0 insertions, 0 deletions