Changes between Version 11 and Version 12 of Tools/Memory Checker


Ignore:
Timestamp:
Mar 29, 2010, 11:02:48 AM (14 years ago)
Author:
Joel Porquet
Comment:

typos

Legend:

Unmodified
Added
Removed
Modified

  • Tools/Memory Checker

    v11 v12  
    44= Overview =
    55
    6 Tracking software bugs is not an easy task and working with super user privileged code or without a memory management unit may still increase difficulty. Some hard to find bugs may stay hidden under certain conditions and suddenly appears depending on undefined memory content for instance. Sometime unexpected embedded software crash are simply due to stack overflow.
     6Tracking software bugs is not an easy task and working with super user privileged code or without a memory management unit may even increase difficulty. Some hard-to-find bugs may stay hidden under certain conditions and suddenly appear depending on undefined memory content for instance. Sometimes, unexpected embedded software crashes are simply due to stack overflow.
    77
    8 The Memory checker tool can help to track these problems down by watching processor memory access and keeping an up to date representation of running contexts and memory allocation map. It's able to report memory accesses which are valid for hardware but invalid from a software point of view given current software state. It is similar to the [http://valgrind.org/ valgrind] memory checker tool available on GNU/Linux and MacOs, but is aimed at checking operating system level memory operations rather than Unix user process memory operations.
     8The Memory checker tool can help to track these problems down by watching processor memory accesses and keeping an up-to-date representation of running contexts and memory allocation map. It's able to report memory accesses which are valid for hardware but invalid from a software point of view given current software state. It is similar to the [http://valgrind.org/ valgrind] memory checker tool available on GNU/Linux and MacOs, but aims at checking Operating System level memory operations rather than Unix user process memory operations.
    99
    1010Like the [wiki:Tools/GdbServer Gdb Server], the Memory checker contains no processor-specific code and can be used to manage any Soclib processor model using the generic [wiki:Component/Iss2Api Iss2 interface]. It is implemented as an Iss wrapper class.
    1111
    12 When the Memory checker is in use, it internally traces 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 for each contexts and allocation ranges. The [http://www.mutekh.org/ MutekH] operating system has support for the Memory checker.
     12When the Memory checker is in use, it internally traces 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 for each contexts and allocation ranges. The [http://www.mutekh.org/ MutekH] Operating System has support for the Memory checker.
    1313
    1414= What is being checked =
    … …  
    1717
    1818Context and stacks related checks:
    19  * The stack pointer register must stay in range given by the operating system for each software context in use.
    20  * The frame pointer register (if any) must stay in range given by the operating system for each software context in use.
     19 * The stack pointer register must stay in the range given by the Operating System for each software context in use.
     20 * The frame pointer register (if any) must stay in the range given by the Operating System for each software context in use.
    2121 * Contexts stack ranges can not overlap (checked on context creation).
    22  * Stack range must be in allocated memory at context creation (as soon as allocation checks are enabled).
     22 * Stack ranges must be in allocated memory at context creation (as soon as allocation checks are enabled).
    2323 * The stack memory is marked as non-initialized when a new execution context is created.
    2424 * The stack memory is always considered as non-initialized below the stack pointer.
    … …  
    8888Some platforms shipped with SoCLib uses the Memory checker, have a look to the [source:trunk/soclib/soclib/platform/topcells/caba-vgmn-mutekh_soclib_tutorial] source code.
    8989
    90 = Using an instrumented operating system =
     90= Using an instrumented Operating System =
    9191
    92 The running operating system must communicate with the Memory checker to report information about context creation (stack range), and memory-allocator operations. This is done through read/write operations in specific memory locations which are intercepted by the Memory checker and not forwarded to the rest of the platform.
     92The running Operating System must communicate with the Memory checker to report information about context creation (stack range), and memory-allocator operations. This is done through read/write operations in specific memory locations which are intercepted by the Memory checker and not forwarded to the rest of the platform.
    9393
    94 Currently the only known supported operating system is [http://www.mutekh.org MutekH] with Mips32, Arm and Powerpc processors.
    95 Adding Memory Checker support to an other operating system is a trivial task though.
     94Currently the only known supported Operating System is [http://www.mutekh.org MutekH] with Mips32, Arm and Powerpc processors.
     95Adding Memory Checker support to an other Operating System is a trivial task though.
    9696
    9797== MutekH example ==
    … …  
    110110
    111111Note:
    112  * An instrumented operating system can not be used without the ISS Memory checker module as memory accesses won't be intercepted and may cause bus error or side effects.
     112 * An instrumented Operating System can not be used without the ISS Memory checker module as memory accesses won't be intercepted and may cause bus error or side effects.
    113113 * 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.
    114114 * The Memory checker registers bank is protected by a magic value and is unlikely to be modified by an other running software.
    … …  
    119119
    120120 * The `T` flag can be used to raise a trap exception on suspicious memory access. This trap can be caught by the [wiki:Tools/GdbServer Gdb Server] tool.
    121  * The `R` flag can be added to report all allocator related operations reported by the operating system.
     121 * The `R` flag can be added to report all allocator related operations reported by the Operating System.
    122122 * The `C` flag can ba added to report all execution contexts creation and deletion operations.
    123123 * The `S` flag can be added to report all context switch operations.