This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [MI non-stop 03/11, RFA] Discard cleanup when deferring displaced step


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]