Re: [Valgrind-developers] Re: [RFC]contribute a new tool to valgrind, Instruction Trace

[Yao Qi <qiy...@cn...>]

On Fri, Feb 24, 2006 at 11:42:29PM +0100, Josef Weidendorfer wrote:
> Hi,
> 
> it had a short look over the code.
> 
> So you print out all instructions where debug info says that they
> are in this function, right? You decide this in the callback

Yes, you are right!

> function, which is run for every instruction in the code.
> Why not decide this already in the instrumentation phase?

At first, we did put all the instruction display in the instrumentation
phase, but later, when we want to collect the information about memory 
access, data and address, I found that some data and address are
generated at run time, so I had to put print_write_data() and
print_read_data() in a callback form at run-time to collect some
run-time information.

I think this would decrease the efficiency of valgrind and itrace, but I
could not find another better solution to it.

In order to keep the order of instruction display and memory access
display,  that is to say, "R" or "W" record follow closedly to "I" or "J"
record if this instruction access memory, I put print_instruction() into 
callback.  Otherwise, instructions will be displayed first at
instrumentation phase, and memory access will be displayed later at the
run time, it would destroy the readability of the final output.

If anyone here any better idea or comments to this, feel free to tell
us.

> 
> > and only record instructions in this function you specified, while the
> > latter could enable itrace to record all instructions in this function
> > and instructions in functions called by this function.
> 
> I am not sure if this very simple calltree tracing is the right thing to
> include into VG source. At least there should be a big warning in the
> code/docu that this does not work
> * with multithreaded code (switching to another thread while in the function
> will leave you with tracing on)
> * with signal handlers (which will be traced, too)
> * with functions which are left via a jump (_dl_runtime_resolve, longjmps,
> perhaps exception handling, handcrafted assembler ...)
> * only with ISAs where VEX can identify RET instructions (AFAIK for PPC the
> jumpkind is only a hint here as PPC has no explicit RET instructions)

We did few tests on above you mentioned, so we are not sure what
would happen when itrace tracing a multithreaded program, a signal
handler and exception handler.

We will pay attention on these aspects and update the document per the
test result!

> > I include a patch of valgrind-itrace in attachment, and please apply it
> > to valgrind-3.1.0.
> 
> I am not the one to decide this, but I think it probably would be nice to add
> instruction tracing and function filtering (done at instrumentation time)
> to lackey.

We would like to have try to port the code of itrace to lackey!
> 
> Why do you not simply provide an external tool package? You can look at
> the configure.in and Makefile.am's in callgrind which does exactly this
> (granted, with some problems regarding biarch support).
> 
> Josef

-- 
Regards, Yao
------------
Yao Qi