From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2149 invoked by alias); 30 Nov 2006 23:38:45 -0000 Received: (qmail 2140 invoked by uid 22791); 30 Nov 2006 23:38:44 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 30 Nov 2006 23:38:39 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 354D7FF319; Thu, 30 Nov 2006 15:38:38 -0800 (PST) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19537-07; Thu, 30 Nov 2006 15:38:36 -0800 (PST) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id 8A0EF103D7C; Thu, 30 Nov 2006 15:35:02 -0800 (PST) Received: from 192.168.92.189 ([192.168.92.189]) by ussunex01.palmsource.com ([192.168.101.9]) via Exchange Front-End Server owa.palmsource.com ([10.0.20.17]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Nov 2006 23:35:02 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 30 Nov 2006 15:35:01 -0800 Subject: Re: Single stepping and threads From: Michael Snyder To: Daniel Jacobowitz Cc: gdb@sourceware.org In-Reply-To: <20061129133637.GB28834@nevyn.them.org> References: <20061129052942.GA16029@nevyn.them.org> <6734.193.137.208.250.1164804049.squirrel@webmail.xs4all.nl> <20061129133637.GB28834@nevyn.them.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 30 Nov 2006 23:38:00 -0000 Message-Id: <1164929701.14460.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00257.txt.bz2 On Wed, 2006-11-29 at 08:36 -0500, Daniel Jacobowitz wrote: > On Wed, Nov 29, 2006 at 01:40:49PM +0100, Mark Kettenis wrote: > > Are you talking about stepi or step? > > For step we should be very careful, since on some platforms the dynamic > > linker may play games with locks and we risk a deadlock if we don't let > > the other threads run. > > That's the second part of the question :-) The current setting of > "set scheduler-locking" applies to whenever proceed() is told to step, > rather than when the user says "step". So it affects stepi always and > step within a source line, but not step over a function. That was intentional -- a compromise between more stringent locking, and the tendency to deadlock. The idea was, "a function call is too long to keep the scheduler locked, unles you insist on locking it down completely (schedlock on)". > I talked > about "stepping" over prologues and over functions without debug info; > I hadn't thought about skipping shared library trampolines, but I > can definitely see how that would be a problem. > > I don't like the user interface here; we say "step" and it will > sometimes run one thread and sometimes run all threads and it's hard to > explain which. But we may not be able to do better without adding > unacceptable risk of deadlocks :-( >