Mike Stump <mikest...@comcast.net> writes:
> 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.
I know: I've been using something like this for a long time while still
testing gcc on a 250 MHz MIPS R10k running (crawling, actually ;-)
IRIX. But that's not the point here: without passing the exec name to
gdb, the check_guality test hangs forever, however large one might make
the dejagnu timeout.
> 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.
I'll have to look into this some more when I'll be forced to to more
Solaris/SPARC testing on slow UltraSPARC-T2 systems: there are a couple
of tests that regularly run into the dejagnu timeout, some already
reported, others not yet.
> Upping the timeout of course won’t cure an infinite loop due to gdb bugs.
Indeed.
> 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.
I don't think this is an issue: one I'd fixed guality.h to pass argv[0]
to gdb, all guality tests completed just fine, even on my slowest SPARC
machine.
>>> Ok for mainline?
>
> Ok to me, but, if the gdb/guality folks have better comments, I’d defer to
> them.
Indeed: this part of the question is more about the general quality and
future of the guality tests. They have been Alexandre's baby mostly,
and he's been largely absent from GCC development lately.
> 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.
Depends: one some platforms, it might be possible to determine the exec
name by OS-dependent means (be it /proc, getexecname, or whatever), but
I bet there are targets supported by gdb that have no such facility, and
for their sake (and currently available versions of gdb), just always
passing argv[0] seems the easiest course of action. As I said,
gfortran.dg/guality/guality.exp already does it, and there were no
issues even on Solaris.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
