| The structure of this module is worth noting. |
| |
| The main part is in vg_replace_malloc.c. It gets compiled into the tool's |
| 'preload' shared object, which goes into the client's area of memory, and |
| runs on the simulated CPU just like client code. As a result, it cannot |
| use any functions in the core directly; it can only communicate with the |
| core using client requests, just like any other client code. |
| |
| And yet it must call the tool's malloc wrappers. How does it know where |
| they are? The init function uses a client request which asks for the list |
| of all the core functions (and variables) that it needs to access. It then |
| uses a client request each time it needs to call one of these. |
| |
| This means that the following sequence occurs each time a tool that uses |
| this module starts up: |
| |
| - Tool does initialisation, including calling VG_(malloc_funcs)() to tell |
| the core the names of its malloc wrappers. These are stored in |
| VG_(tdict). |
| |
| - On the first allocation, vg_replace_malloc.c:init() calls the |
| GET_MALLOCFUNCS client request to get the names of the malloc wrappers |
| out of VG_(tdict), storing them in 'info'. |
| |
| - All calls to these functions are done using 'info'. |
| |
| This is a bit complex, but it's hard to see how it can be done more simply. |
| |
| |
