|
From: Nicholas N. <nj...@cs...> - 2007-09-04 22:10:02
|
On Tue, 4 Sep 2007, Oriol Prat wrote: > I did it. > It works until the called function calls a libc function. > I sent a mail, days ago, explaining all the process that I followed to > accomplish. > > > It could be a problem to call indirect libc functions in valgrind tool code? > > valgrind code -> user library function (hard-coded absolute address) > -> libc function (like fwrite, printf, etc) > > Some questions about Valgrind internals come to my mind: > Are VG_ libc functions and regular libc functions using the same file > descriptor table? Everything uses the same file descriptor table. But I'm not sure how that's relevant. > What happens with the heap used by translated code and regular code > called inside Valgrind tools? I don't understand the question. But Valgrind tools don't use the normal heap, they have their own heap space. Nick > 2007/9/4, Nicholas Nethercote <nj...@cs...>: >> On Mon, 3 Sep 2007, Oriol Prat wrote: >> >>> Is it possible to call translated code from an instrumented function? >>> >>> I have an instrumented function inserted with unsafeIRDirty_0_N and >>> from inside this function I want to call a function that is part of >>> the user code. >>> >>> I want to do this because I load with LD_PRELOAD another >>> instrumentation tool at the same time as Valgrind and I want to call a >>> function of this other tool from Valgrind instrumentation function. >>> >>> I understand that this other tool is instrumented by Valgrind like >>> regular user code and I'm not be able to call it directly from >>> Valgrind instrumented functions. >> >> I'm not sure if you can do this. If you can find a way to just call the >> code normally from the function, and Valgrind will translate it normally, I >> think. The hard part may be working out how to call the code from the >> function, since it won't be visible -- maybe you could do something horrible >> like put the destination address in a global variable? Not sure. >> >> Nick >> > |