|
From: Jeroen N. W. <jn...@xs...> - 2005-11-11 19:22:42
|
Greetings, 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. I'm thinking of using 'vanilla' Valgrind from svn as outer Valgrind, and my hacked version as inner Valgrind, and I want to subject both of them to regression testing. 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. 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?) What do you think? Jeroen. |
|
From: Nicholas N. <nj...@cs...> - 2005-11-11 20:37:29
Attachments:
diff
|
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. 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. > 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. Nick |