1The structure of this module is worth noting. 2 3The 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 5runs on the simulated CPU just like client code. As a result, it cannot 6use any functions in the core directly; it can only communicate with the 7core using client requests, just like any other client code. 8 9And yet it must call the tool's malloc wrappers. How does it know where 10they are? The init function uses a client request which asks for the list 11of all the core functions (and variables) that it needs to access. It then 12uses a client request each time it needs to call one of these. 13 14This means that the following sequence occurs each time a tool that uses 15this 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 27This is a bit complex, but it's hard to see how it can be done more simply. 28 29 30