Re: [PATCH v2 00/23] All-stop on top of non-stop

[Pedro Alves <palves@redhat.com>]

On 04/10/2015 09:21 AM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> While v1 had only been tested on x86-64 GNU/Linux, v2 was tested on:
>>
>>      x86-64 GNU/Linux
>>      x86-64 GNU/Linux on top of software single-step branch
>>      PPC64 GNU/Linux
>>      S/390 GNU/Linux
> 
> I also tested this series on aarch64 GNU/Linux (hardware single step, no

Thanks!

> displaced stepping) with GDBserver.  Some regressions in
> gdb.threads/non-stop-fair-events.exp.
> 
> (gdb) PASS: gdb.threads/non-stop-fair-events.exp: signal_thread=2: continue &
> ^M
> Program received signal SIGUSR1, User defined signal 1.^M
> FAIL: gdb.threads/non-stop-fair-events.exp: signal_thread=2: thread 1 broke out of loop (timeout)
> FAIL: gdb.threads/non-stop-fair-events.exp: signal_thread=2: thread 2 broke out of loop (timeout)
> FAIL: gdb.threads/non-stop-fair-events.exp: signal_thread=2: thread 3 broke out of loop (timeout)

Fun.   TBC, that was only with gdbserver, right?

I suspect the test was only passing by change before though.
AFAICS, aarch64 doesn't have a displaced stepping implementation.
I'd suspect current master fails other non-stop tests? (and hopefully
this series fixes them).

So GDB should now be falling back to stopping all threads to
step past the breakpoint on aarch64, while before threads were
just missing breakpoints.   Likely something wrong with that
with remote targets still.

Thanks,
Pedro Alves