On Friday 22 February 2008, Julian Seward wrote:
> > > >  trace_start_client_code
> > > >  track_stop_client_code
> ...
> > > The above is not sufficient.
> ...

> I am (very) surprised to hear that track_{start,stop}_client_code
> give wrong results.  The reason is that (translations of) client code
> (and I mean *all* client code, including client signal handlers)

<OT>
"Signal handler exit via longjmp" is offtopic here, but how should valgrind
core be able to detect this, as the signal frame is silently discarded by
longjmp? This is also clearly stated in "pub_tool_tooliface.h":

 /* Called after a signal is delivered.  Nb: unfortunately, if the signal
    handler longjmps, this won't be called.  */
 void VG_(track_post_deliver_signal)(void(*f)(ThreadId tid, Int sigNo));

However, this is not important for Callgrind as with the regular resync.
of the shadow stack against the real one, this case still is catched
without any help from VG core.

</OT>


> So perhaps tid is wrong here?

For Callgrind, it is a non-issue, as setup_bbcc is called at beginning
of every BB. So I wanted to play safe and did the adjustment against
VG_(get_running_tid) there. I could skip this and make an assertion instead.

Josef

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Valgrind-developers mailing list
Valgrind-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-developers

Reply via email to