This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [MI non-stop 03/11, RFA] Discard cleanup when deferring displaced step
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 11 Jul 2008 17:21:24 +0400
- Subject: Re: [MI non-stop 03/11, RFA] Discard cleanup when deferring displaced step
- References: <200806282039.52280.vladimir@codesourcery.com> <200807111410.58951.pedro@codesourcery.com>
On Friday 11 July 2008 17:10:58 Pedro Alves wrote:
> A Saturday 28 June 2008 17:39:52, Vladimir Prus wrote:
> > My MI non-stop tests (coming later in the series) revealed a bug in
> > displaced stepping -- we fail to discard cleanup on an early exit path,
> > which caused a call to normal_stop at very unfortunate time -- when a
> > thread was running.
> >
>
> Ooops, my bad. Thanks for catching this!
>
> I think it would make sense to tag the thread as running at that point.
> In the point of view of the frontend, it is running, but internally,
> it is known to not be executing, until its turn in the displaced stepping
> request queue arrives. That is, the frontend should not allow inspecting
> this thread as if it was running already, and interrupting it should make
> it stop as soon as it tries to execute, not skip over it like ends up
> happening currently.
>
> To be clear, the user told the thread to resume, it just didn't resume
> immediatelly due to an internal implementation detail. (is_running (ptid)
> && !is_executing (ptid)) should be true at that early return. Not a
> serious issue to run to fix it (may need care if starting the
> displaced step on it ends up failing), but,
>
> Anyone disagrees in principle?
Seems right to me. Should that be a separate patch, or should I adjust
this one?
- Volodya