eclipse-threadx/threadx

ThreadX provides focused diagnostics such as optional stack checking, API object validation, memory-pool information, event tracing, and module memory protection. It does not provide a general mechanism comparable to AddressSanitizer for detecting out-of-bounds access, use-after-free, or related memory errors. Following #319, I want this investigation to establish whether such support is practical and what a focused implementation would cover. The investigation needs to determine: Which fault classes are in scope: stack, pool, global, and arbitrary-buffer overflows; use-after-free; double release; leaks; and invalid object access. Which environments can be supported: the Linux simulation port, embedded GCC or Clang builds, other supported compilers, emulators, and physical targets. Whether compiler sanitizer runtimes can be used without introducing prohibited dependencies, unacceptable licensing constraints, or assumptions that do not hold on bare-metal targets. Whether ThreadX-specif

Is your feature request related to a problem? Please describe. Eclipse ThreadX currently offers SMP ports for Cortex-A, Cortex-R8, MIPS interAptiv and ARC HS, plus the Linux and Win64 simulators. There is no SMP support for Armv8-R, even though we already ship a uniprocessor Cortex-R52 port in ports/cortex_r52. That leaves a gap for users who need MPU-based, hard real-time, safety-oriented multicore. This came up in #229, where @AJIOB asked for Cortex-M SMP support on a dual Cortex-M4 subsystem. Cortex-M is not a realistic target for SMP, because Armv7-M and Armv8-M provide no core identity register, no architected inter-core interrupt and no shared exclusive monitor, so every one of those would be SoC-specific glue. Armv8-R is the architecture that actually answers that need, so this issue splits the tractable half of #229 out into its own request. Credit for raising the underlying use case goes to @AJIOB. Describe the solution you'd like An SMP port for Armv8-R, starting with Cortex-

Summary The ARMv8-A ThreadX ports require the application to run with SPSel = 0, so that SP_EL0 is used for thread stacks and for the system stack. This requirement is not stated anywhere in prose. It is only implied by the example startup.S and vectors.S files, which most users replace with their own board bring-up code. Background Two different conventions coexist in the tree: ports/cortex_a5x targets EL3, never touches SPSel, stays on SP_ELx, and builds the initial SPSR with M[0] set (0x5/0x9/0xD, i.e. ELxh). Every later ARMv8-A port — A34, A35, A53, A55, A57, the A6x and A7x families, plus the SMP and module variants — runs with SPSel = 0 and builds the initial SPSR with M[0] clear (0x4/0x8/0xC, i.e. ELxt). SP_ELx is only a transient exception-entry stack. The second convention is enforced in three places that must agree: startup.S executes MSR SPSel, #0 before entering ThreadX, irqFirstLevelHandler in vectors.S executes MSR SPSel, 0 before calling _tx_thread_context_save, an

Split out of #181, originally reported by @mwolosewicz and discussed with @goldscott and @ascheurer. That thread mixed a concrete bug (addressed in #701) with this feature request, so I am tracking the feature on its own. TX_ENABLE_STACK_CHECKING does not support module threads today. _txm_module_manager_thread_create prepares the module thread stack for stack checking because it was derived from _tx_thread_create, which makes it look supported, but the kernel stack allocated for user mode threads is not prepared and the check does not survive the stack switch. Two things stand in the way. First, the kernel stack carries no guard pattern beyond tx_thread_module_kernel_stack_end, so TX_THREAD_STACK_CHECK reads outside the allocated block and reports a spurious error, which is the crash @mwolosewicz originally hit. Second, and more fundamentally, a user mode module thread owns two stacks. tx_thread_schedule swaps tx_thread_stack_start, tx_thread_stack_end and tx_thread_stack_size over to

scripts/check_clang.sh links every example build it can drive, and reports the ones it cannot. Three ports remain on that report: no script driver, so outside this stage: cortex_a5_smp cortex_a7_smp cortex_a9_smp Closing this empties that line. A check that permanently prints known exceptions teaches people to skim past it, so zero is worth reaching. What is missing Nothing much, which is what makes this a good first issue. All three examples are already complete — startup.S, sample_threadx.ld, sample_threadx.c, and the MP_GIC / MP_Mutexes / MP_SCU / MP_PrivateTimer / v7 drivers are all present under ports_smp/<core>/gnu/example_build/. They also already have build_threadx.bat and build_threadx_sample.bat, which name every source and every flag. What they lack is the .sh counterparts, so nothing on Linux or in CI can build them: ports_smp/cortex_a5_smp/gnu/example_build/ ports_smp/cortex_a7_smp/gnu/example_build/ ports_smp/cortex_a9_smp/gnu/example_build/ How to do it Follow the p