From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11140 invoked by alias); 3 Mar 2003 01:04:55 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11067 invoked from network); 3 Mar 2003 01:04:53 -0000 Received: from unknown (HELO white) (68.14.146.65) by 172.16.49.205 with SMTP; 3 Mar 2003 01:04:53 -0000 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 18peNx-00011b-00 for ; Sun, 02 Mar 2003 20:04:53 -0500 Date: Mon, 03 Mar 2003 01:04:00 -0000 From: Bob Rossi To: gdb@sources.redhat.com Subject: Re: GDB/MI revisited Message-ID: <20030303010452.GA3920@white> Mail-Followup-To: gdb@sources.redhat.com References: <15940.5214.123419.414411@nick.uklinux.net> <3E5CEA03.2070007@redhat.com> <15967.54551.724257.774642@nick.uklinux.net> <3E616E6D.1080908@redhat.com> <15970.39290.513649.825076@nick.uklinux.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15970.39290.513649.825076@nick.uklinux.net> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-03/txt/msg00037.txt.bz2 On Sun, Mar 02, 2003 at 11:53:30PM +0000, Nick Roberts wrote: > > > > I would prefer this approach too since the GUD buffer would then allow > > > completion. However, without level 2 annotations, the CLI is useless to the > > > lisp package that I have written, so I don't see how an incremental migration > > > is possible. > > > > Why exactly is it useless? Using both [deprecated] level 2 annotations > > and "interpreter mi ..." simultaneously. > > Ah! I follow you now. Does this mean that you would like to incrementally > obsolete annotations? This relates to something that I said earlier: > > NR> Also gdb-ui.el probably doesn't need all the annotations. If you lost some > NR> key ones (frames-invalid and breakpoints-invalid, for example) would this > NR> make it easier to maintain? > > I will give incremental migration some thought but unless the benefits are > clear (for you or me) I think it might be easier to do in one go. > > > > > You could even continue to use "run". > > > > > > Except that the manual says: > > > > > > This mechanism is provided as an aid to developers of GDB/MI clients > > > and not as a reliable interface into the CLI. Since the command is > > > being interpreteted in an environment that assumes GDB/MI behaviour, > > > the exact output of such commands is likely to end up being an > > > un-supported hybrid of GDB/MI and CLI output. > > > > > > Also "run" generates ^done rather than *stopped and I am trying to use the > > > latter to update the source file display. > > > > The manual is refering to this behavior: > > > > (gdb) > > target sim > > &"target sim\n" > > ~"Connected to the simulator.\n" > > ^done > > (gdb) > > > > The new behavior vis: > > > > (gdb) > > -interpreter-exec console "target sim" > > ~"Connected to the simulator.\n" > > ^done > > (gdb) > > > > is documented and supported. > > OK, but `-interpreter-exec console' run still generates ^done rather than > *stopped so I would need to recognise this. > > > > > You mean something like: > > > > > > > > -interpreter-exec console break foo > > > > ~Breakpoint 1 created. > > > > =breakpoint-create,breakpoint={nr=5,location=foo,file=bar.c,line=47} > > > > > > I was thinking explicitly of *stopped. I haven't found a need for the others > > > yet. > > > > To clarify something about level 2 annotations, what exactly is this new > > emacs code dependant on? For level two annotations the rough equivalent > > to the above is (ignore the yy): > > > > > info break > > > > > > yypost-prompt-for-continue > > > yyarg-value * > > > 0x2000000 > > > yyarg-end > ... > > How is info break roughly equivalent to break foo? > > > and it is these markups that GDB wants to get away from. They are what > > is littered through out GDB's code and the motivator behind getting rid > > of level two annotations. > > Yes. I follow this. > > > > > That is the second change sitting on the interpreters branch. > > > > > > I've checked out interps-20030202-branch. This doesn't seem to do the above. > > > Should I have a different version? Does it generate the *stopped record in > > > the manner that I would like? Does it work with interpreter mi mi-command > > > also? > > > > Hmm, so to split this into two problems. How much of each of: > > > > - markups, as in the above marking up of the breakpoint out > > - events, as in things like `*stopped' > > > > is this code dependant on? > > The current code (gdb-ui.el) is completely dependent on the markups that > annotations provides. I want the new code to use `*stopped' to update file > display. If this works as I would like (as described above and previously) > then together with the `^done' record it should provide most of the > functionality that Emacs needs. > > > > > I don't think it is immediatly necessary though as the imediate objective > > > > is to just address the problem of level two annotations littered through > > > > out things like the breakpoint code. > > > > > > I don't follow. Aren't they interconnected? I thought the idea was that the > > > quicker that MI got adopted the quicker level two annotations could be dropped > > > > The concern is with the marking up of things like breakpoint output. > > Event notification, I believe, is less of a problem. > > If this is the case, I *think* I could modify gdb-ui.el not to use the > annotation breakpoints-invalid quite easily. I don't know what other users > of level 2 annotations, e.g the authors of cgdb, would think, though. cgdb doesn't depend on breakpoints-invalid because they were unreliable in some versions of gdb. For example, when the user deleted the last breakpoint, the 'breakpoints-invalid' wouldn't be triggered. So, cgdb requests the breakpoints after every user command. It would be great if in MI, the client could ask for notifications that it is interested in ( breakpoints, source file and line, variables ... ) Bob Rossi