|
From: Jeff D. <jd...@ad...> - 2004-08-04 20:03:20
|
th...@cy... said: > The problem is that the virtual environment seen by a program running > under valgrind may not be the same as the real environment - things > like signal handlers, signal masks, resource limits and son. That > might be confusing for the thread that isn't running under valgrind > and might even lead to that thread damaging the process state. I'm not > saying it will happen, just that it's something to beware of. Yeah, that's why I was concerned about the process data existing in its native state. As for the rest, in the absense of CLONE_SIGHAND, it is all private to the thread, so it and valgrind won't trip over each other, assuming that the child is sufficiently careful not to inherit stuff that it doesn't expect. > It's still switch from the simulated CPU to the real CPU though - the > thread of control arrives at the clone and then branches with one > branch continuing on the real CPU and one on the simulated CPU. That > sounds to me just the same (for the new thread) as the existing thread > of control continuing on the real CPU. It feels to me more like the valgrind thread runs a system call with no perceptible effect, and there's this new thread all of a sudden which runs happily in this address space because it can't tell that valgrind is there. > You probably really need Jeremy's thoughts on the matter - he's more > up on this stuff and I think he was involved in dropping the support > for switching back to the real CPU. Yeah, he was responsible for that fragment I posted as well. Jeff |