njn | 717cde5 | 2005-05-10 02:47:21 +0000 | [diff] [blame] | 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 |
njn | bd8f1c4 | 2005-07-19 03:38:09 +0000 | [diff] [blame] | 6 | use any functions in the core directly; it can only communicate with the |
njn | 717cde5 | 2005-05-10 02:47:21 +0000 | [diff] [blame] | 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 | |