|
From: Tom H. <th...@cy...> - 2004-08-04 14:58:24
|
In message <200...@cc...>
Jeff Dike <jd...@ad...> wrote:
>> But how did you cope with the fact that valgrind doesn't protect it's
>> internal data structures in any way? You would have all sorts of
>> problems with two threads trying to access the same data.
>
> I think I was mistaken about this firing off another valgrind thread, for
> two reasons.
>
> I remember being concerned about whether the process data was still
> present in its normal, not running under valgrind, form. This would
> only be a problem if you were planning on running a non-valgrind
> thread in the same address space.
Even doing that (if it's still possible) is quite dangerous as
that thread could accidentally damage valgrind's environment.
> Second, the patch above looks like it extracts the client IP from
> valigrind's state and branches to it. This would make the new
> thread a non-valgrind one.
That would imply that the newly created thread was left to run on
the real CPU rather than the simulated CPU. If that's the case then
I'm not that it is possible anymore - I know we had to take out the
stuff that allowed valgrind to switch back to the real CPU after
running a specified number of basic blocks because it could no longer
be made to work.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|