|
From: Jeremy F. <je...@go...> - 2004-12-03 04:12:35
|
On Thu, 2004-12-02 at 17:34 -0800, Roland McGrath wrote: > > > I guess that's probably about as useful as anyone needs. Or maybe > > > valgrind/xen. But I had contemplated actual normal native kernels with > > > built-in valgrind. > > > > Sounds interesting - what do you mean exactly though? > > I mean valgrind for a Linux kernel just like valgrind for a user process. > i.e., all the kernel code translated and monitored on the fly as it runs. > Only the valgrind engine itself really has to run normally, and a tiny bit > of glue for trap handlers to reenter valgrindland. The internal allocators > can have special hooks like normal valgrind's malloc does. I think this is > doable and it has appeal for hack value. But the more I think about, the > more it seems like the valgrinding xen is what is really the most useful > (and probably easier to do). i.e., a vanilla xen guest kernel can run > under a valgrind host instead of the real xen host. This would look like a new OS port for Valgrind, I guess, though it could get tricky. At the moment we don't emulate any privileged instructions, but I haven't read enough about Xen to know if that matters (do the Xen guest kernels run their own privileged instructions, or do they call into the hypervisor?). It would certainly be an interesting project from the perspective of making us be very clear about which parts of Valgrind are OS emulation and which parts are CPU emulation. I guess machine faults and traps are close enough to looking like signals to fit into the emulation model that way. The other interesting thing will be to work out how Valgrind can know about the various thread contexts within the kernel. This would relate to the thread-switch problem, and also so that we can use helgrind to examine the kernel's use of locking (which may or may not produce useful results). J |