From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17849 invoked by alias); 24 Aug 2004 14:51:23 -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 17756 invoked from network); 24 Aug 2004 14:51:17 -0000 Received: from unknown (HELO miranda.se.axis.com) (193.13.178.2) by sourceware.org with SMTP; 24 Aug 2004 14:51:17 -0000 Received: from [10.84.130.1] (ironmaiden.se.axis.com [10.84.130.1]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id i7OEpD9P009879 for ; Tue, 24 Aug 2004 16:51:13 +0200 Message-ID: <412B55E1.7040803@axis.com> Date: Tue, 24 Aug 2004 14:51:00 -0000 From: Orjan Friberg Organization: Axis Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: schedlock.exp questions Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00639.txt.bz2 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