|
From: Scott P. <pa...@la...> - 2010-09-16 01:33:57
|
On 09/15/2010 03:46 PM, Nicholas Nethercote wrote: > The IRStmt will be destroyed before the instrumented code is run. > However, if you heap-allocated some memory and copied it, you could > then pass a pointer to the copy. As for deallocating the copy... if > the translation gets flushed you should free the copy. The only hook > that will let you know when that happens is > VG_(needs_superblock_discards). That might give you enough info to do > it. Or you could just not worry about it, depending on how robust > your tool needs to be; code cache flushes aren't that common. Ah, I didn't know about VG_(needs_superblock_discards). Nice. > The fewer arguments, the better. If one of the arguments has only N > possible values and N is small (eg. 3 or 4) you can have N functions. > So instead of these calls: > > foo(1, ...) > foo(2, ...) > foo(3, ...) > > you have: > > foo1(...) > foo2(...) > foo3(...) > > Several of the existing Valgrind tools do this. Okay, that seems more practical to use for my particular code. I'll give it a shot. Thanks, -- Scott |