[rfc] Preferred thread event reporting: Linux native target
Ulrich Weigand
uweigand@de.ibm.com
Mon Aug 18 18:19:00 GMT 2008
Pedro Alves wrote:
> On Friday 15 August 2008 23:54:31, Pedro Alves wrote:
>
> > > and afterwards we're back to the thread
> > > the user is looking at, right?
> >
> > Well, in all-stop, there's nothing doing that currently. when
> > you switch inferior_ptid (in all-stop mode) to handle a
> > possible stop, and then you decide you should not stop, there's
> > nothing reverting back to the previous thread. inferior_ptid will
> > stay pointing to the last thread you resumed (the hopping thread),
> > until you hit another stop event, and context_switch to the thread
> > that took it.
>
> Hmmm, I was just taking another look at this, and,
> you may be right here.
>
> We'd have also have requested a single-step in the thread we
> wanted before detecting a need for a thread hop, so, when we
> get to eventually handling that original single-step
> finishing, we'd context-switch to it again. I guess this
> would make your change OK. If not, how does this work then?
Yes, that was my thought. We *have* to get inferior_ptid right
on platforms with hardware single-step (because linux-nat.c will
only hardware step that thread), and therefore we will also get
inferior_ptid right on platforms with software single-step
(because the code is the same).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
More information about the Gdb-patches
mailing list