schedlock.exp questions
Daniel Jacobowitz
drow@false.org
Tue Aug 24 14:55:00 GMT 2004
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
More information about the Gdb-patches
mailing list