GNU bug report logs - #48611
Allow DEJAGNU TIMEOUT env var for slow arches

Previous Next

To reply to this bug, email your comments to 48611 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Héctor Orón Martínez <hector.oron <at> gmail.com>
To: bug-dejagnu <at> gnu.org
Cc: Ben Elliston <bje <at> air.net.au>, jcb62281 <at> gmail.com
Subject: Allow DEJAGNU TIMEOUT env var for slow arches
Date: Sun, 23 May 2021 10:50:55 +0200

Hello,

Please consider allowing custom timeout environment variable for slow
architectures, such m68k. The following change we carry in Debian
distribution:

Description: timeout for m68k and maybe arm should be doubled
 The timeout in /usr/share/dejagnu/remote.exp:257 is too short for many
 of gcc's testcases, when run on m68k and arm. Include a hack to define
 a specific timeout via an environment variable.

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=182177
Bug-Debian: https://bugs.debian.org/182177
Last-Update: 2021-05-03

--- dejagnu-1.6.2.orig/lib/remote.exp
+++ dejagnu-1.6.2/lib/remote.exp
@@ -311,6 +311,8 @@ proc remote_exec { hostname program args
     # 300 is probably a lame default.
     if { [llength $args] > 3 } {
  set timeout "[lindex $args 3]"
+    } elseif { [getenv DEJAGNU_TIMEOUT] != "" } {
+ set timeout [getenv DEJAGNU_TIMEOUT]
     } else {
  set timeout 300
     }

Thanks for considering!

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Message #12 received at 48611 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: 48611 <at> debbugs.gnu.org
Subject: Re: bug#48611: Allow DEJAGNU TIMEOUT env var for slow arches
Date: Sun, 23 May 2021 20:12:24 -0500

This patch mentions that the problem seems to be specific to certain 
target architectures and possibly certain testing sites.

Would this be better solved by setting timeouts in a site or board 
configuration file?

I recognize that the remote_exec procedure is not currently sensitive to 
that either, so there will be an enhancement here for 1.6.4 either way.

I will say now that the DEJAGNU_TIMEOUT environment variable will *not* 
be accepted upstream because there are many different timeouts in 
various parts of DejaGnu and providing only a single "knob" to adjust 
all of them is not appropriate.  If there are other components in Debian 
that will need to be updated, I recommend changing the environment 
variable used to DEJAGNU_REMOTE_EXEC_TIMEOUT as an interim measure as 
soon as possible.  That name is acceptable for this purpose, although 
the possibility of instead setting a target configuration parameter is 
likely to be preferred.  There is also little difficulty in allowing an 
environment variable to override a target configuration parameter, for 
ease of development.

Also, does this need to be an environment variable or can it be a 
variable passed on the runtest command line?  (What is the surrounding 
context here?)  The latter would be preferred if feasible simply to 
reduce clutter in the environment:

[...]
+    } elsif { [info exists DEJAGNU_REMOTE_EXEC_TIMEOUT] } {
+        set timeout $DEJAGNU_REMOTE_EXEC_TIMEOUT
[...]

and add "DEJAGNU_REMOTE_EXEC_TIMEOUT=600" to the runtest command line.  
Such variables are set early in runtest.exp while parsing the command 
line but are distinct from the environment.

Backporting patches for this to 1.6.2 and 1.6.3 for Debian should be 
fairly easy once they land on Git master for 1.6.4.


-- Jacob

Message #15 received at 48611 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: 48611 <at> debbugs.gnu.org
Subject: Re: bug#48611: Allow DEJAGNU TIMEOUT env var for slow arches
Date: Mon, 24 May 2021 19:02:40 -0500

Now that I have had a chance to sleep on this, I will save you some 
trouble:  an environment or command line variable will not be accepted 
upstream for this and 1.6.4 will add a board_info key for this purpose.

The rationale is that DejaGnu can support testing runs spanning multiple 
targets, and in the future will support multiple targets in parallel 
testing mode as well.  There is no good way to limit the scope of an 
environment variable or command line variable to only one target, and 
different target boards may need different timeout values.  The 
board_info structures are the correct place for this information.

While 1.6.4 may possibly rework board_info internally, I will try to 
keep the changes to lib/remote.exp simple enough for Debian to easily 
backport them to 1.6.3 and/or 1.6.2.


-- Jacob

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.