On 1/29/20 11:04 AM, Luis Machado wrote:
> 
> 
> On 1/29/20 11:01 AM, Simon Marchi wrote:
>> On 2020-01-29 6:30 a.m., Luis Machado wrote:
>>>>> +# Number of expected SIGTRAP's to get.  This needs to be kept in sync
>>>>> +# with the source file.
>>>>> +set expected_traps 3
>>>>> +set keep_going 1
>>>>> +set count 0
>>>>> +set old_timeout $timeout
>>>>> +set timeout 10
>>>>
>>>> Any reason you are changing the timeout?  There is nothing in the 
>>>> test that
>>>> looks like it would take time.
>>>>
>>>
>>> If GDB doesn't support one of these instructions, it will be caught in
>>> an infinite loop. The reduced timeout will prevent a long wait time
>>> until we bail out.
>>
>> Ok.  The worry I have with it is that if the target board has raised 
>> the timeout
>> on purpose, because it's testing with a slow target/link/emulator, 
>> then this will
>> cancel it.  In this case I'd just leave the timeout as it is.  
>> Normally, GDB won't
>> be broken for this test case, so it won't matter.
>>
>> Moreover, the timeout here on my x86 machine is 10 seconds by 
>> default.  I just checked
>> on an AArch64 box on the compile farm, it's 10 there too.  So in which 
>> case was it
>> useful to set it to 10?
>>
> 
> Interesting. In my mind the default was from 30 to 60. Maybe that has 
> changed over the years. If the boards are free to set it, then that is 
> more desirable.
> 
> I'll let it be then.

Here's the updated patch.