Changeset ac200c1 in rtems for cpukit/libmisc/cpuuse

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:

• cpukit/libmisc/cpuuse/README (modified) (1 diff)

cpukit/libmisc/cpuuse/README

@@ -3 +3 @@
 #
 
-This directory contains a stack bounds checker.  It provides two
+This directory contains a CPU usage reported.  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.
+   + provides an educated guess at each task's CPU usage
 
 NOTES:
 
-1.  Stack usage information is questionable on CPUs which push
-    large holes on stack.
+1.  CPU usage is "docked" by a clock tick at each context switch.
 
-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.