forked from Imagelibrary/rtems
2afb22b7e1
A speciality of the RTEMS build system was the make preinstall step. It copied header files from arbitrary locations into the build tree. The header files were included via the -Bsome/build/tree/path GCC command line option. This has at least seven problems: * The make preinstall step itself needs time and disk space. * Errors in header files show up in the build tree copy. This makes it hard for editors to open the right file to fix the error. * There is no clear relationship between source and build tree header files. This makes an audit of the build process difficult. * The visibility of all header files in the build tree makes it difficult to enforce API barriers. For example it is discouraged to use BSP-specifics in the cpukit. * An introduction of a new build system is difficult. * Include paths specified by the -B option are system headers. This may suppress warnings. * The parallel build had sporadic failures on some hosts. This patch removes the make preinstall step. All installed header files are moved to dedicated include directories in the source tree. Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc, etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g. erc32, imx, qoriq, etc. The new cpukit include directories are: * cpukit/include * cpukit/score/cpu/@RTEMS_CPU@/include * cpukit/libnetworking The new BSP include directories are: * bsps/include * bsps/@RTEMS_CPU@/include * bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include There are build tree include directories for generated files. The include directory order favours the most general header file, e.g. it is not possible to override general header files via the include path order. The "bootstrap -p" option was removed. The new "bootstrap -H" option should be used to regenerate the "headers.am" files. Update #3254.
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:
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.