Re: [RFA] New threads test

[Daniel Jacobowitz <drow at mvista dot com>]

On Thu, Oct 09, 2003 at 05:05:33PM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> >On Thu, Oct 09, 2003 at 12:41:16PM -0700, Michael Snyder wrote:
> >
> >>Daniel Jacobowitz wrote:
> >>
> >>>On Wed, Oct 01, 2003 at 02:52:30PM -0400, Daniel Jacobowitz wrote:
> >>>
> >>>
> >>>>On Wed, Oct 01, 2003 at 11:37:11AM -0700, Michael Snyder wrote:
> >>>>
> >>>>
> >>>>>Daniel Jacobowitz wrote:
> >>>>>
> >>>>>
> >>>>>>This is a test for the remote protocol issue I'm solving with vCont.  
> >>>>>>It
> >>>>>>also shows up in schedlock, but the simpler test makes it much clearer
> >>>>>>what's going wrong.  OK?
> >>>>>>
> >>>>>
> >>>>>Umm... what is going wrong?  What are you testing for here?
> >>>>
> >>>>+# It tests that the correct thread is single-stepped.
> >>>>
> >>>>More intelligibly: when gdbserver is told to single-step one thread
> >>>>(without holding all others schedlocked), it assumes we mean the first
> >>>>thread.  Which might not be the _right_ thread.
> >>
> >>Hmmm... it should assume we mean the _current_ thread
> >>(ie. the one that had a stop event).  The remote protocol
> >>should cover this (and did, last I checked).
> >
> >
> >I could have changed gdbserver to default to that, in fact I thought I
> >had (but I hadn't).  But it still breaks down if the user switches
> >threads explicitly - 
> 
> Hmmm, that's what target_prepare_to_proceed is supposed to handle.
> Err... was.  What happened to it?  I missed this discussion, I guess.

It's still there.  It turned out that all of the architecture specific
versions could be replaced by a generic one.

prepare_to_proceed is part of the solution, yes - the reason that it
was changed was because I also ran into that when working on the same
problem.  But the problem is that the remote protocol wasn't rich
enough to describe what we wanted to do.  Particularly the difference
between:
  step thread 3
  step thread 3 and let all other threads run

We got instead:
  step thread 3
  step some thread and let all other threads run


> >see vCont, which this is testing.
> 
> Can you refer me to the threads on vcont?  I've been seeing
> references to it, but haven't found the origin or the definition.

The origin is hard to follow in the list archives, since the
conversation took six or seven months.  You can find the final
definition at:
  http://sources.redhat.com/ml/gdb/2003-10/msg00020.html
and some earlier discussion at:
  http://sources.redhat.com/ml/gdb/2003-09/msg00210.html
and
  http://sources.redhat.com/ml/gdb-patches/2003-09/msg00624.html

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer