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 the kernel stack on every kernel entry, but it does not swap tx_thread_stack_highest_ptr. A module thread suspended in kernel mode leaves a kernel stack address in highest_ptr, and the next check performed against the module stack trips the highest_ptr < stack_start test.
A complete implementation therefore needs the extra tx_thread_module_stack_highest_ptr member @goldscott proposed, a guard pattern reserved at the top of the kernel stack, and matching changes in all twenty-six module tx_thread_schedule assembly files, which address the thread control block through hardcoded offsets. Two limitations @goldscott noted still apply: only the manager can perform the check and handle the error, and a module can manipulate its own stack at will, so the result is advisory.
This needs hardware validation on at least one Cortex-M and one Cortex-A module port before it can land. There is currently no module coverage in CI.
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_CHECKINGdoes not support module threads today._txm_module_manager_thread_createprepares 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, soTX_THREAD_STACK_CHECKreads 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_scheduleswapstx_thread_stack_start,tx_thread_stack_endandtx_thread_stack_sizeover to the kernel stack on every kernel entry, but it does not swaptx_thread_stack_highest_ptr. A module thread suspended in kernel mode leaves a kernel stack address inhighest_ptr, and the next check performed against the module stack trips thehighest_ptr < stack_starttest.A complete implementation therefore needs the extra
tx_thread_module_stack_highest_ptrmember @goldscott proposed, a guard pattern reserved at the top of the kernel stack, and matching changes in all twenty-six moduletx_thread_scheduleassembly files, which address the thread control block through hardcoded offsets. Two limitations @goldscott noted still apply: only the manager can perform the check and handle the error, and a module can manipulate its own stack at will, so the result is advisory.This needs hardware validation on at least one Cortex-M and one Cortex-A module port before it can land. There is currently no module coverage in CI.