From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28409 invoked by alias); 30 Nov 2006 23:26:26 -0000 Received: (qmail 28397 invoked by uid 22791); 30 Nov 2006 23:26:23 -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:26:16 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 14AC1103D7A; Thu, 30 Nov 2006 15:26:15 -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 18432-10-37; Thu, 30 Nov 2006 15:26:13 -0800 (PST) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id AE3C5103D70; Thu, 30 Nov 2006 15:26:13 -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:26:13 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 30 Nov 2006 15:26:12 -0800 Subject: Re: Single stepping and threads From: Michael Snyder To: Joel Brobecker Cc: gdb@sourceware.org In-Reply-To: <20061129055915.GM9968@adacore.com> References: <20061129052942.GA16029@nevyn.them.org> <20061129055915.GM9968@adacore.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 30 Nov 2006 23:26:00 -0000 Message-Id: <1164929172.14460.26.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/msg00253.txt.bz2 On Tue, 2006-11-28 at 21:59 -0800, Joel Brobecker wrote: > > The default is "off". Should it be "step" instead? > > I am not sure. On the one hand, I personally think that the current > behavior makes it harder to debug the program. I've been fustrated > a few times in the past when my next/step command got interrupted > and I found myself in another thread -> I kept using breakpoints > to do what I needed to do. > > On the other hand, this has been the default behavior for so long > that it's something you expect... I don't know how much this will > impact the users. At AdaCore, I don't remember receiving any report > of that sort from our users, and tasking in Ada is something that's > commonly used. > > The other argument against is that the debugger is supposed to be > transparent to the execution. This is not 100% true, but I think > we are very very close to it. Except maybe with certain thread > layers? Not sure, this is not my area of expertise, to say the > least. But for sure changing the setting to either "on" or "step" > will cause the debugger to affect the scheduling of the inferior. That's correct. GDB is unavoidably intrusive when it comes to thread scheduling. The default behavior ("off"), is the least intrusive, and somewhat randomly, unpredictably intrusive. "Step" would be more intrusive, and non-randomly so. It will cause the "current" thread to be strongly preferred, and other threads will probably starve. "On" is the most intrusive -- no other threads can run, and if there are any synchronization issues, the program will eventually deadlock. > > So, to summarize, I'm somewhat in favor. I'll poll my team-mates > and see if they have any interesting ideas to share on the subject. > > > 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 :-) > > I agree with that. If we decide to make that change, and that hides > issues as a result, then these particular issues become less important, > and you can spend the time working on other things that you like. > > > A related issue is the tendency of "step" to let other threads run even > > in "set scheduler-locking step". For instance: > [...] > > - "step" acts like "next" when stepping over a function without debug > > info. Should we honor "set scheduler-locking step" when doing > > this? > > I would say yes. A step should be a few instructions, while stepping > over a call is potentially a much larger number of instructions. > As a result, stepping over without letting the other threads go would > more likely cause a lock. >