From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1970 invoked by alias); 1 May 2008 17:22:16 -0000 Received: (qmail 1961 invoked by uid 22791); 1 May 2008 17:22:14 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 May 2008 17:21:53 +0000 Received: (qmail 25645 invoked from network); 1 May 2008 17:21:50 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 May 2008 17:21:50 -0000 From: Vladimir Prus To: Pedro Alves Subject: Re: MI non-stop interface details Date: Thu, 01 May 2008 17:22:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb@sourceware.org, Pawel Piech , Marc Khouzam References: <200804261939.37635.vladimir@codesourcery.com> <200804301059.44112.vladimir@codesourcery.com> <200804301534.48779.pedro@codesourcery.com> In-Reply-To: <200804301534.48779.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805012121.51174.vladimir@codesourcery.com> 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: 2008-05/txt/msg00009.txt.bz2 On Wednesday 30 April 2008 18:34:48 Pedro Alves wrote: > A Wednesday 30 April 2008 07:59:43, Vladimir Prus wrote: > > On Tuesday 29 April 2008 21:48:51 Pedro Alves wrote: > > > A Tuesday 29 April 2008 18:04:57, Vladimir Prus wrote: > > > > > Pedro Alves wrote: > > > > > Can we make -exec-continue/-exec-step/-exec-next consistent, by > > > > > making the case of not passing a --thread parameter semantics > > > > > match? Given the same arguments, if one resumes just one thread, > > > > > the others should too, IMHO. > > > > > > > > Too late. -exec-continue resumes everything. -exec-step, from user > > > > standpoint, resumes one -- most users don't even know that step > > > > can resume all threads. > > > > > > Oh, I'm talking non-stop mode. It's not too late for that. > > > > > > I played a bit with eclipse/java debugging (which implements non-stop), > > > and noticed it only resumes one thread when one clicks the > > > equivalent of "continue". I have used eclipse/java heavilly in the > > > past, and I never found that unintuitive. I remember > > > looking for a "continue all" button and not finding one, but normally > > > I didn't even thing about it. Resuming one thread was just fine. > > > > Opinions differ. I think Eclipse behaviour optimized for non-common > > cases. Maybe this non-stop behaviour is good for that J2EE kind of thing, > > with zillion of threads, but it's not a good default behaviour for > > debugging ordinary applications. > > > > Eh, indeed my experience is mostly with debugging live J2EE systems. > It's also a bless to be able to hot-replace code while debugging, but > well, java makes it easier to implement. :-) I won't claim what > is common or non-common without data. Clearly, add a "resume all" > button/shorcut and you get your "common" behaviour implemented. I think it's the other way around -- add your "resume this thread" button, and you get your custom behaviour :-) > > > (I keep thinking that in non-stop mode, the exec commands without > > > --thread are equivalent to the CLI commands in non-stop mode. > > > > > > I keep forgetting to pass --thread to continue& and end up > > > resuming more than I wanted.) > > > > > > > > If we choose to always ignore the scheduler-locking setting > > > > > in non-stop mode, by making them operate on the current thread > > > > > only, we can still honour '-exec-continue --thread="all"', > > > > > or '-exec-step --all'. If people find it desirable, we can > > > > > make "scheduler-locking off" with no --thread specified mean resume > > > > > all threads. That I tend to agree is wrong in non-stop mode. I'd > > > > > rather have two buttons on the IDE -- "resume" and "resume all", > > > > > (or two keyboard shortcuts, etc.) then to export the sheduler-locking > > > > > modes to the user interface. > > > > > > > > I guess we can redefine the behaviour of -exec-continue in non-stop, or > > > > in MI3, but I worry that two different behaviours will make life too > > > > hard for frontends (and for us) > > > > > > Oh, I was talking non-stop. > > > > I don't think that adding a bunch of "if (non_stop)" is gonna be a good > > solution. > > Oh well, on the GDB side, there's no way around it. Inferior control > in non-stop is different. In non-stop, we have to resume every > thread individually in common code, and while doing it, we have to > make sure every thread is resumed with its context set. > While in all-stop, there's always only one thread with an event to > attend, and all other threads have been freezed by the debugger. When > we resume, in all-stop it's the target's responsibility to resume the > frozen threads. > A resume all in non-stop has also to take care of not resuming already > running threads -- more accuratelly it's "resume-all-stopped". This > worry doesn't exist in all-stop. > > Unless you were talking about that check in the frontend side. Have > no idea what would change, but I'd expect at least a bit of work to > enable non-stop, just not a rewrite. > > If we don't make "-exec-continue" resume only the selected thread, then > a frontend not using "--thread" should set "set scheduler-locking on" > to have a way of resuming just one thread, and GDB should > honour scheduler-locking modes in non-stop mode. This is the part > I want to have settled, as I get to tweak to code :-) Why a frontend would not use --thread for this specific command? > > Does this mean "-exec-step" with no "--thread" > and "scheduler-locking off" should step every stopped thread? I assume > not, it's not intuitive, but it's not really the same as in all-stop, > where we step one thread and resume all others, which is a > behaviour change too. I don't believe making -exec-step step just current thread will be perceived by users as a behaviour change. I bet most users don't know, and don't expect, the -exec-step command to run random other threads, hit breakpoints in those threads, etc. > (Well, we could do non-stop do that too --step current, and > resume others, meaning that non-stop with scheduler-locking off > would be similar to all-stop, *except* we don't stop all threads > when the step finishes... If we do that in common code, then, > it starts looking like we could turn "non-stop on" always, and > implement all-stop on top of it -- not really sure if that should > be a goal, or is it is possible at all, and I was going to defer > thinking about it until later on, otherwise we'll never get this done.) [Pedro and I discussed this a bit on IRC, and...] On IRC, you said: [20:40] in CLI it's lame to have to know the thread id, and to have to pass it to "continue". [20:43] break 20; ; next; next; ; another next; one step; continue; uuups, other thread resumed too... I think this is valid point -- if user, in CLI, enables non-stop, then having "continue" just work, resuming one thread, seems right. Are you going to add "--all" to "continue"? Going back to -exec-continue, it's probably best to make it behave the same way as "continue", in non-stop mode. This means that a frontend will have to conditionally pass "--all" to -exec-continue, but in any way, if a frontend enables non-stop mode, is surely has to adjust some of the logic, and changing -exec-continue logic does not seem too hard. Thanks, Volodya