Changes between Version 8 and Version 9 of Tools/Memory Checker


Ignore:
Timestamp:
Mar 29, 2010, 1:52:49 AM (14 years ago)
Author:
becoulet
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Tools/Memory Checker

    v8 v9  
    1 = Memory access checker for Soclib =
    21
    3 The Memory checker tool is a software memory access debugger for !SoClib.
     2The Memory checker is a memory and context debugger tool for SoCLib.
    43
    54= Overview =
    65
    7 The Memory checker is able to perform several analysis on memory accesses performed by the running software to track software bugs. Access to uninitialized or freed data and stack overflow are examples of reported behaviors. It acts as the [http://valgrind.org/ valgrind] memory checker tool found on some UNIX.
     6Tracking 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.
    87
    9 == Implementation ==
     8The 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.
    109
    1110Like 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.
    1211
    13 When the Memory checker is in use, it 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 and allocation ranges. The [http://www.mutek.fr/ MutekH] operating system is working with 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.
    1413
    15 === What is being checked ===
     14= What is being checked =
    1615
    1716All memory accesses are monitored and checked for read to non previously initialized (written) words.
    … …  
    2524 * The stack memory is always considered as non-initialized below the stack pointer.
    2625 * Memory r/w accesses in stack can not occur below the stack pointer.
     26 * Switch to invalidated contexts.
    2727
    2828Memory allocation and region checks:
    … …  
    3434 * Allocation are only allowed in free memory.
    3535
    36 === Suspicious memory access reporting ===
     36= What is being reported =
    3737
    38 Suspicious memory accesses produce a message on simulator `stdout` stream. This simulation is not stopped though.
     38The default behavior is to report each suspicious memory access with a message on simulator output.
    3939
    40 An exception can be reported to an optional `GdbServer` module to stop processor execution when a suspicious memory access happened. This enables further analysis 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.
     40More diagnostics messages can be reported, see configuration section below.
    4141
    42 = Usage =
     42A trap exception can be reported to an optional [wiki:Tools/GdbServer Gdb Server] module to stop processor execution when a suspicious memory access happened.
     43This allows further analysis 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.
    4344
    44 == Adding Memory checker support to your platform ==
     45= Adding Memory checker support to your SoCLib platform =
    4546
    46 Adding the !GdbServer to your topcell is easy. First include the header:
     47== Declaration ==
     48
     49Adding the Memory checker to your topcell is easy. First include the header:
    4750
    4851{{{
    … …  
    6770}}}
    6871
    69 == Initializer description ==
     72== Initialization ==
    7073
    7174The line:
    … …  
    7881 * `"tty,ramdac_ctrl"` a list of exclusions in the `!MappingTable` segment's names. You should ignore any segment mapped to a device.
    7982
    80 == Using an instrumented operating system ==
     83Some 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.
     84
     85= Using an instrumented operating system =
    8186
    8287The 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.
    8388
    84 Currently the only known supported operating system is [http://www.mutek.fr MutekH] with Mips32 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.
     89Currently the only known supported operating system is [http://www.mutekh.org MutekH] with Mips32, Arm and Powerpc processors.
     90Adding Memory Checker support to an other operating system is a trivial task though.
     91
     92== MutekH example ==
     93
     94Here is an example of MutekH build invocation for SoCLib Mips32 with Memory checker support:
     95
     96{{{
     97make CONF=examples/hello/config BUILD=soclib-mips32el:pf-tutorial:memcheck
     98}}}
     99
     100The kernel can be use with the caba-vgmn-mutekh_kernel_tutorial SoCLib platform:
     101
     102{{{
     103./system.x mips32el:4 .../mutekh/hello-soclib-mips32el.out
     104}}}
    85105
    86106Note:
    … …  
    89109 * The Memory checker registers bank is protected by a magic value and is unlikely to be modified by an other running software.
    90110
     111= Configuration =
     112
     113The Memory checker tool behavior can be configured through the use of the `SOCLIB_MEMCHK` environment variable. This variable may contains some flag letters:
     114
     115 * 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.
     116 * The `R` flag can be added to report all allocator related operations reported by the operating system.
     117 * The `C` flag can ba added to report all execution contexts creation and deletion operations.
     118 * The `S` flag can be added to report all context switch operations.
     119 * The `I` flag can be added to display all processor registers on each errors.
     120 * The `A` flag can be added to display offending memory access details.
     121
     122Here is an example invocation to obtain an interlaced Memory checker and `GdbServer` function calls trace, with trap exception and wait for gdb client connection on error:
     123
     124{{{
     125SOCLIB_MEMCHK=T SOCLIB_GDB=SC ./system.x ......
     126}}}
     127
    91128= Output example =
    92129
    93 With the following code using an unitialized stack variable to set a global:
     130This is an example output of running a MutekH Memory checker enabled kernel with a buggy application:
    94131
    95 {{{
    96 int foo;
     132[[Image(memcheck.png,nolink)]]
    97133
    98 void _main(void*unused)
    99 {
    100   int bar;
    101   foo = bar;
     134Each error is reported along with information about current running context and memory region associated with the error.
    102135
    103   // ...
    104 }
    105 }}}
    106 
    107 We get the following output:
    108 
    109 {{{
    110 cache0 error:
    111  access to uninitialized word
    112  at PC=[@0x60100564: (_main + 0x8)]
    113     SP=[@0x62207fb8: (context_stack + 0x7f94)]
    114     last Dreq: <DataReq mode MODE_KERNEL   valid type DATA_READ @ 0x62207fc8 wdata 0 be 0xf> [@0x62207fc8: (context_stack + 0x7fa4)]
    115 }}}
    116