This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] Fix PR 2250 - multithreaded single-step problems in all-stop mode
- From: Pedro Alves <pedro at codesourcery dot com>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: gdb-patches at sourceware dot org, drow at false dot org
- Date: Sat, 15 Nov 2008 16:10:39 +0000
- Subject: Re: [rfc] Fix PR 2250 - multithreaded single-step problems in all-stop mode
- References: <200811142104.mAEL4JBX024219@d12av02.megacenter.de.ibm.com>
On Friday 14 November 2008 21:04:18, Ulrich Weigand wrote:
> a while ago I posted a patch to fix problem PR 2250:
> http://sourceware.org/ml/gdb-patches/2008-05/msg00089.html
>
> This problem is about the behaviour of GDB when single-stepping
> a thread of a multi-threaded application. If during a single-step
> operation, some other event happens in another thread, GDB may get
> into an inconsistent state, where some internal data structures
> still think a single-step operation is going on, while this is
> in fact no longer true.
>
> The patch I originally proposed, however, conflicted with the
> new non-stop mode (where single-step operations can be outstanding
> in multiple threads at the same time), so it was never applied.
> Now that all the non-stop code is in mainline, the original bug
> is still present in the all-stop mode. I've reworked the patch
> to fix the problem in all-stop mode, while keeping the new behaviour
> in non-stop mode unchanges.
Thank you very much for your patience and for refitting the patch.
I do find this version much cleaner than the last (for not
relying on global variables, and due to context-switching
being a thing of the past).
>
> As discussed in the message refered to above, I'm implementing the
> the following two changes:
>
> - If the step operation is interrupted by an *internal* breakpoint
> that is handled transparently, the operation continues in a
> transparent and consistent manner after the breakpoint was handled.
> (This is the handle_inferior_event change in the patch below.)
>
I still agree with this behaviour. I've made it so that GDB removes
step-resume breakpoints of all threads (in all-stop) on a normal_stop
for the same reasoning (delete_step_thread_step_resume_breakpoint).
> - If the step operation is interrupted by an *explicit* breakpoint
> that breaks to a user prompt, it is completely cancelled. It is
> then up to the user how to continue from the prompt.
> (This is the clear_proceed_status change in the patch below.)
Yay! I had something similar here to address this bullet (updated
from the last time I showed it, but unfinished and a bit hacky) that
I ended up never submitting. Yours is better.
> Regression tested on powerpc64-linux. This patch fixes the problem
> originally reported as PR 2250 (thanks to Emi Suzuki for verifying!).
>
> I didn't test anything with all-stop mode, but by construction the
> patch should not modify the behaviour at all in this case.
Yeah, should be fine (obviously talking about non-stop mode here).
> Does this look right? If there are no objections, I'm planning
> on committing this in a couple of days.
I like this a lot.
Hmm, speaking of things that aren't cleared properly in all
threads when we are going to start a proceed, shouldn't the
things cleared in init_thread_stepping_state be cleared
in clear_proceed_status_thread instead? E.g.,
step_after_step_resume_breakpoint, etc.
--
Pedro Alves