Re: [PATCH 2/2] Enable range stepping for ARM on GDBServer

[Antoine Tremblay <antoine dot tremblay at ericsson dot com>]

Pedro Alves writes:

> On 08/31/2016 07:15 PM, Antoine Tremblay wrote:
>> 
>> Pedro Alves writes:
>> 
>>> On 08/31/2016 06:14 PM, Antoine Tremblay wrote:
>>>> This patch enables range stepping to be done in GDBServer with an ARM
>>>> target.
>>>>
>>>> There is one problem however with the gdb.threads/non-stop-fair-events.exp
>>>> test.
>>>>
>>>> Since single stepping is done in software and that displaced stepping is
>>>> not supported, threads end up hitting each others breakpoints and the main
>>>> thread can't make any progress passed a number of threads on my system.
>>>>
>>>> Thus we get:
>>>> FAIL: gdb.threads/non-stop-fair-events.exp: signal_thread=5: thread 1
>>>> broke out of loop (timeout)
>>>>
>>>> Note that even letting it go an hour doesn't help so bumping the timeout
>>>> is out of the question.
>>>>
>>>> I'm not sure what to do about this one ? kfail ? ideas ?
>>>
>>> Hmm, this is exactly the sort of problem the test is meant to
>>> catch, and the reason we do event thread randomization:
>>>
>>>  # Test that GDB in non-stop mode gives roughly equal priority to
>>>  # events of all threads.
>>>
>>> Why does it work without range stepping, but not with?
>>>
>> 
>> If I recall correctly GDBServer will report each stepi to GDB
>> without range stepping but will continue in gdbserver when range
>> stepping is on, thus the run control is different.
>> 
>> And that GDBServer's run control is not as fair as GDB's for such
>> situations.
>> 
>> Maybe it could be made to work, I remember trying a few things but after
>> spending quite some time on it I could not wrap my head around it. Thus
>> my call for ideas here.
>
> It's between hard and impossible to give out ideas without some sort
> of high level analysis of the typical loop of events gdbserver is getting
> stuck in, causing the main thread to never be given a chance to
> make progress.
>

I agree, my point is that after spending days analyzing the thing, I
can't make sense of it in resonable time and it's complicated enought
that describing the process in an email and asking for help on some
particular pieces of code doesn't seems like a process that would work.

So by ideas I mean, if someone has checked that out already, or is ready
to look into it from scratch or there's a reason that this should not be
relevant to range stepping on ARM.

> It sounds like gdbserver's event starvation avoidance isn't really
> working on sss targets with range stepping enabled.  E.g., are we
> doing the randomization too late?
>

I would need to get back into it for a few days which I can't do at the
moment to answer that. From what I recall the way the events are
selected made it so that the signal was never delivered.

I'm sorry I can't be more helpful at the moment but I wanted to post
this issue before I have to leave for a while.

However I wonder if range stepping or ARM depends on this of if we
should treat it as two different issues ?

Thank you,
Antoine