|
From: Jeroen N. W. <jn...@xs...> - 2005-11-12 09:29:12
Attachments:
README_DEVELOPERS.patch
selfhost.txt
|
On Fri, 11 Nov 2005, Nicholas Nethercote wrote: > On Fri, 11 Nov 2005, Jeroen N. Witmond wrote: > >> While working on blanket (a basic code coverage tool) I got the urge to >> use memcheck on it, so I looked into self-hosting. I ran into some >> usability problems quite soon. > > Yes, the self-hosting support is quite new and not well tested. Thanks > for looking at it. > >> In the current setup, the inner Valgrind (the one running blanket, in my >> case) has to be configured specifically to run as client of the outer >> Valgrind (memcheck). This breaks the regression test of the inner >> Valgrind. >> >> Just reversing the situation, using --enable-outer instead of >> --enable-inner, obviously does not solve the problem. In addition, the >> outer valgrind should use the presence or absence of command line option >> --weird-hacks=enable-outer to determine the correct VALGRIND_LIB and >> VALGRIND_LAUNCHER (with or without the suffix "_OUTER") to use. This >> allows both outer and inner Valgrind to be regression-tested separately. > > I think it's simpler than that. Try the attached patch and let me know if > it is good enough for your needs. The patch works. Thanks! > Nb: The --weird-hacks=enable-outer (now called "--simulation-hints") isn't > very important, it just prevents problems if you run both inner and outer > Valgrind with -d. You can get away without using it. This change in name has not made it into README_DEVELOPERS yet. See attached file READE_DEVELOPERS.patch. >> A problem with this schema might be that the presence of --enable-inner >> in >> coregrind/m_dispatch/dispatch-x86-linux.S. (I noticed that the amd64 and >> ppc32 variants of this file do not handle --enable-inner. Is that >> correct?) > > It's correct. It's a sanity check of the FP state (or something like > that) which fails under self-hosting, but Julian says it's unimportant and > would be difficult to fix. Now I am able to memcheck nulgrind (using tests/true as client program), resulting in a number of errors, apparently from both tools, the most spectacular error being: "valgrind: VG_(scheduler), phase 3: run_innerloop detected host state invariant failure" See attached file selfhost.txt for the full output. Am I doing something wrong? Can I help in any way in debugging and fxing this problem? Jeroen. |
|
From: Nicholas N. <nj...@cs...> - 2005-11-12 16:19:29
Attachments:
x
|
On Sat, 12 Nov 2005, Jeroen N. Witmond wrote: > The patch works. Thanks! Committed. > This change in name has not made it into README_DEVELOPERS yet. See > attached file READE_DEVELOPERS.patch. True, thanks. > Now I am able to memcheck nulgrind (using tests/true as client program), > resulting in a number of errors, apparently from both tools, the most > spectacular error being: "valgrind: VG_(scheduler), phase 3: run_innerloop > detected host state invariant failure" See attached file selfhost.txt for > the full output. That invariant failure is what I get if the ENABLE_INNER ifdef in m_dispatch-x86-linux.S is not present. But I get a different failure, see attachment. > Am I doing something wrong? No, it looks fine. > Can I help in any way in debugging and fxing this problem? Sure :) As I said, self-hosting is not very reliable yet, so any help in making it work better would be very helpful. I can't give you any very specific pointers to fix this current problem, though. One thing to note: running Memcheck on Valgrind currently won't be as useful as it could be because Valgrind's on allocator (m_mallocfree.c) requires annotating with client requests to indicate when blocks are allocated and freed. Nick |