forked from Imagelibrary/rtems
3a4ae6c210
Configuration Table Template file added and all tests modified to use this. All gvar.h and conftbl.h files removed from test directories. Configuration parameter maximum_devices added. Core semaphore and mutex handlers added and RTEMS API Semaphore Manager updated to reflect this. Initialization sequence changed to invoke API specific initialization routines. Initialization tasks table now owned by RTEMS Tasks Manager. Added user extension for post-switch. Utilized user extensions to implement API specific functionality like signal dispatching. Added extensions to the System Initialization Thread so that an API can register a function to be invoked while the system is being initialized. These are largely equivalent to the pre-driver and post-driver hooks. Added the Modules file oar-go32_p5, modified oar-go32, and modified the file make/custom/go32.cfg to look at an environment varable which determines what CPU model is being used. All BSPs updated to reflect named devices and clock driver's IOCTL used by the Shared Memory Driver. Also merged clock isr into main file and removed ckisr.c where possible. Updated spsize to reflect new and moved variables. Makefiles for the executive source and include files updated to show break down of files into Core, RTEMS API, and Neither. Header and inline files installed into subdirectory based on whether logically in the Core or a part of the RTEMS API.
#
# $Id$
#
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
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:
1. Stack usage information is questionable on CPUs which push
large holes on stack.
2. 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:
1. Determine how/if gcc will generate stack probe calls and support that.
2. Get accurate stack usage numbers on i960.. it pushes very large
holes on the stack.