Sebastian Huber
3b061c5c44
The briefs of the libmisc files named a topic, not the content of the file. Four shell briefs named the wrong command. The file main_blksync.c said "RM Shell Command Implementation". The files main_id.c, main_time.c and shellconfig.c named ls and debugrfs. Four string conversion sources named the conversion, for example "Convert String to Unsigned Long". Write every brief in the style of the tree. A source brief starts with "This source file contains". A command brief names the command the file provides. A header brief starts with "This header file provides". Put @file, @ingroup and @brief in this order in every block. Updates #5717. Assisted-by: Claude:claude-opus-5 claude-code Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Introduction
This directory contains a stack bounds checker. It provides two primary features:
- check for stack overflow at each context switch
- provides an educated guess at each task's stack usage
Enabling
Add the stack checker extension to the initial user extension set. If using confdefs.h to build your configuration table, this is as simple as adding -DSTACK_CHECK_ON to the gcc command line which compiles the file defining the configuration table. In the RTEMS test suites and samples, this is always init.c
Background
The stack overflow check at context switch works by looking for a 16 byte pattern at the logical end of the stack to be corrupted. The "guesser" assumes that the entire stack was prefilled with a known pattern and assumes that the pattern is still in place if the memory has not been used as a stack.
Both of these can be fooled by pushing large holes onto the stack and not writing to them... or (much more unlikely) writing the magic patterns into memory.
This code has not been extensively tested. It is provided as a tool for RTEMS users to catch the most common mistake in multitasking systems ... too little stack space. Suggestions and comments are appreciated.
NOTES:
-
Stack usage information is questionable on CPUs which push large holes on stack.
-
The stack checker has a tendency to generate a fault when trying to print the helpful diagnostic message. If it comes out, congratulations. If not, then the variable Stack_check_Blown_task contains a pointer to the TCB of the offending task. This is usually enough to go on.
FUTURE:
- Determine how/if gcc will generate stack probe calls and support that.