From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6125 invoked by alias); 12 Feb 2004 21:53:45 -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 6108 invoked from network); 12 Feb 2004 21:53:40 -0000 Received: from unknown (HELO nick.uklinux.net) (194.247.48.135) by sources.redhat.com with SMTP; 12 Feb 2004 21:53:40 -0000 Received: by nick.uklinux.net (Postfix, from userid 501) id 869A875FDE; Thu, 12 Feb 2004 21:43:38 +0000 (GMT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16427.62345.989794.926455@nick.uklinux.net> Date: Thu, 12 Feb 2004 21:53:00 -0000 To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: RFA (?) Annotate Level 3 patch In-Reply-To: <40296BF1.7060900@gnu.org> References: <16176.3560.65649.7079@nick.uklinux.net> <4016A245.6030001@gnu.org> <16414.51421.622553.831432@nick.uklinux.net> <40296BF1.7060900@gnu.org> X-SW-Source: 2004-02/txt/msg00327.txt.bz2 > > Moving annotate_stopped to the start of normal_stop seems to do the right > > thing. It might be bad practice, however, to break existing functionality > > so a better solution might be to create a new annotation there - aargh! - > > called stopping, say, instead. However, remember that I will have reduced > > my initial set of 25 annotations to 14. They would be: > > > > > > pre-prompt prompt post-prompt > > commands overload-choice query > > prompt-for-continue source starting > > exited signalled signal > > stopped > > > > and stopping > > Could stopped be zapped from annotate level-3 then? Well "stopped" is in my list above as a conservative measure to keep existing functionality. Since all stop (normal or otherwise) seem to go through normal_stop, I think that one annotation (called stopped or stopping) at the start of this procedure is sufficient for my purposes. On a related matter, as the Machine Interface evolves, Emacs will have to do different things for different versions of GDB, so it would be helpful if "show version" ("-gdb-show version") or a related command gave a formally defined increasing version number. In Emacs, the last release is 21.3.1 and the version in CVS is 21.3.50. In GDB, the last release is 6.0 but the version in CVS is 2004-02-01-cvs, say. Also releases, like 5.3postxxxx.. exist. Perhaps I can get a mode to work just with GDB/MI before the next release of Emacs from HEAD, which is where my code resides. However, unlike GDB, Emacs has no schedule ;-) Nick