|
From: Stephen M.
|
JF> Rex Walburn wrote: RW> Hi RW> I tried using VG_(describe_addr) and it returns a value (null) for RW> every address. >>>>> "JF" == Jeremy Fitzhardinge <je...@go...> writes: JF> Only the stabs reader extracts enough type information for JF> describe_addr to work; nobody has put the effort into the DWARF JF> reader yet. If you compile with -gstabs, you might get more JF> useful results (though I suspect this code has been untested for a JF> while, so you may get some explosions instead). You might also want to try looking at the "Kvasir" tool that our research group has implemented. We had a similar problem of wanting to have detailed variable information along with per-instruction operation tracking: in our case, we wanted to print the values of all the accessible variables at the entrance and exit of functions, but to use Memcheck's information to know which memory locations had valid data. Rather than building on Valgrind's existing debugging information reading code, we made our own by modifying the "readelf" tool from the GNU Binutils (unfortunately, we didn't find out about libdwarf until too late); this just supports DWARF, but we read all sorts of information about global variables, parameters, arrays, and structs. We use this information to find the address(es) for each variable we're interested in, and then print their contents. You can get the source for Kvasir as part of the Daikon distribution, from http://pag.csail.mit.edu/daikon/download/. At the moment, it comes as a tool along with a minimally modified version of Valgrind 2.2.0, and includes hacked versions of Memcheck and readelf inside (it's all GPLed). In the current version, the code for reading the debugging information, traversing the sets of variables, and printing out their contents in our specific trace format aren't as well separated as we'd like, but if you don't mind reusing by cut and paste, you might find a lot of code you could take advantage of. -- Stephen |