From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9221 invoked by alias); 29 Nov 2006 05:58:58 -0000 Received: (qmail 9209 invoked by uid 22791); 29 Nov 2006 05:58:57 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 29 Nov 2006 05:58:51 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 36B6448D243 for ; Wed, 29 Nov 2006 00:58:49 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05950-02-2 for ; Wed, 29 Nov 2006 00:58:49 -0500 (EST) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id C438948D1C3 for ; Wed, 29 Nov 2006 00:58:48 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 1000) id 816E634C099; Tue, 28 Nov 2006 21:59:15 -0800 (PST) Date: Wed, 29 Nov 2006 05:58:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: Re: Single stepping and threads Message-ID: <20061129055915.GM9968@adacore.com> References: <20061129052942.GA16029@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061129052942.GA16029@nevyn.them.org> User-Agent: Mutt/1.4.2.2i 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/msg00212.txt.bz2 > 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. 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. -- Joel PS: My understanding is that not all systems support the running of an individual thread instead of the entire program. Is that right? Or do all systems support this feature?