> > > trace_start_client_code
> > > track_stop_client_code
> > >
> > > Are any of these good enough? (I really thought we had a
> > > track_thread_switch event...)
> >
> > The above is not sufficient. I have tried in exp-drd to only update
> > the cached thread ID when one of the above events was generated. The
> > result was that for several test cases the cached thread ID was not
> > equal to VG_(get_running_tid()). An example of such a test case is
> > exp-drd/tests/sigalrm.c.
>
> Did you research the reason for this?
Yes, that is a good question.
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)
can only be reached through the following functions
coregrind/m_scheduler/scheduler.c: run_thread_for_a_while
coregrind/m_scheduler/scheduler.c: run_noredir_translation
There is no other way for a translation to be run.
In both functions, the call to the generated code is bracketed
by these:
// Tell the tool this thread is about to run client code
VG_TRACK( start_client_code, tid, bbs_done );
// Tell the tool this thread has stopped running client code
VG_TRACK( stop_client_code, tid, bbs_done );
So perhaps tid is wrong here? But it can't be: the tid
passed to run_thread_for_a_while and run_noredir_translation
is used to select which set of guest registers to use for the
run, and so if it was wrong threaded programs as a whole would
die in a very obvious way.
J
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
