OpenCores
URL https://opencores.org/ocsvn/openrisc_2011-10-31/openrisc_2011-10-31/trunk

Subversion Repositories openrisc_2011-10-31

[/] [openrisc/] [trunk/] [rtos/] [rtems/] [c/] [src/] [libmisc/] [stackchk/] [README] - Blame information for rev 218

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 30 unneback
#
2
#  $Id: README,v 1.2 2001-09-27 12:01:46 chris Exp $
3
#
4
 
5
Introduction
6
============
7
 
8
This directory contains a stack bounds checker.  It provides two
9
primary features:
10
 
11
   + check for stack overflow at each context switch
12
   + provides an educated guess at each task's stack usage
13
 
14
Enabling
15
========
16
 
17
Add the stack checker extension to the initial user extension set.
18
If using confdefs.h to build your configuration table, this is
19
as simple as adding -DSTACK_CHECK_ON to the gcc command line which
20
compiles the file defining the configuration table.  In the RTEMS
21
test suites and samples, this is always init.c
22
 
23
Background
24
==========
25
 
26
The stack overflow check at context switch works by looking for
27
a 16 byte pattern at the logical end of the stack to be corrupted.
28
The "guesser" assumes that the entire stack was prefilled with a known
29
pattern and assumes that the pattern is still in place if the memory
30
has not been used as a stack.
31
 
32
Both of these can be fooled by pushing large holes onto the stack
33
and not writing to them... or (much more unlikely) writing the
34
magic patterns into memory.
35
 
36
This code has not been extensively tested.  It is provided as a tool
37
for RTEMS users to catch the most common mistake in multitasking
38
systems ... too little stack space.  Suggestions and comments are appreciated.
39
 
40
NOTES:
41
 
42
1.  Stack usage information is questionable on CPUs which push
43
    large holes on stack.
44
 
45
2.  The stack checker has a tendency to generate a fault when
46
    trying to print the helpful diagnostic message.  If it comes
47
    out, congratulations. If not, then the variable Stack_check_Blown_task
48
    contains a pointer to the TCB of the offending task.  This
49
    is usually enough to go on.
50
 
51
FUTURE:
52
 
53
1.  Determine how/if gcc will generate stack probe calls and support that.
54
 
55
2.  Get accurate stack usage numbers on i960.. it pushes very large
56
    holes on the stack.

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.