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

[Jonathan Wakely]

On 03/12/20 22:49 -0600, Jacob Bachmeyer wrote:
> Jonathan Wakely wrote:
> > On 02/12/20 21:48 -0600, Jacob Bachmeyer wrote:
> > > Jonathan Wakely wrote:
> > > > Hi,
> > > >
> > > > [...]
> > > >
> > > > If I set test_timeout in ~/.dejagnurc or site.exp then I do indeed see
> > > > the value change. But it doesn't do anything. I can set test_timeout
> > > > to 2 second, and tests that sleep for 20 seconds or more will still
> > > > PASS and not timeout (as long as $tool_timeout is large enough).
> > >
> > > Evidently, the GCC testsuite is overriding that setting.
> >
> > Yes, GCC replaces the standard_wait proc with one that uses its own
> > value:
> >
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/lib/timeout.exp;h=856c2e3184122cbd1128116703fef5480ec8805e;hb=HEAD
> >
> >
> > And so now I see what's happening. DG prints the value of
> > $test_timeout, calls remote_wait with that timeout, which calls
> > standard_wait with that timeout, but GCC replaces that proc with one
> > that uses a different timeout. I don't think DG can know about that
> > really.
> >
> > 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.