From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25701 invoked by alias); 30 Nov 2006 23:22:50 -0000 Received: (qmail 25441 invoked by uid 22791); 30 Nov 2006 23:22:47 -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:22:39 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 1D547103C3F; Thu, 30 Nov 2006 15:22:37 -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 17685-01-65; Thu, 30 Nov 2006 15:22:33 -0800 (PST) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id 53DBC103CC8; Thu, 30 Nov 2006 15:22:33 -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:22:33 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 30 Nov 2006 15:22:32 -0800 Subject: Re: Single stepping and threads From: Michael Snyder To: Daniel Jacobowitz Cc: gdb@sourceware.org In-Reply-To: <20061129052942.GA16029@nevyn.them.org> References: <20061129052942.GA16029@nevyn.them.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 30 Nov 2006 23:22:00 -0000 Message-Id: <1164928952.14460.22.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/msg00252.txt.bz2 On Wed, 2006-11-29 at 00:29 -0500, Daniel Jacobowitz wrote: > Ulrich's message earlier reminded me of something I've been meaning to > discuss for a while. This isn't specific to software single stepping, > but to single step in general for threaded programs. > > We have a knob "set scheduler-locking". It offers three values: > > Set mode for locking scheduler during execution. > off == no locking (threads may preempt at any time) > on == full locking (no thread except the current thread may run) > step == scheduler locked during every single-step operation. > In this mode, no other thread may run during a step command. > Other threads may run while stepping over a function call > ('next'). > > The default is "off". Should it be "step" instead? The example I used > to use whenever someone asked me about this was single stepping through > something like a barrier or mutex; if other threads don't run, you > won't advance, because no other thread will have a chance to release > the lock. That much is true. But it seems like a reasonable thing to > document and reference "set scheduler-locking". And having threads > run during single stepping has surprised a lot of users who've asked > me about the current behavior. > > What do you all think? I implemented "set scheduler-locking", at user request. The behavior that the users were requesting is "step". I left the default at "off", because that was gdb's original behavior, and I didn't want to change it out from under people without notice. It may very well be time to change the default. > > One reason I've procrastinated bringing this up is that set > scheduler-locking off, the current default, has a lot more nasty > corner cases that I've meant to look into; if step becomes the default, > I suspect more of those will linger unfixed. But users won't encounter > them as often, which is much like fixing them :-) > > A related issue is the tendency of "step" to let other threads run even > in "set scheduler-locking step". For instance: > > - We use a breakpoint to skip the prologue of a function when we step > into it. This could either be implemented with a stepping range > instead, or else we could continue to use the breakpoint but honor > the scheduler locking mode anyway, but the current behavior is > silly. > > - "step" acts like "next" when stepping over a function without debug > info. Should we honor "set scheduler-locking step" when doing > this? >