From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1025 invoked by alias); 4 Jun 2005 13:02:42 -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 1007 invoked by uid 22791); 4 Jun 2005 13:02:34 -0000 Received: from lakermmtao04.cox.net (HELO lakermmtao04.cox.net) (68.230.240.35) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 04 Jun 2005 13:02:34 +0000 Received: from white ([68.9.64.121]) by lakermmtao04.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050604130228.ZSUE20878.lakermmtao04.cox.net@white>; Sat, 4 Jun 2005 09:02:28 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1DeYIG-0006V9-00; Sat, 04 Jun 2005 09:02:28 -0400 Date: Sat, 04 Jun 2005 13:02:00 -0000 From: Bob Rossi To: Nick Roberts , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Hooks still needed for annotations Message-ID: <20050604130228.GA24976@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050603235923.GA9992@nevyn.them.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-06/txt/msg00045.txt.bz2 On Fri, Jun 03, 2005 at 07:59:24PM -0400, Daniel Jacobowitz wrote: > On Sat, Jun 04, 2005 at 10:33:58AM +1200, Nick Roberts wrote: > > > > > > I don't currently use breakpoints-invalid but I might wish to at one > > > > stage. I want to ensure that annotations aren't quietly removed by > > > > dismantling them bit by bit. > > > > > > If that's what you want to accomplish, your patch should include test > > > cases for these annotations. Otherwise they're likely to be "cleaned > > > up". Also, please do not comment out code; if it's wrong, it should be > > > deleted. > > > > I left the comment there to try to prevent them being removed again. If > > I remove then I would also like to remove the deprecated prefix for the > > two hooks. > > 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. For instance, I know that the Apple guys have patched MI in order for there parser to know when it is recieving an asyncronous command. I haven't got that far, but would like to see such a think in the FSF GDB. Also, last time I looked at Eclipse's source code, they were still using a hybrid GDB/CLI implementation because MI simply didn't support all of the features that they are using. 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)? > The way to prevent them from being removed again is to add test cases. > > > The point about keeping them is that they can be used for event notification > > in MI (Tue, 8 Feb 2005 10:14:31 +1300). > > > > Th manual says: > > > > > `ASYNC-CLASS ==>' > > > `"stopped" | OTHERS' (where OTHERS will be added depending on the > > > needs--this is still in development). > > > > I do not have enough knowldege of GDB to work out when breakpoint information > > changes in the code. So I would like to use the calls to breakpoints_changed > > (breakpoints-invalid) to do this and generate MI output: > > > > =breakpoint-changed,BreakpointTable={nr_rows... > > I don't know enough about MI yet to know if this is the right way to do > that. I don't think it is. > > - Certainly we should not be outputting the whole breakpoint table. > We'd want a way to represent the changes. Yeah, this is a good point. If we follow the annotations route, we could just alert the FE that the breakpoints have changed and then force them to get the new list. The wierd thing is, there is situations in GDB with annotations where GDB just spews out breakpoints-invalid over and over and over again. It creates a lot of I/O and is a source of trouble. I believe this happens when part of the code you are stepping though was not compiled with debug? > - 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 Thanks, Bob Rossi