Re: Weird behaviour with --target_board="unix{var1,var2}"

[Jonathan Wakely <jwakely at redhat dot com>]

On 22/08/16 21:16 +0100, Pedro Alves wrote:
> On 08/22/2016 03:40 PM, Jonathan Wakely wrote:
>
> > What's going on?!
> >
> > Have I fundamentally misunderstood something about how RUNTESTFLAGS or
> > effective-target keywords work?
>
> Here's a wild guess.
>
> In gdb's testsuite, I've seen odd problems like these being caused by some
> tcl global getting set on the first run using one board, then then the
> second run using the second board finds the variable already set and
> skips something.  E.g.:
>
>  https://sourceware.org/ml/gdb-patches/2015-04/msg00261.html
>
> I'd look at the code that decides whether to run a test in a particular
> mode with the above in mind.  Given that reordering the boards makes
> a difference, it kind of sounds like some "last checked mode" or some
> such variable is bleeding between runs.

I've tracked it down to this block of code in
/usr/share/dejagnu/dg.exp:

   # Don't do this if we're testing an interpreter.
   # FIXME: why?
   if { ${dg-interpreter-batch-mode} == 0 } {
	# Catch excess errors (new bugs or incomplete testcases).
	if {${dg-excess-errors-flag}} {
	    setup_xfail "*-*-*"
	}
	if {![string match "" $comp_output]} {
	    fail "$name (test for excess errors)"
	    send_log "Excess errors:\n$comp_output\n"
	} else {
	    pass "$name (test for excess errors)"
	}
   }

Adding some logging to the libstdc++-dg-test callback shows that
${dg-interpreter-batch-mode}  == 1 for the tests which don't print
their result.

That's being set by prettyprinters.exp and xmethods.exp (so it's GDB's
fault! ;-) because they want to keep the executables around, to run
GDB on. When we run with multiple boards that variable doesn't get
reset to 0 for the next run of conformance.exp

That also explains why putting RUNTESTFLAGS="conformance.exp..." fixes
it, because the other .exp files aren't used, so batch mode is never
set.

Shouldn't be too hard to fix.