[prev in list] [next in list] [prev in thread] [next in thread] 

List:       user-mode-linux-devel
Subject:    Re: [uml-devel] [Valgrind-developers] running UserModeLinux under
From:       "Michael Abshoff" <Michael.Abshoff () fsmath ! mathematik ! uni-dortmund ! de>
Date:       2007-12-27 19:55:12
Message-ID: 64587.80.144.206.235.1198785312.squirrel () fsmath ! mathematik ! uni-dortmund ! de
[Download RAW message or body]

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, jreiser@BitWagon.com


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
> Valgrind-developers@lists.sourceforge.net
> 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

[prev in list] [next in list] [prev in thread] [next in thread]