]> rtime.felk.cvut.cz Git - l4.git/blob - l4/pkg/valgrind/src/valgrind-3.6.0-svn/docs/internals/m_replacemalloc.txt
Inital import
[l4.git] / l4 / pkg / valgrind / src / valgrind-3.6.0-svn / docs / internals / m_replacemalloc.txt
1 The structure of this module is worth noting.
2
3 The main part is in vg_replace_malloc.c.  It gets compiled into the tool's
4 'preload' shared object, which goes into the client's area of memory, and
5 runs on the simulated CPU just like client code.  As a result, it cannot
6 use any functions in the core directly;  it can only communicate with the
7 core using client requests, just like any other client code.
8
9 And yet it must call the tool's malloc wrappers.  How does it know where
10 they are?  The init function uses a client request which asks for the list
11 of all the core functions (and variables) that it needs to access.  It then
12 uses a client request each time it needs to call one of these.
13
14 This means that the following sequence occurs each time a tool that uses
15 this module starts up:
16
17  - Tool does initialisation, including calling VG_(malloc_funcs)() to tell
18    the core the names of its malloc wrappers.  These are stored in
19    VG_(tdict).
20
21  - On the first allocation, vg_replace_malloc.c:init() calls the
22    GET_MALLOCFUNCS client request to get the names of the malloc wrappers
23    out of VG_(tdict), storing them in 'info'.
24
25  - All calls to these functions are done using 'info'.
26
27 This is a bit complex, but it's hard to see how it can be done more simply. 
28
29