On Thu, Jan 27, 2011 at 1:23 PM, Laurynas Biveinis <laurynas.bivei...@gmail.com> wrote: > The --enable-checking=valgrind does two things. First, it provides > Valgrind annotations for internal GCC allocators so that Valgrind has > a better idea about memory blocks which are not supposed to be > accessed. Second, it actually invokes Valgrind on every compiler > invocation. This makes the option very nice for e.g. ensuring that > bootstrap and testsuite are Valgrind-clean. However if one wants to > use Valgrind only to analyze a particular testcase, then the price of > full Valgrind'ified bootstrap is prohibitive. > > Thus I propose to separate the two. To avoid introducing another > --enable-checking option, let's move the annotations to the "misc" > checking and also enable "misc" too if "valgrind" is requested. Both > these options are disabled for releases, so no performance loss there. > > There are two drawbacks I can think of. First, if one wants Valgrind > annotations but does not have the required headers, then the compiler > will be built without them - silently (currently > --enable-checking=valgrind fails if headers are not found). Second, > the compiler binary will be built slightly different if "misc" is > enabled depending on the presence or absence of those headers. I > believe these are minor enough. > > I have a prototype patch which I've been using on gc-improv (not > committed there yet). > > What do you think?
I think we should drop the behavior that --enable-checking=valgrind invokes valgrind, this seems like an odd feature. Doing the annotations under an --enable-checking flag also sounds odd, we for example have --enable-gather-detailed-mem-stats, I'd have expected a --enable-valgrind-annotations to do that. I have no preference how to change the existing (odd) behavior, but maybe introduce --enable-valgrind-annotations for the annotations and enable that when valgrind checking is enabled? Richard.
