[PATCH 2/2,v3] [AArch64] Test handling of additional brk instruction patterns

Luis Machado luis.machado@linaro.org
Wed Jan 29 14:39:00 GMT 2020


On 1/29/20 11:11 AM, Simon Marchi wrote:
> On 2020-01-29 9:09 a.m., Luis Machado wrote:
>> 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.
> 
> Thanks, that looks good to me.
> 
> Simon
> 

Pushed now. Thanks!



More information about the Gdb-patches mailing list