[PATCH 0/4] Handle test execution timeout consistently across protocols

[Maciej W. Rozycki]

Hi,

 This patch series spawned as a side effect of our local change to deal 
with excessively slow GCC test cases scoring false failures due to hitting 
the execution timeout.

 To avoid excessive testsuite run times where other test cases do hang, as 
it would be the case if the timeout set globally was to be increased, we 
implemented a test execution timeout scaling factor for individual test 
cases identified as being slow to request via the GCC test harness (to be 
reused by different tools as required), just as we already do in other 
places.  This is different from the tool execution timeout where (in this 
case) it is GCC execution that is being guarded against taking excessive 
amount of time on the test host (which does hit sometimes too) rather than 
the resulting test case executable run on the target afterwards (where 
applicable).

 In the course we revealed an inconsistency across various DejaGNU target 
board communication protocols in setting the base test execution timeout, 
from full flexibility for local Unix targets, through correlation with the 
base timeout for some other targets, to fixed 120s for the GDB stub 
protocol.

 This small patch series addresses the inconsistency by borrowing from our 
local Unix target case.  It also adds consistent reporting of the test 
case execution command and timeout across the protocols involved.

 The intent is to avoid having to override the respective TCL procedures 
locally just to correct the timeout handling shortcomings in the versions 
shipped with DejaGNU.

 This has been verified with the GCC testsuite in a couple of environments 
using the Unix protocol, both locally and remotely, the GDB stub protocol, 
and the sim protocol, making sure that timeout settings are respected.  I 
found no obvious way to verify the remaining parts, but the changes follow 
the same pattern, so they're expected to behave consistently.

 A change for the timeout factor will follow.  As it consists of a DejaGNU 
part and a GCC part I chose to send it separately so as not to cross-post 
this whole series between the DejaGNU and GCC mailing lists.

 Any questions, comments, or concerns?  Otherwise please apply.

  Maciej