Re: Valgrind meets UML

[Jeremy Fitzhardinge <jeremy@goop.org>]

On Sat, 2002-12-21 at 06:40, John Reiser wrote:
> In order to prevent races between valgrind for UML and kernel allocators which
> valgrind does not "know", then the VALGRIND_* declarations being added to kernel
> allocators should allow for expressing the concept "atomically change state in
> both allocator and valgrind". 

Valgrind doesn't sit on the side and observe the kernel.  A better way
of viewing it is as a synthetic CPU which does a lot more error checking
than a typical CPU.  Valgrind itself is running all code, so there is no
scope for Valgrind and the kernel to get out of sync.  You can view the
VALGRIND_* declarations as being extensions to the instruction set. 

If UML were "SMP" (ie, multithreaded), then Valgrind would emulate all
the CPUs and their concurrency; at most you'd need to use the normal
synchronisation mechanisms to control the sequencing of the VALGRIND_*
directives with respect to allocators running on other CPUs/in other
threads.

On the other hand, if you view the directives that Jeff is proposing as
a more general set of directives for any tool to use to instrument the
kernel, then you might need to thinking about things in more detail.  On
the other hand, that smacks of over-design unless there's something
which can make immediate use of such hooks now (and therefore guide the
design).  

Putting the VALGRIND_* hooks (or some thin sugar wrapping) in now in the
appropriate places will mark where any further work should be done, so
should be enough for now.

	J