|
From: Jeremy F. <je...@go...> - 2005-01-10 16:44:18
|
On Mon, 2005-01-10 at 13:33 +0000, Nicholas Nethercote wrote: > Feels to me like the right way to do this is to get function wrapping > working somehow, ie. allowing Valgrind tools to augment functions like > pthread_mutex_lock() with some extra code (this is different to function > replacement, which we currently use extensively; we don't want to have > to duplicate the functionality of the original function). I can't > remember if this has been discussed previously (probably) and if so, what > the general opinion was about how easy/reliable it is. Well, to be really useful, we need to determine some internal state of the pthreads library. With pthread_mutex_lock, we want to know when its about to block trying to take a lock, as well as when it has actually taken the lock. The first one is tricky, and not easily derivable from plain wrapping (unless we run a parallel simulation of pthreads to model what each particular call is going to do, which sounds fragile). > I second Julian in saying that it would be nice to see a bit more > polishing before it goes in. Looking at the patch, there are a few parts > that say "XXX" or "must fix this later"... it would be good to fix these, > otherwise they're likely to stay that way for a while. I'll review them. > And the things Tom > has found, obviously. Yep. > Also, there's the question of how this will interact with Julian's private > VCPU changes. It could be a tricky merge. I made almost no changes to vg_to/from_ucode, so I'm assuming that there's not much interaction. J |