From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29939 invoked by alias); 15 Jun 2005 15:52:59 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29923 invoked by uid 22791); 15 Jun 2005 15:52:54 -0000 Received: from lakermmtao03.cox.net (HELO lakermmtao03.cox.net) (68.230.240.36) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 15 Jun 2005 15:52:54 +0000 Received: from white ([68.9.64.121]) by lakermmtao03.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050615155249.LYJG18229.lakermmtao03.cox.net@white>; Wed, 15 Jun 2005 11:52:49 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1DiaC8-0005U1-00; Wed, 15 Jun 2005 11:52:48 -0400 Date: Wed, 15 Jun 2005 15:52:00 -0000 From: Bob Rossi To: Nick Roberts , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Hooks still needed for annotations Message-ID: <20050615155248.GC20778@white> Mail-Followup-To: Nick Roberts , gdb-patches@sources.redhat.com References: <17053.24737.153388.915345@farnswood.snap.net.nz> <20050601113004.GC15414@white> <17054.10607.109160.333076@farnswood.snap.net.nz> <20050603190856.GB32722@nevyn.them.org> <17056.56022.36723.292491@farnswood.snap.net.nz> <20050603235923.GA9992@nevyn.them.org> <20050604130228.GA24976@white> <20050613031400.GF9288@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050613031400.GF9288@nevyn.them.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-06/txt/msg00195.txt.bz2 On Sun, Jun 12, 2005 at 11:14:00PM -0400, Daniel Jacobowitz wrote: > On Sat, Jun 04, 2005 at 09:02:28AM -0400, Bob Rossi wrote: > > On Fri, Jun 03, 2005 at 07:59:24PM -0400, Daniel Jacobowitz wrote: > > > They are deprecated. I believe there's a clear consensus that the > > > entire annotation system is going to go, and in the near future. Just > > > not yet. > > > > I hope that the annotations can stay until Nick and I, along with the > > Apple and Eclipse people think that the MI is stable and ready for use. > > This bit has some logical sense on its own, but not in your examples. > Eclipse uses a hybrid GDB/CLI implementation - but not annotations (as > far as I know, anyway)! Apple uses a patched GDB with substantially > different MI behavior - but not annotations (again, AFAIK)! Hi Daniel, Yes, you are right. I suppose the point I was trying to get across was that GDB/MI is very good, but just not ready full time ready on it's own. (Which we are changing rapidly) > Feel free to correct me if I'm wrong, but those are not compelling > examples of why yet another output format should stick around. The > fact that you and Nick are using them is a more compelling reason. I agree with you. > > Also, I think it's reasonable to say that GDB should have a parser that > > FE's can use. The only way to have a parser that can be tested properly > > is to allow it to be packaged and tested in GDB's testsuite. Otherwise, > > if the annotations are removed, FE's like GVD, XXGDB, DDD, KGDB, ... > > are either going to "go the way of the bison" or they are going to have > > to write code that handles GDB/MI. Do we really want 5-10 GDB/MI > > parser's out there (each with there own bugs)? > > This is also unrelated to the removal of annotations. I think that this could be related (although not a prerequisite) to the removal of annotations. Only in the sense that the annotations should stay until GDB/MI is fully mature. I do see your point though, I just have different motivations than you (I think). > I don't much think a parser is GDB's responsibility. Offering one as a > convenience, sure, maybe. Note that a lot of frontends won't get to > use it anyway! If we ship it with GDB, then it's going to be covered > under the GPL. Well, could I maintain a copy under the LGPL, and then contribute all of the modifications to the FSF GDB under the GPL? Either way, I don't care much about commercial tools. If a good parser is created, I think it's possible a lot of front ends will use it. For instance, KGDB, DDD and GVD are all free projects that could benefit from such a technology. Right? > > > - Breakpoints changing is not an asynchronous event. Stopped is an > > > async event; breakpoint-deleted is a synchronous event, even if it > > > comes from the user typing in a console window. > > > > It fits much nicer into the asyncronous case that nick posted. If > > we want to make it syncronous then I think there would have to be a > > change to the MI protocol. > > > > output ==> > > ( out-of-band-record )* [ result-record ] [ status-update ] "(gdb)" nl > > Maybe it will need a format change. But, guess what, it is still not > an asynchronous event. We don't have a comprehensive story in place > for this sort of response yet. Yes, agreed. Thanks, Bob Rossi