|
From: David M. <dm...@gm...> - 2005-12-23 09:30:22
|
Hi, Hope everyone is doing well. A colleague of mine, Dan Wilkerson ( ds...@ee...) and I are writing a tool to look at memory access patterns of applications, primarily on IA32. (We asked a question regarding this before on valgrind-devel -- thanks again for the help). Now we would like to match the current program counter value with each load and store. W= e are building this tool by modifying memcheck; right now we are using the valgrind 3.0.1 code as a base and plan to move to the SVN head when we have a stable tool. We have a way to obtain the current PC, but we are wondering if there is a better way. The way we currently obtain the PC is that we declare a global Addr lastPCAddr variable in mc_include.h . Then in MC_(instrument) in mc_translate.c, we instrument each Ist_IMark with a callback that updates the global lastPCAddr with the st->Ist.IMark.addr. Later, for loads and stores, we change the "slow" cases for handling load and store in mc_main.c to read the global lastPCAddr and print it out together with the load or store address. (We also set the VG_DEBUG_MEMORY to 2 so everything goes through the slow cases). The result seems to produce reasonable output on the programs we've tested so far, but we're not sure we understand everything. Our questions: 1) Will we have multi-threading problems with the global Addr lastPCAddr? 2) The include file in /VEX/pub/libvex_ir.h refers to the Ist_IMark as "optional." Does this mean that our strategy will sometimes fail to update the PC correctly in cases when the Ist_IMark is omitted, but the program advances one "instruction" (well, from the point of view of the original binary)? If so, in what cases would we expect this? is there a workaround? 3) The include file in /VEX/pub/libvex_guest_x86.h has an entry for a UInt guest_EIP. Is there a way for a tool to read this value directly? If you would like to see the code, copies of the files we modified are online at http://www.cs.berkeley.edu/~dmolnar/mc_include.h http://www.cs.berkeley.edu/~dmolnar/mc_translate.c http://www.cs.berkeley.edu/~dmolnar/mc_main.c Thanks very much, and hope you have a happy holidays, -David Molnar |
|
From: Julian S. <js...@ac...> - 2005-12-23 14:48:49
|
Without understanding all the details, I should point out that ... > 2) The include file in /VEX/pub/libvex_ir.h refers to the Ist_IMark as > "optional." ... this comment is wrong. The IMarks will always be present; omitting them would cause the profiling tools not to work. I suggest you derive your tool from the cachegrind implementation in 3.1.0 (not 3.0.X). Quite a bit of effort went into ensuring that cachegrind properly matches data and instruction addresses. J |
|
From: Julian S. <js...@ac...> - 2005-12-23 22:56:24
|
> I suggest you derive your tool from the cachegrind implementation in 3.1.0 > (not 3.0.X). Quite a bit of effort went into ensuring that cachegrind > properly matches data and instruction addresses. On reflection that's erroneous advice - no need to start from cachegrind. All you need to know is that: 1. To determine the PC to be associated with any memory reference you come across, inspect the most recently seen IMark. 2. On rare occasions you will find some IR statements which precede the first IMark in the block. These are for V's own administrative purposes and do not reflect work that the program would actually have done. You should copy these verbatim to the output, and start instrumentation proper at the first IMark. cachegrind and lackey in 3.1.0 have instrumentation functions which behave in this way. J |