[v2] gdb/testsuite: Consume all debug output in gdb.base/osabi.exp

  The Linaro CI runs the GDB testsuite using the read1 tool, which
significantly increases the time it takes DejaGNU to read inferior output.
On top of that sometimes the test machine has higher than normal load,
which causes tests to run even slower.

Because the gdb.base/osabi.exp enables "debug arch" output, which is
somewhat verbose, it sometimes fails when running in the Linaro CI
environment.

Fix this problem by consuming each line of output from GDB, which causes
DejaGNU to reset the timeout after each match (IIUC).

Suggested-by: Simon Marchi <simark@simark.ca>
---

Hello,

v1 attempted to solve this problem by using "with_read1_timeout_factor 10".
Following Simon's suggestion, this version keeps DejaGNU busy instead.

 gdb/testsuite/gdb.base/osabi.exp | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)
  

Thiago Jung Bauermann <thiago.bauermann@linaro.org> writes:

> index 9bbfff52bae8..d48925d806b4 100644
> --- a/gdb/testsuite/gdb.base/osabi.exp
> +++ b/gdb/testsuite/gdb.base/osabi.exp
> @@ -23,8 +23,27 @@ require !gdb_debug_enabled
>  
>  proc test_set_osabi_none { } {
>      clean_restart
> +    # Because the test enables debug output, which is somewhat verbose, if we look
> +    # just for the specific line we want to see may timeout before GDB prints
> +    # the next prompt when running in very slow or overloaded machines
> +    # (especially when the read1 tool is used).  We need to consume all the
> +    # debug output to avoid triggering the timeout.
>      gdb_test_no_output "set debug arch 1"
> -    gdb_test "set osabi none" ".*gdbarch_find_by_info: info.osabi 1 \\(none\\).*"
> +    set saw_info_osabi 0
> +    set test "set osabi none"
> +    gdb_test_multiple $test $test {
> +	-re "\r\ngdbarch_find_by_info: info.osabi 1 \\(none\\)\r\n" {
> +	    set saw_info_osabi 1
> +	    exp_continue
> +	}
> +	-re "\r\n\[^\r\n\]+\r\n" {

Rereading the patch, it just occurred to me that while this is
guaranteed to work with read1, the pattern could match the line with the
GDB prompt in normal buffered read mode, and prevent the pattern below
from matching. I'll think more about it and post a v3 later.

> +	    # Consume all otherwise unmatched lines.
> +	    exp_continue
> +	}
> +	-re "$::gdb_prompt \$" {
> +	    gdb_assert { $saw_info_osabi } $test
> +	}
> +    }
>  }
>  
>  test_set_osabi_none
  

On 2024-03-02 10:14, Thiago Jung Bauermann wrote:
> 
> Thiago Jung Bauermann <thiago.bauermann@linaro.org> writes:
> 
>> index 9bbfff52bae8..d48925d806b4 100644
>> --- a/gdb/testsuite/gdb.base/osabi.exp
>> +++ b/gdb/testsuite/gdb.base/osabi.exp
>> @@ -23,8 +23,27 @@ require !gdb_debug_enabled
>>  
>>  proc test_set_osabi_none { } {
>>      clean_restart
>> +    # Because the test enables debug output, which is somewhat verbose, if we look
>> +    # just for the specific line we want to see may timeout before GDB prints
>> +    # the next prompt when running in very slow or overloaded machines
>> +    # (especially when the read1 tool is used).  We need to consume all the
>> +    # debug output to avoid triggering the timeout.
>>      gdb_test_no_output "set debug arch 1"
>> -    gdb_test "set osabi none" ".*gdbarch_find_by_info: info.osabi 1 \\(none\\).*"
>> +    set saw_info_osabi 0
>> +    set test "set osabi none"
>> +    gdb_test_multiple $test $test {
>> +	-re "\r\ngdbarch_find_by_info: info.osabi 1 \\(none\\)\r\n" {
>> +	    set saw_info_osabi 1
>> +	    exp_continue
>> +	}
>> +	-re "\r\n\[^\r\n\]+\r\n" {
> 
> Rereading the patch, it just occurred to me that while this is
> guaranteed to work with read1, the pattern could match the line with the
> GDB prompt in normal buffered read mode, and prevent the pattern below
> from matching. I'll think more about it and post a v3 later.

Ok, one interrogation I had while reading your patch was the fact that
the two patterns above begin and end with \r\n.  I don't see how that
can possibly work, since that would consume two \r\n between each line.
I would expect to see only \r\n at the end of each pattern.  But
otherwise the logic seems good.

Simon
  

Simon Marchi <simark@simark.ca> writes:

> On 2024-03-02 10:14, Thiago Jung Bauermann wrote:
>> 
>> Thiago Jung Bauermann <thiago.bauermann@linaro.org> writes:
>> 
>>> index 9bbfff52bae8..d48925d806b4 100644
>>> --- a/gdb/testsuite/gdb.base/osabi.exp
>>> +++ b/gdb/testsuite/gdb.base/osabi.exp
>>> @@ -23,8 +23,27 @@ require !gdb_debug_enabled
>>>  
>>>  proc test_set_osabi_none { } {
>>>      clean_restart
>>> +    # Because the test enables debug output, which is somewhat verbose, if we look
>>> +    # just for the specific line we want to see may timeout before GDB prints
>>> +    # the next prompt when running in very slow or overloaded machines
>>> +    # (especially when the read1 tool is used).  We need to consume all the
>>> +    # debug output to avoid triggering the timeout.
>>>      gdb_test_no_output "set debug arch 1"
>>> -    gdb_test "set osabi none" ".*gdbarch_find_by_info: info.osabi 1 \\(none\\).*"
>>> +    set saw_info_osabi 0
>>> +    set test "set osabi none"
>>> +    gdb_test_multiple $test $test {
>>> +	-re "\r\ngdbarch_find_by_info: info.osabi 1 \\(none\\)\r\n" {
>>> +	    set saw_info_osabi 1
>>> +	    exp_continue
>>> +	}
>>> +	-re "\r\n\[^\r\n\]+\r\n" {
>> 
>> Rereading the patch, it just occurred to me that while this is
>> guaranteed to work with read1, the pattern could match the line with the
>> GDB prompt in normal buffered read mode, and prevent the pattern below
>> from matching. I'll think more about it and post a v3 later.

Actually, thinking more about it this isn't a problem because GDB
doesn't put a \r\n after the prompt, so this entry won't match the line
with the prompt.

However, I noticed that the -lbl option to gdb_test_multiple adds a very
similar regexp, so I'll change the patch to use that option in v3.

The only difference is that -lbl uses a lookahead pattern for the last
\r\n so it doesn't consume it.

> Ok, one interrogation I had while reading your patch was the fact that
> the two patterns above begin and end with \r\n.  I don't see how that
> can possibly work, since that would consume two \r\n between each line.
> I would expect to see only \r\n at the end of each pattern.  But
> otherwise the logic seems good.

That is a good point which I hadn't noticed. Thanks for pointing it out.
I fixed it in v3 by using a lookahead pattern for the \r\n at the end so
that it isn't consumed.