Re: [Valgrind-users] how to trace an application

[Josef W. <Jos...@gm...>]

On Sunday 01 April 2007, Nicholas Nethercote wrote:
> On Sun, 1 Apr 2007, Nicholas Nethercote wrote:
> >> Hmm... perhaps it would be enough for such modules to document their
> >> instrumentation needs (such as "module X needs a helper call to y at start of
> >> every BB" or "module X wants to scan the SB and insert an IR snippet
> >> before every exit"), and let the tool author do the actual instrumentation
> >> manually as it is done now.
> >
> > That would be very nice if it could be done in a clean way.  It's one of
> > those things that could be useful in a range of contexts but is actually
> > really hard to do well, because of all the weird cases (PLT, longjmp/setjmp,
> > tail recursion, etc).
> 
> Thinking some more, it shouldn't be that hard.  You'd have events like 
> "enter_function" and "exit_function", which would get passed the function 
> name and start address.  (You'd have to make clear that 
> enter_function/exit_function aren't always well-matched.

But the nice thing here is that these functions really _are_ well matched :-)
The whole thing of the shadow stack is to ensure this, with the automatic
unwinding via synchronization with the real stack, taking thread IDs and
signal handlers into account, and which makes it robust (e.g. with longjmp's). 
Otherwise, callgrind would not work.

In addition, we probably want to allow the tool to request the state of the shadow
stack at any point. IMHO backtraces got this way are potentially more useful
than the ones got from the physical stack. Of course, the semantic differences
have to explained in detail.

> )  It could be added  
> in an instrumentation pass like the one used for the 
> new_mem_stack/die_mem_stack events.

Oh, I never looked at these.
Are these adding additional instrumentation after/before the tools instrumentation
phase?

Josef

> 
> Nick
>