From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29096 invoked by alias); 2 May 2008 16:59:20 -0000 Received: (qmail 29082 invoked by uid 22791); 2 May 2008 16:59:19 -0000 X-Spam-Check-By: sourceware.org Received: from mail.windriver.com (HELO mail.wrs.com) (147.11.1.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 May 2008 16:58:58 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m42GwUiD017209; Fri, 2 May 2008 09:58:30 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 May 2008 09:58:29 -0700 Received: from [147.11.37.213] ([147.11.37.213]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 May 2008 09:58:29 -0700 Message-ID: <481B4830.9040909@windriver.com> Date: Fri, 02 May 2008 16:59:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: Vladimir Prus CC: Marc Khouzam , Pedro Alves , gdb@sourceware.org Subject: Re: MI non-stop interface details References: <6D19CA8D71C89C43A057926FE0D4ADAA042910AB@ecamlmw720.eamcs.ericsson.se> <200805012111.31584.vladimir@codesourcery.com> <481A068B.3060208@windriver.com> <200805021820.47837.vladimir@codesourcery.com> In-Reply-To: <200805021820.47837.vladimir@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: 2008-05/txt/msg00025.txt.bz2 Vladimir Prus wrote: > On Thursday 01 May 2008 22:06:03 Pawel Piech wrote: > >> Vladimir Prus wrote: >> >>> On Wednesday 30 April 2008 21:20:24 Pawel Piech wrote: >>> >>> >>>> Vladimir Prus wrote: >>>> >>>> >>>>> Again -- exec-continue resuming just one thread will be a change in behaviour. >>>>> We can take two approaches: >>>>> >>>>> 1. The MI interface we've discussed for non-stop is essentially MI3 (and will >>>>> be used both in all-stop and non-stop mode). We're in position to change anything >>>>> we like, and are not bound by backward compatibility, or anything. >>>>> >>>>> 2. The MI interface for non-stop is MI2 + minimal set of changes. I think that >>>>> Pawel's opposition to the --thread idea indicates that he prefers this approach. >>>>> Then, we rather not change the behaviour of existing commands. >>>>> >>>>> There are not many high-level warts in MI2/non-stop/async, so I'm willing >>>>> to go with (2). >>>>> >>>>> - Volodya >>>>> >>>>> >>>>> >>>> First of all I really appreciate your effort to maintain backward >>>> compatibility. I know that it can seriously complicate the effort to >>>> add new features but I believe this effort pays off in quicker and more >>>> reliable adoption by the users (IDEs). However, there are two kinds of >>>> backward compatibility goals to consider: >>>> 1) Allowing old GDB clients to use the new, extended protocol. >>>> 2) Allow clients that use the extended protocol to easily work with old >>>> protocol versions. And by "easily", I mean that the client should be >>>> able to not have "if(non-stop) { use command a } else { use command b}" >>>> kind of logic scattered throughout its implementation. >>>> >>>> >>> Why do you have such a goal? >>> >>> >> Adoption of new versions of GDB is gradual, so for clients support for >> old versions of GDB is very important. >> > > The "else" branch of your conditional handles old version of GDB, no? > As I mentioned before, having lots of "if (new)... else (old)..." makes the code hard to maintain after a while. I think Nick got it right, maintaining backward compatibility is more work for the server, dealing with incompatibilities is more work for the client. Right now what you're saying is: "what's the big deal, just do a little more work". Keep in mind though, there is one server, and many clients. > >>> Currently, both *running and *stopped have "thread-id" field. >>> >>> >> But your proposal doesn't add any fields to the events indicating >> whether the stopped event stops a single thread or the whole process. >> > > If the thread-id field has a value of "all", then all threads are stopped, > but it's just a shortcut for a number of *stopped, one per each thread. > This leaves out an important piece of information: the triggering thread, which is used by the IDE to decide which thread should get the focus. You may not see a use case for it now, but sooner or later you will add an option to the breakpoint to stop all threads in non-stop mode and you'll want to tell the client which thread hit the breakpoint. Also this behavior is incompatible with the all-stop mode (in new or old GDB versions). I.e. is the all-stop mode always going to report thread-id="all" for every stopped and running event? I suppose you'll say to just add another if-else statement... >>> I'll probably start designing multi-process extensions for MI this week, >>> and will look into these suggestions. Why are you trying to use same >>> namespace for process ids and thread ids? >>> >>> - Volodya >>> >>> >> I see no reason to create a separate name space and in fact adding >> another name space just requires more logic to maintain it. thread-id >> is just a handle that is obtained through well-documented commands, the >> MI clients are not likely to get confused by the fact that containers >> and threads are in the same namespace. Additionally, if GDB was ever to >> support more hierarchical systems: such as >> target->core->processes->threads, it will have to keep revising the >> protocol (in incompatibility inducing ways) to keep up. But I guess >> you'd have to believe that this is a real issue first. >> > > I think the MI commands to query the hierarchy of "containers" will be fairly > agnostic of the actual meaning of each containers (just like variable objects > allow to describe arbitrary structure). That said, I'm not 100% that > making the namespace of containers and namespace of thread IDs is not going > to upset existing frontends. > > - Volodya > Can you think of a scenario in a client which would break? Would KDevelop break? Maybe implementers of other client can speak up on this. -Pawel P.S. I really appreciate your effort and attention to resolve these issues.