|
From: Josef W. <Jos...@gm...> - 2003-03-24 13:10:17
|
On Sunday 23 March 2003 16:57, Nicholas Nethercote wrote: > On Fri, 21 Mar 2003, Nicholas Nethercote wrote: > > > An alternative solution for function wrapping would be not to use the > > > runtime linker (symbol overwriding, hack with __libc_malloc), but to > > > change instrumentation of the first BB of the given function, and do a > > > "jmp" into the valgrind wrapper version if the skin would like to use > > > it. > > > > Hey, good idea. I'll have to think about that some more... > > Hmm, one problem is that it requires glibc to not be stripped, since > spotting function entries relies on symbol information being present. > I'm not sure whether this is likely or not. Symbol information for exported symbols in shared libraries can't be stripped, as the runtime linker has to know about it. This isn't debug information, and thus no problem. Static linking with glibc is another issue - but valgrind doesn't work with static binaries at all. > Also, there's the issue of whether malloc() gets called before Valgrind > gains control, possibly because of static C++ constructors. I've > discussed this with Julian before but I cannot remember what the outcome > was, so maybe I'm wrong. Hmm. malloc() is passing requests to arena_malloc() if not running on the simulated CPU. I still think that wrapping malloc() is a skin issue, and the core only should provide convenience functions for doing this in a simply way... Josef |