Re: Valgrind meets UML

[John Reiser]

Jeff Dike wrote:
> [e-mail] said:
> 
>>Implementors of allocators can have bugs in the valgrind declarations
>>they add. An "independent" check based on documented
>>externally-visible behavior can help. 
> 
> 
> The problem is that valgrind is going to look under the covers of the kernel
> allocators and see the externally-visible requirements being violated.
> 
> Either you implement a globally correct description, which includes the 
> externally visible description as a subset, or you somehow tell valgrind not
> to complain about stuff inside the allocator.
> 
> The second sounds complicated, and anyway hides bugs in the allocator.

I suggest that useful partial progress can be made sooner by identifying the
allocators, telling valgrind about them and their external semantics, and having
valgrind trust them.  In particular, do not valgrind allocators at first.
Waiting for the globally correct description can take a long time, perhaps
about as long as waiting for the authors of device drivers to update to a new
device I/O model.  Also, the globally correct description is necessarily time
dependent: it changes while the allocator is active, and describing it correctly
at that level of detail can be hard, or at least tedious.

Not valgrinding allocators still will reveal plenty of problems.  Those will
help provide motivation for implementing descriptions that are more detailed,
eventually even globally correct at every instant.  Then you can turn valgrind
loose on the allocators themselves.

-- 
John Reiser, [e-mail]