Re: schedlock.exp questions

[Daniel Jacobowitz <drow@false.org>]

On Tue, Aug 24, 2004 at 04:51:13PM +0200, Orjan Friberg wrote:
> I'm having problems with my upcoming CRISv32 target on schedlock.exp 
> that I can't figure out (the existing CRIS target is all PASS).  (For 
> reference, the CRIS target has software single-step and is running Linux 
> 2.4.22; the CRISv32 target has hardware single-step and is running Linux 
> 2.6.6.)
> 
> From what I've understood from looking at the remote communication, 
> "set scheduler-locking off/on" just translates into whether the vCont 
> packet specifies a default action for the other threads.
> 
> First off, the "step without lock does not change thread" test doesn't 
> make any sense to me.  If we're stepping without scheduling lock, then 
> isn't the thread *allowed* to change?  Unless I've misunderstood, 
> shouldn't both "changed thread" and "didn't change thread" be OK in this 
> case?

No.  The request was "single-step this thread, but allow other threads
to run while you do it".  Other threads might report a breakpoint (not
possible in this testcase), but they shouldn't report a single-step
trap - they shouldn't singlestep.

This is a kind of wacky behavior but it's historical.  We could support
single-step-all-threads but we don't now.

> Second, if the thread *did* change when it shouldn't (when the sheduling 
> lock is on), wouldn't it make sense to continue with whatever thread we 
> end up with?  Like this:
> 
>  if {$curthread == $newthread} {
>      pass "continue with lock does not change thread"
>  } else {
>      fail "continue with lock does not change thread (switched to 
> thread $newthread)"
> +    # If the thread changed, well, we have to live with that.
> +    set curthread $newthread
> }

No opinion.

-- 
Daniel Jacobowitz