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

[Jonathan Wakely]

On 23/08/16 09:07 +0100, Jonathan Wakely wrote:
>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.

This seems to work. I'll do some more testing and commit later today.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 2030 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20160823/612a7aba/attachment.bin>