Running cc1 etc under valgrind (was Re: [PATCH 13/21] PR jit/63854: Add support for running "make check-jit" under valgrind)

[David Malcolm]

On Wed, 2014-11-19 at 13:38 -0500, David Malcolm wrote:
> On Wed, 2014-11-19 at 09:57 -0700, Jeff Law wrote:
> > On 11/19/14 03:46, David Malcolm wrote:
> > > This commit updates jit.exp so that if RUN_UNDER_VALGRIND is present
> > > in the environment, all of the built client code using libgccjit.so is
> > > run under valgrind, with --leak-check=full.
> > >
> > > Hence:
> > >    RUN_UNDER_VALGRIND= make check-jit
> > > will run all jit testcases under valgrind (taking 27 mins on my
> > > machine).
> > >
> > > Results are written to testsuite/jit/test-FOO.exe.valgrind.txt
> > >
> > > jit.exp automatically parses these result file, looking for lines of
> > > the form
> > >    definitely lost: 11,316 bytes in 235 blocks
> > >    indirectly lost: 352 bytes in 4 blocks
> > > in the valgrind log's summary footer, adding PASSes if they are zero
> > > bytes, and, for now generating XFAILs for non-zero bytes.
> > >
> > > Sadly this diverges jit.exp's fixed_host_execute further from DejaGnu's
> > > host_execute, but I don't see a clean way to fix that.
> > >
> > > This currently adds 63 PASSes and 49 XFAILs to jit.sum, giving:
> > >    # of expected passes   2481
> > >    # of expected failures 49
> > >
> > > gcc/testsuite/ChangeLog:
> > > 	PR jit/63854
> > > 	* jit.dg/jit.exp (report_leak): New.
> > > 	(parse_valgrind_logfile): New.
> > > 	(fixed_host_execute): Detect if RUN_UNDER_VALGRIND is present
> > > 	in the environment, and if so, run the executable under
> > > 	valgrind, capturing valgrind's output to a logfile.  Parse the
> > > 	log file, generating PASSes and XFAILs for the summary of leaks.
> > OK for the trunk.  FWIW, I'd love to see a mode where we can easily do 
> > this for the other testsuites as well.
> 
> Many of the cleanups in these patches are called from toplev::finalize,
> or something called from there, so that they're called by libgccjit.so,
> but not called by cc1/cc1plus etc.
> 
> In general, cc1 etc don't need to bother free-ing everything, and can
> instead simply exit.
> 
> But if you're running under valgrind, you'd probably want them to call
> toplev::finalize before exiting, to make the valgrind log shorter.
> 
> So perhaps cc1 etc could detect if they're being run under valgrind, and
> call toplev::finalize in the appropriate place?
> 
> Or maybe this could be a command-line option?
> 
> [I think I prefer autodetection, fwiw]

It turns out that this isn't necessary (I think), since the pointers are
typically still reachable.