Changes between Version 1 and Version 2 of Tools/Memory Checker

Timestamp:

Jan 29, 2009, 8:09:07 PM (15 years ago)

Author:

becoulet

Comment:

--

Tools/Memory Checker

@@ -9 +9 @@
 == Implementation ==
 
-Like the GdbServer, the Memory checker contains no processor specific code and can be used to manage any Soclib processor model using the generic Iss interface. It is implemented as an Iss wrapper class. When the Memory checker is in use, it intercepts all events between the processor Iss model and the Soclib platform. The running operating system must be instrumented slightly to let the Memory checker be aware of valid stack ranges and allocation ranges. The Mutekh operating system is working with the Memory checker.
+Like the GdbServer, the Memory checker contains no processor specific code and can be used to manage any Soclib processor model using the generic Iss interface. It is implemented as an Iss wrapper class. When the Memory checker is in use, it intercepts all events between the processor Iss model and the Soclib platform. The running operating system must be instrumented slightly to let the Memory checker be aware of valid stack ranges and allocation ranges. The [http://www.mutek.fr MutekH] operating system is working with the Memory checker.
 
 === What is being checked ===
 
-All memory access are monitored and checked for read access to non previously initialized (written) words.
+All memory accesses are monitored and checked for read to non previously initialized (written) words.
 
 Context and stacks related checks:
  * The stack pointer register must stay in range given by the operating system for each software context in use.
  * The frame pointer register (if any) must stay in range given by the operating system for each software context in use.
- * Context stack range can not overlap (checked on context creation)
- * Stack range must be in allocated memory at context creation (when allocation checks are enabled).
+ * Contexts stack ranges can not overlap (checked on context creation).
+ * Stack range must be in allocated memory at context creation (as soon as allocation checks are enabled).
  * The stack memory is marked as non-initialized when a new execution context is created.
- * The stack memory is marked as non-initialized below the stack pointer.
+ * The stack memory is always considered as non-initialized below the stack pointer.
  * Memory r/w accesses can not occur below the stack pointer.
 
 Memory allocation and region checks:
- * Write accesses can not occur in readonly preloaded sections.
- * Preloaded sections are marked as uninitialize when appropriate.
- * Memory is marked as uninitialized on `malloc()`.
- * Memory is marked as uninitialized on `free()`.
+ * Write accesses can not occur in read only preloaded sections.
+ * Preloaded sections are marked as uninitialized when appropriate.
+ * Memory is marked as uninitialized on `malloc()` invocation.
+ * Memory is marked as uninitialized on `free()` invocation.
  * Memory r/w accesses can not occur in freed memory.
  * Allocation are only allowed in free memory.
@@ -34 +34 @@
 === Suspicious memory access reporting ===
 
-Suspicious memory access produce a message on running platform stdout stream.
+Suspicious memory accesses produce a message on simulator `stdout` stream. This simulation is not stopped anyway.
 
-An exception can be reported if working with the GdbServer module to stop the processors execution. This enables further analisys of buggy software when a suspicious memory access happend. When using the Memory checker with the GdbServer, the Memory checker must be close to the processor.
+An exception can be reported to an optional GdbServer module to stop processors execution when a suspicious memory access happend. This enables further analisys of buggy software. When using the Memory checker with the GdbServer, the Memory checker must wrap the processor directly and must be wrapped in the GdbServer.
 
 == Usage ==
@@ -48 +48 @@
 }}}
 
-Then call the init function with mapping table and loader and replace processor instantiation:
+Then call the init function with mapping table and loader parameters and replace processor instantiation:
 
 {{{
@@ -69 +69 @@
 The running operating system must communicate with the Memory checker to report information about context creation, stack range and allocator operations. This is done through read/write access to specifc memory locations which are intercepted by the Memory checker and not forwarded to the rest of the platform.
 
-Currently the only known supported operating system is Mutekh with mips processor. Other processors are partially supported, only memory allocation checks are performed. To use the memory checker with Mutekh, simply add the `CONFIG_SOCLIB_MEMCHECK` configuration token to your configuration file.
+Currently the only known supported operating system is [http://www.mutek.fr MutekH] with Mips processor. Other processors are partially supported, only memory allocation checks are performed. To use the memory checker with MutekH, simply add the `CONFIG_SOCLIB_MEMCHECK` configuration token to your configuration file.
 
 Note:
  * An instrumented operating system can not be used without the ISS Memory checker module as memory access won't be intercepted and may cause bus error or side effects.
- * The default base address for the register bank of the memory checker is 0x00004200. This address can be changed but must stay small to fit on some processor instruction immediate field.
- * The register bank is protected by a magic value and as almost no chance being modified by an other running software.
+ * The default base address for the register bank of the memory checker is 0x00004200. This address can be changed but must stay close to 0 to fit on some processor instruction immediate field. You should consider this if you already have components at these addresses.
+ * The Memory checker registers bank is protected by a magic value and has almost no chance being modified by an other running software.