From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24747 invoked by alias); 24 Aug 2004 14:55:06 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24619 invoked from network); 24 Aug 2004 14:55:03 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 24 Aug 2004 14:55:03 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BzchT-0006rd-6k; Tue, 24 Aug 2004 10:55:03 -0400 Date: Tue, 24 Aug 2004 14:55:00 -0000 From: Daniel Jacobowitz To: Orjan Friberg Cc: gdb-patches@sources.redhat.com Subject: Re: schedlock.exp questions Message-ID: <20040824145502.GA26280@nevyn.them.org> Mail-Followup-To: Orjan Friberg , gdb-patches@sources.redhat.com References: <412B55E1.7040803@axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <412B55E1.7040803@axis.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-08/txt/msg00640.txt.bz2 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