[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