On Fri, 4 Dec 2020, Jonathan Wakely wrote:
> >>Maybe what GCC should really do is set $test_timeout instead, which is
> >>possible now that proc unix_load allows it to be overridden.
> >
> >This is another example of problems caused by monkey-patching the test
> >framework. The use of a different variable is a bug in the GCC testsuite.
>
> While I share the sentiment on monkey-patching, this code in GCC dates
> from 2008, so it's not entirely surprising that it doesn't use the
> test_timeout variable that was introduced in 2015, replacing a
> hardcoded "300" value:
> https://lists.gnu.org/archive/html/dejagnu/2015-11/msg00008.html
>
> I'll look into whether we can unify GCC's timeout with the new
> test_timeout variable in recent versions of DejaGnu.
I last looked into these timeouts in details a while ago already, mostly
in the context of GDB, and there were several of them across the various
test suites. And it better stayed like that, because obviously we want
different thresholds for compilation, downloading and running a test case
each. So if we have a look at board description files dating back to
1999, then we have settings like:
set_board_info timeout 600
set_board_info testcase_timeout 500
set_board_info gcc,timeout 800
set_board_info gdb,timeout 60
setting various timeouts and one would expect these files to continue
working as originally designed.
Ah, I have tracked down one cleanup of mine in this area, specifically
GDB commit 4a40f85a84f0 ("GDB/testsuite: Avoid timeout lowering"), the
description of which combined with TCL code affected may shed some light
on how the timeouts could be managed with GCC testing as well.
NB slow target hardware may require hours to complete with some of the
test cases and I used timeouts as high as 7200 to handle outliers, which
would however be preferably applied to target execution only and not other
test activity.
Maciej
