|
From: John R.
Attachments:
valgrind-3.3.0.patch.gz
|
The attached patch to valgrind-3.3.0 is what I am using to run UML (UserModeLinux) for x86 under memcheck on x86, thus checking the memory accesses of a linux kernel. -rw-rw-r-- 1 jreiser jreiser 8846 2007-12-15 11:36 valgrind-3.3.0.patch.gz -rw-rw-r-- 1 jreiser jreiser 31383 2007-12-15 11:36 valgrind-3.3.0.patch The changes generally are in three areas: Allow clone() to handle more flag cases successfully, and also establishing a new stack pointer in the child even for a fork-like clone(). These changes are somewhat general, although motivated by UML. Allow better coordination with respect to explicit stack switching; UML uses longjmp() for this purpose. Perhaps after more thought this could be done automatically by VEX when translating "load stack pointer from memory." Enable valgrind to stop tracking the child of a clone() immediately, letting the child run natively. This change is somewhat specific to UML and its "skas0" mode of operation. UML has a difficult time dealing with virtualization of the child side of clone(); having the tool "let go" of most children makes it easier. Obviously UML requires changes, too. Although the linux kernel has kmalloc() and kfree() subroutines, the obvious coorespondence to malloc() and free() does not carry all the needed or desired information. The kernel allocators already have some builtin checking, and allocating a "page" can have non-simple implications. There is work in annotating the linux kernel allocators with VALGRIND_MALLOCLIKE_BLOCK, VALGRIND_FREELIKE_BLOCK, VALGRIND_MAKE_MEM_DEFINED, and VALGRIND_MAKE_MEM_UNDEFINED. Details will appear on the uml-devel mailing list. -- John Reiser, jreiser@BitWagon.com |
|
From: Bart V. A. <bar...@gm...> - 2007-12-17 15:11:39
|
On 12/15/07, John Reiser <jr...@bi...> wrote: > > The attached patch to valgrind-3.3.0 is what I am using to run > UML (UserModeLinux) for x86 under memcheck on x86, thus checking > the memory accesses of a linux kernel. This sounds great. Can you share your experience with running UML under memcheck ? Regards, Bart. |
Bart Van Assche wrote: >>The attached patch to valgrind-3.3.0 is what I am using to run >>UML (UserModeLinux) for x86 under memcheck on x86, thus checking >>the memory accesses of a linux kernel. > This sounds great. Can you share your experience with running UML under > memcheck ? Details will appear in use...@li... and have started to appear in lin...@vg... . In general, running UML under memcheck is much the same as running any large application under memcheck for the first time. "Bugs" crawl out of the woodwork left and right. The kernel allocators make some assumptions that are unfriendly to memcheck. Threads are a serious nuisance. Debugging is tedious. printf and "for(;;);" are your friends (to avoid timing-dependent problems, and so you can attach gdb to a specific address space.) Getting a traceback of UML under memcheck is cumbersome. The best progress often is made by writing a program to detect and isolate the bug (editing the source of the kernel and/or memcheck, recompiling, and re-running) rather than by general external application of gdb. The *option* for memcheck to complain as soon as possible, immediately upon fetch of uninit bits, without waiting for array indexing or a conditional jump/move, is sorely missed. -- John Reiser, jreiser@BitWagon.com |