schedlock.exp questions

[Orjan Friberg <orjan.friberg@axis.com>]

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?

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
}

-- 
Orjan Friberg
Axis Communications