This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
schedlock.exp questions
- From: Orjan Friberg <orjan dot friberg at axis dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Tue, 24 Aug 2004 16:51:13 +0200
- Subject: schedlock.exp questions
- Organization: Axis Communications
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