|
From: Stephen M.
|
I've recently tried using callgrind and the self-hosting features of recent Valgrind versions in order to profile our Valgrind-based tracing and dynamic analysis tools (http://pag.csail.mit.edu/fjalar/). So far, this seems to work pretty well. However, I ran into one problem with an error coming from the following code in dispatch-x86-linux.S: /* We're leaving. Check that nobody messed with %mxcsr or %fpucw. We can't mess with %eax here as it holds the tentative return value, but any other is OK. */ #if !defined(ENABLE_INNER) /* This check fails for self-hosting, so skip in that case */ pushl $0 fstcw (%esp) cmpl $0x027F, (%esp) popl %esi /* get rid of the word without trashing %eflags */ jnz invariant_violation #endif cmpl $0, VG_(machine_x86_have_mxcsr) jz L2 pushl $0 stmxcsr (%esp) andl $0xFFFFFFC0, (%esp) /* mask out status flags */ cmpl $0x1F80, (%esp) popl %esi jnz invariant_violation L2: /* otherwise we're OK */ jmp run_innerloop_exit_REALLY (the eventual error message is: valgrind: m_scheduler/scheduler.c:994 (vgPlain_scheduler): the 'impossible' happened. valgrind: VG_(scheduler), phase 3: run_innerloop detected host state invariant failure ) Since the %fpucw check is commented out, the problems must have been coming from the %mxcsr check, and indeed when I ifdef'ed that out too, things seemed to run fine. 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 (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, but we're loathe to give up fprintf() and friends), now statically. The computer I'm seeing this on is an older Athlon that I'm not sure even has an MXCSR register, if that makes a difference. Is ifdeffing out the second check the right fix? -- Stephen |