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