mirror of
https://github.com/ioacademy-jikim/debugging
synced 2025-06-08 08:26:14 +00:00
30 lines
1.2 KiB
Plaintext
30 lines
1.2 KiB
Plaintext
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.
|
|
|
|
|