Re: [RFA] New threads test

[Michael Snyder <msnyder@redhat.com>]

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.

 >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.