|
From: David M. <dm...@gm...> - 2008-03-26 08:56:16
|
Hi everyone, Hope you are doing well, and thank you for your work on Valgrind. I have been using it happily for some months now as an invaluable aid to my research. I have a question I hope has not already been answered and which I haven't found the answer so far via searching the archives, if I missed something please let me know. Part of my work requires inspecting the arguments to library function calls such as memcpy, malloc, realloc, etc. to see if they meet certain criteria. The Valgrind function interception mechanism works well for this and other dynamically loaded functions for looking at the concrete values of these arguments. Indeed memcheck already uses it to look at the high bit of arguments to malloc/realloc and complains if it is set. The problem is that I *also* would like to know the name of the VEX IR basic block and IR registers or temporary variables which hold these arguments during execution at the post-instrumentation phase (i.e. the phase at which the VEX BB is passed to the tool). That is, if the guest calls malloc, I'd like to know during instrumentation that the current BB passed to my tool is malloc, that guest register X corresponds to argument 1, etc. (I am happy to explain in detail why I'd like this, but it's basically because I'm converting VEX IR on the fly into constraints which I attempt to solve for generating new inputs, and I want constraints that talk about function arguments.) The approach I have thought of so far is this: 1) Collect a table of the EIPs for the entry points to each function of interest (e.g. using the debug symbol parsing module), plus the calling convention used for each function 2) At instrumentation time, check each EIP in the basic block to see if the EIP is in the table 3) If so, hard-code instrumentation according to the calling convention, e.g. have constraints that talk about IR register X for the first argument I've been looking through the Callgrind sources for better understanding of 1) and 3), which is helpful but doesn't seem to be focused on the arguments as much. Has anyone else done this already or could suggest a better approach? Thanks, -David Molnar |
|
From: Nicholas N. <nj...@cs...> - 2008-03-26 22:05:41
|
On Wed, 26 Mar 2008, David Molnar wrote: > Part of my work requires inspecting the arguments to library function calls > such as memcpy, malloc, realloc, etc. to see if they meet certain criteria. > The Valgrind function interception mechanism works well for this and other > dynamically loaded functions for looking at the concrete values of these > arguments. Indeed memcheck already uses it to look at the high bit of > arguments to malloc/realloc and complains if it is set. > > The problem is that I *also* would like to know the name of the VEX IR basic > block and IR registers or temporary variables which hold these arguments > during execution at the post-instrumentation phase (i.e. the phase at which > the VEX BB is passed to the tool). That is, if the guest calls malloc, I'd > like to know during instrumentation that the current BB passed to my tool is > malloc, that guest register X corresponds to argument 1, etc. (I am happy to > explain in detail why I'd like this, but it's basically because I'm > converting VEX IR on the fly into constraints which I attempt to solve for > generating new inputs, and I want constraints that talk about function > arguments.) > > The approach I have thought of so far is this: > > 1) Collect a table of the EIPs for the entry points to each function of > interest (e.g. using the debug symbol parsing module), plus the calling > convention used for each function > 2) At instrumentation time, check each EIP in the basic block to see if the > EIP is in the table > 3) If so, hard-code instrumentation according to the calling convention, e.g. > have constraints that talk about IR register X for the first argument Are you aware of pub_tool_debuginfo.h:VG_(get_fnname_if_entry) ? It will help with (1) and (2). Other than that... matching up arguments with VEX entities is difficult, because you do have to know the calling conventions, etc. Valgrind doesn't have any general support for it, amd the fact that you're using function replacement might complicate things, but I'm not sure about that. Overall, it sounds to me like you understand the problem as well as anyone else -- good luck! Nick |
|
From: David M. <dm...@gm...> - 2008-03-27 01:51:15
|
On Wed, Mar 26, 2008 at 3:05 PM, Nicholas Nethercote < nj...@cs...> wrote: > > Are you aware of pub_tool_debuginfo.h:VG_(get_fnname_if_entry) ? It will > help with (1) and (2). > No, I was not aware of that. Thank you for the pointer! I'd started to write this myself but this is better. > > Other than that... matching up arguments with VEX entities is difficult, > because you do have to know the calling conventions, etc. Valgrind > doesn't > have any general support for it, amd the fact that you're using function > replacement might complicate things, but I'm not sure about that. > OK, that is what I was afraid of. I can try it without the function replacement first, since if I can figure out the calling convention I can inspect the concrete values of the arguments via instrumentation instead of through interposition. That may avoid some complications. The one piece of good news is that for now I only need to make it work for 32-bit Linux/x86. So that very slightly limits the scope. > > Overall, it sounds to me like you understand the problem as well as anyone > else -- good luck! > Thanks, appreciate it. -David Molnar |