Re: [pushed] Fix adjust_pc_after_break, remove still current thread check

[Pedro Alves <palves at redhat dot com>]

On 02/11/2015 10:00 AM, Pedro Alves wrote:
> Yet another latent bug exposed by all-stop-on-top-of-non-stop.
> Kind of hard to believe we still get this wrong.

...

> I can't find any reason we'd need the "thread to be examined is still
> the current thread" condition in adjust_pc_after_break, at least
> nowadays; it might have made sense in the past.  Best just remove it,
> and rely on currently_stepping().

Bah, I knew this exposed further bugs, but didn't recall that those
bugs are already visible in plain non-stop without the rest of the series
I'm working on.  With this patch, non-stop-fair-events.exp sometimes
FAILs with:

Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.threads/non-stop-fair-events.exp ...
FAIL: gdb.threads/non-stop-fair-events.exp: signal_thread=6: thread 11 broke out of loop (timeout)
FAIL: gdb.threads/non-stop-fair-events.exp: signal_thread=7: continue -a&
FAIL: gdb.threads/non-stop-fair-events.exp: signal_thread=7: thread 1 restarted (timeout)
FAIL: gdb.threads/non-stop-fair-events.exp: signal_thread=7: thread 2 restarted (timeout)
FAIL: gdb.threads/non-stop-fair-events.exp: signal_thread=7: thread 3 restarted (timeout)

It's not a problem with this patch.  Rather, this patch exposes a
fundamental problem of moribund breakpoints.  I have a patch to
address it, which I've been testing on a few different GNU/Linux archs
today.  I'll send it out as soon as I get a chance.

Thanks,
Pedro Alves