John Reiser wrote
Hi John,
> Patches have been developed which enable UserModeLinux for i686 to
> run under the memcheck tool of Valgrind on i686. Thus it is possible
> to check dynamically the memory accesses made by a running Linux kernel
> against memcheck's model of allowed behavior. This work was supported
> by Google Inc.
>
> The combined patches are at "alpha" quality.
I applied your patch against a vanilla 3.3.0 and with both gcc 4.2 and a
recent gcc 4.3 snapshot I get the following compilation failure on Linux
x86-64 (Centos 5)
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I..
-I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux
-I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1
-DVGO_linux=1 -DVGP_amd64_linux=1
-DVG_LIBDIR="\"/usr/local/valgrind-3.3.0-asap/lib/valgrind"\" -m64
-fomit-frame-pointer -O2 -g -Wmissing-prototypes -Wall -Wshadow
-Wpointer-arith -Wstrict-prototypes -Wmissing-declarations
-fno-strict-aliasing -Wno-long-long -Wno-pointer-sign
-Wdeclaration-after-statement -fno-stack-protector -MT
libcoregrind_amd64_linux_a-syswrap-linux.o -MD -MP -MF
".deps/libcoregrind_amd64_linux_a-syswrap-linux.Tpo" -c -o
libcoregrind_amd64_linux_a-syswrap-linux.o `test -f
'm_syswrap/syswrap-linux.c' || echo './'`m_syswrap/syswrap-linux.c; \
then mv -f ".deps/libcoregrind_amd64_linux_a-syswrap-linux.Tpo"
".deps/libcoregrind_amd64_linux_a-syswrap-linux.Po"; else rm -f
".deps/libcoregrind_amd64_linux_a-syswrap-linux.Tpo"; exit 1; fi
m_syswrap/syswrap-linux.c: In function vgModuleLocal_do_fork_clone:
m_syswrap/syswrap-linux.c:338: error: VexGuestArchState has no member
named guest_EAX
m_syswrap/syswrap-linux.c:340: error: VexGuestArchState has no member
named guest_ESP
m_syswrap/syswrap-linux.c:349: warning: implicit declaration of function
letgo_vex_x86_linux
make[3]: *** [libcoregrind_amd64_linux_a-syswrap-linux.o] Error 1
make[3]: Leaving directory `/tmp/Work/valgrind-3.3.0/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/Work/valgrind-3.3.0/coregrind'
> They have memchecked
> an entire trivial session (boot UML, login, halt), and have identified
> a couple specific problems in kernel code. The steps necessary to reach
> "beta" quality (a motivated kernel developer can get useful results)
> have been outlined and are being pursued.
>
> The goods:
> 15KB http://bitwagon.com/valgrind+uml/valgrind-3.3.0-2007-12-27.patch.gz
> 60KB http://bitwagon.com/valgrind+uml/uml-2.6.22.5-2007-12-27.patch.gz
>
> Current status and updates will be maintained on the [coming] web page
> http://bitwagon.com/valgrind+uml/index.html
>
> As a convenience for when the official sites are not responding,
> here are copies of the original unpatched software that is required:
> 4MB http://bitwagon.com/valgrind+uml/valgrind-3.3.0.tar.bz2
> 45MB http://bitwagon.com/valgrind+uml/linux-2.6.22.5.tar.bz2
> 103MB http://bitwagon.com/valgrind+uml/FedoraCore5-x86-root_fs.bz2
> Approximately 2.5GB of disk space is required to play.
>
> Motivated in part by the difficulty of tracking down the causes of
> "Conditional jump or move depends on uninitialised data", the patches
> include a new *optional* mode for memcheck: --complain-asap=yes.
This is a very, very cool feature. Any way you can split that patch out
from the patchset?
> In this mode, memcheck issues a complaint immediately for any load
> from memory that contains uninitialized bits. This gives a very early
> notice of potential trouble. It also squawks for uninitialized
> holes in structures or bitfields, conditions which later become ignored
> or "don't care", certain compiler optimizations for speed, etc.
> The intent is to reduce the blizzard of "false positive" complaints
> by using the glibc-audit patches to provide a "quiet" glibc,
> by making the holes in kernel structures explicit (and filling them),
> by writing suppressions for known cases, by and further enhancing
> this new mode of memcheck.
>
> On the UML side, there is a significant technical issue: the semantics
> of kmalloc+kfree do not match the semantics of malloc+free. The kernel
> slab allocator caches and re-issues identified objects, which accumulate
> state and retain it throughout execution, including from kfree to kmalloc.
> In contrast, a region that is passed to free() loses both its contents
> and its identity. Also, size is an important parameter to malloc,
> but is implicit to kmalloc. The initial patches finesse these issues
> (for instance: by supplying the size as trailing parameter to kmalloc,
> and by noticing that SLAB_POISON ==> free()), but there will be
> significant discussion and work in resolving the differences.
>
> --
> John Reiser, [EMAIL PROTECTED]
Cheers,
Michael
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Valgrind-developers mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
