|
From: Stephen M.
|
>>>>> "NN" == Nicholas Nethercote <nj...@ca...> writes: SMcC> This first version is a bit roughly assembled, being based on SMcC> the Sparrow skin, parts of Memcheck, and the GNU Binutils SMcC> "readelf" program, assembled with some modifications essentially SMcC> by cut and paste (along with a slightly modified version of the SMcC> Valgrind core, circa 2.1.1) together with our own code. In the SMcC> future, we'd like to use resources from Valgrind in a more SMcC> principled way, ideally making a tool that could be dropped into SMcC> an unmodified Valgrind distribution. We expect there are only a SMcC> few places in the rest of Valgrind that would need to be more SMcC> flexible to accommodate this (for instance, we don't want SMcC> Memcheck's V bits to be set to "valid" after an invalid access). NN> What changes to Valgrind's core would you require to make Kvasir a NN> normal drop-in Valgrind tool? Sounds like improved debug info NN> support is one. (Nb: I'm not promising anything with those NN> sentences :) We're currently doing all our own reading of debugging information separately from what Valgrind's core does; the only hook we added was a way to get the name of the program binary, so we could open it ourselves to get the debugging information. (It's possible there's already a hook for this that we missed; what we added was so simple we didn't bother searching carefully. We could also probably do just as well with a way to get a file descriptor or a FILE* for the executable.) It would certainly be possible to merge the DWARF-parsing code we're using (which is basically the readelf program) into the core, but it doesn't seem like it would be worth the effort. NN> The V bits setting sounds like purely a tool/skin issue, though. Yes, I think the most major issues have to do with how we can best share functionality with Memcheck. We basically need our tool to do 90% of the work the Memcheck does (not leak detection, or the aforementioned V bit resetting), plus extra stuff of our own. In some ways, this seems similar to the situation with Addrcheck: we could link directly with ".o" files from the memcheck directory, if they just had a few more things controlled by flags, and a few things pulled into separate files. -- Stephen |