This is the mail archive of the
mailing list for the GDB project.
Re: [pushed] Fix adjust_pc_after_break, remove still current thread check
- From: Pedro Alves <palves at redhat dot com>
- To: GDB Patches <gdb-patches at sourceware dot org>
- Date: Thu, 12 Feb 2015 18:32:40 +0000
- Subject: Re: [pushed] Fix adjust_pc_after_break, remove still current thread check
- Authentication-results: sourceware.org; auth=none
- References: <54DB2843 dot 3040008 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
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.