Re: [rfc] Preferred thread event reporting: Linux native target

["Ulrich Weigand" <uweigand@de.ibm.com>]

Michael Snyder wrote:
> Ulrich Weigand wrote:
> > Pedro Alves wrote:
> > 
> >>> -- this is actually simply the currently selected thread
> >>> (i.e. the current value of inferior_ptid).
> >> Disagreed.  inferior_ptid will change if an event happens in
> >> another thread while you're stepping, but the core decides the event
> >> was not a good reason to stop.  E.g., thread hopping.
> > 
> > Hmm, but if we "thread hop" inferior_ptid should be prefered
> > anyway (to get the internal "thread hop" action over with as
> > quickly as possible), and afterwards we're back to the thread
> > the user is looking at, right?
> 
> After that, I think, we're back to whichever thread
> the OS decides to schedule next.  I don't think there
> is any guarantee that that will be the one the user
> was previously looking at.

I think the OS scheduler is not really relevant here.
GDB assumes it can decide which of the threads of an
application it wants to *single-step*.

So if an application has threads A, B, and C, and is 
stopped on an event in B, and then decides it wants to
continue single-stepping C, it will tell the target to
continue all thread, while single-stepping C.

Now the OS scheduler may choose to run A, B, or C next
(or several of them in parallel on an SMP system), but
no matter what: we should never get single-step events
from A or B, but we should get a single-step event after
C has executed its first instruction (whenever that may
be).

The above assumption (that GDB can decide which threads
to single-step) is always true when using software single-
stepping.  It is also true for the Linux native target,
and for the remote target (assuming the remote side
implements the protocol accordingly).

There may be odd targets where this assumption is false;
GDB will probably get confused on those.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com