Re: [Valgrind-developers] MXCSR invariant failures under self-hosting

[Julian S. <js...@ac...>]

> I can't say I understand why the %fpucw check fails when you're
> self-hosting, but it seems at least plausible that a similar issue
> affects the %mxcsr check. I'm not sure what it is about our tool that
> tickles this problem; I didn't see similar failures with a memcheck
> built from a pristine valgrind source

Check that the helper functions your tool calls do not mess with
mxcsr.  Technically it is caller saved, but saving it across all
helper function calls would be expensive and so vex doesn't.

> (our tool is based in part on 
> memcheck). One potentially significant difference is that we still
> link with glibc (I get the impression that's discouraged, 

Very much so.  We too have been loathe to lose glibc support, but after
a long and somewhat confusing discussion some months ago, it became
clear that linking in glibc opens the possibility of various kinds of
bad interactions between glibc and V, since V needs to control various
kinds of resources (address space layout, signal state) but glibc
believes that it is the sole owner of such resources.  Getting rid of
glibc was therefore a step forward from both a stability and 
portability standpoint.

I would not be surprised to find that your use of glibc causes V to
bomb with an assertion failure when running large programs with the
flag --sanity-level=3 or above.

J