[PATCH] [testsuite] Raise timeout factor for gdb.xml/tdesc-reload.exp

[Luis Machado]

On 4/16/21 12:55 PM, Simon Marchi wrote:
> On 2021-04-16 11:41 a.m., Luis Machado via Gdb-patches wrote:
>> For aarch64, the "info all-registers" output is very verbose.  If you run
>> this test using read1, it will timeout before the command output is done being
>> read.
>>
>> I'm using a non-read1 specific timeout factor given we may run this test in
>> parallel with many others.
>>
>> gdb/testsuite/ChangeLog:
>>
>> YYYY-MM-DD  Luis Machado  <luis.machado@linaro.org>
>>
>> 	* gdb.xml/tdesc-reload.exp: Set timeout factor to 4.
>> ---
>>   gdb/testsuite/gdb.xml/tdesc-reload.exp | 13 +++++++++----
>>   1 file changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/gdb/testsuite/gdb.xml/tdesc-reload.exp b/gdb/testsuite/gdb.xml/tdesc-reload.exp
>> index bc0f88b7ee3..5609db12225 100644
>> --- a/gdb/testsuite/gdb.xml/tdesc-reload.exp
>> +++ b/gdb/testsuite/gdb.xml/tdesc-reload.exp
>> @@ -68,10 +68,15 @@ if ![runto_main] then {
>>       return -1
>>   }
>>   
>> -# Run info registers just to check this appears to run fine with the
>> -# new target description.
>> -gdb_test "info all-registers" ".*" \
>> -    "Run info registers"
>> +# The output of this test can be very verbose depending on the architecture.
>> +# Raise the timeout factor so checks get a reasonable time to match the
>> +# pattern.
>> +with_timeout_factor 4 {
>> +    # Run info registers just to check this appears to run fine with the
>> +    # new target description.
>> +    gdb_test "info all-registers" "\[\r\n\]*" \
>> +	"Run info registers"
>> +}
>>   
>>   # Write out the current target description.
>>   gdb_test_no_output "pipe maint print xml-tdesc | cat > $xml_file_3" \
>>
> 
> Hi Luis,
> 
> When the timeout is due to one command producing lots of lines of
> output, I think it's generally better to fix it by changing the test to
> read one line at a time.  Each line should be quick to read, so won't
> reach the timeout, and the timeout will be "reset" between each line.
> 
> That could be done by using gdb_test_multiple and exp_continue.
> 
> If the issue is that GDB "thinks" for a long time before outputting
> something, because the command is computationally intensive, then
> raising the timeout makes sense, because we have now way to know whether
> GDB is doing progress or stuck.

I did notice some other tests using this approach. I ran into a couple 
cases:

- Verbose output with multiple lines.
- Verbose output with a single huge line.

Let me rework this (and possibly the other patches too).