Changeset ac200c1 in rtems for cpukit/libmisc/cpuuse


Ignore:
Timestamp:
Sep 29, 2004, 8:34:01 PM (17 years ago)
Author:
Joel Sherrill <joel.sherrill@…>
Branches:
4.10, 4.11, 4.8, 4.9, 5, master
Children:
7452b85
Parents:
8d942067
Message:

2004-09-29 Joel Sherrill <joel@…>

  • configure.ac, libmisc/cpuuse/README, libmisc/stackchk/README, librpc/src/xdr/xdr_float.c, score/cpu/Makefile.am, score/include/rtems/score/mppkt.h: i960 obsoleted and all references removed.
File:
1 edited

Legend:

Unmodified
Added
Removed
  • cpukit/libmisc/cpuuse/README

    r8d942067 rac200c1  
    33#
    44
    5 This directory contains a stack bounds checker.  It provides two
     5This directory contains a CPU usage reported.  It provides two
    66primary features:
    77
    8    + check for stack overflow at each context switch
    9    + provides an educated guess at each task's stack usage
    10 
    11 The stack overflow check at context switch works by looking for
    12 a 16 byte pattern at the logical end of the stack to be corrupted.
    13 The "guesser" assumes that the entire stack was prefilled with a known
    14 pattern and assumes that the pattern is still in place if the memory
    15 has not been used as a stack.
    16 
    17 Both of these can be fooled by pushing large holes onto the stack
    18 and not writing to them... or (much more unlikely) writing the
    19 magic patterns into memory.
    20 
    21 This code has not been extensively tested.  It is provided as a tool
    22 for RTEMS users to catch the most common mistake in multitasking
    23 systems ... too little stack space.  Suggestions and comments are appreciated.
     8   + provides an educated guess at each task's CPU usage
    249
    2510NOTES:
    2611
    27 1.  Stack usage information is questionable on CPUs which push
    28     large holes on stack.
     121.  CPU usage is "docked" by a clock tick at each context switch.
    2913
    30 2.  The stack checker has a tendency to generate a fault when
    31     trying to print the helpful diagnostic message.  If it comes
    32     out, congratulations. If not, then the variable Stack_check_Blown_task
    33     contains a pointer to the TCB of the offending task.  This
    34     is usually enough to go on.
    3514
    36 FUTURE:
    37 
    38 1.  Determine how/if gcc will generate stack probe calls and support that.
    39 
    40 2.  Get accurate stack usage numbers on i960.. it pushes very large
    41     holes on the stack.
Note: See TracChangeset for help on using the changeset viewer.