On Jan 28, 2015, at 4:58 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote:
>
> Thoughts?
So the timeout for slow things can be increased:
# More time is needed
set_board_info gcc,timeout 800
set_board_info gdb,timeout 60
from the frv-sim.exp file. And:
# Increase the timeout
set timeout 60
from a few others. And:
set_board_info testcase_timeout 30
from usparc-cygmon.exp. I’d like to think one or more of those would cure the
timeout problem. You can put the timeout in a site.exp file or a
$HOME/.dejgnurc file for dejagnu and try it out, something like:
case "$target_triplet" in {
{ “sparc-*-*" } {
set_board_info gdb,timeout 60
}
}
if you want to try site.exp. The timeouts should be buried somewhere inside
gcc or dejagnu for non-site specific timeouts however.
For individual test cases that are pigs that you catch, dg-timeout-factor can
be used to slide it up. On a good host, every test should take 10 seconds or
less. If they take more, I would bump the timeout to be 30x the time it takes
on a good host. This gives us headroom for shared machines, slower machines
and all sorts of variations. The slowest of the targets (m68k testing), aren’t
expected to be able to be covered by this slop, they would need to use a more
formal mechanism to say they are extra slow.
Upping the timeout of course won’t cure an infinite loop due to gdb bugs.
One thing that I wonder about is how much swap space one has and if the test
suite firing up too many gdb tasks too fast and simply running it out of memory
or causing thrashing due to testtcase size. If you wanted to explore this,
look for check_gcc_parallelize=10000 in the Makefile, and see if trimming it
down helps. If so, then Jakub might be able to help trim the guilty tests down
so they don’t so thrash as much.
> Ok for mainline?
Ok to me, but, if the gdb/guality folks have better comments, I’d defer to them.
The command line issue sounds like a gdb bug. I’d report it and tag in a PR
number into the comment where we create the command line.
