Re: What does "Execution timeout is: $test_timeout" mean?

[Maciej W. Rozycki]

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