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 30
