Re: [rfc] Fix PR 2250 - multithreaded single-step problems in all-stop mode

[Pedro Alves <pedro@codesourcery.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