From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24584 invoked by alias); 28 Feb 2003 21:35:02 -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 24577 invoked from network); 28 Feb 2003 21:35:00 -0000 Received: from unknown (HELO nick.uklinux.net) (194.247.48.172) by 172.16.49.205 with SMTP; 28 Feb 2003 21:35:00 -0000 Received: by nick.uklinux.net (Postfix, from userid 501) id 2839276037; Fri, 28 Feb 2003 21:31:04 +0000 (GMT) From: Nick Roberts Message-ID: <15967.54551.724257.774642@nick.uklinux.net> Date: Fri, 28 Feb 2003 21:35:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: GDB/MI revisited In-Reply-To: <3E5CEA03.2070007@redhat.com> References: <15940.5214.123419.414411@nick.uklinux.net> <3E5CEA03.2070007@redhat.com> X-SW-Source: 2003-02/txt/msg00612.txt.bz2 > > > Can you post a transcript of a typical EMACS <-> GDB session? > > > > It would depend on the user, of course, but typically GDB commands would be > > passed to gdb by two means: explicitly through the GUD buffer or through a > > lisp function. The latter could be invoked through the minibuffer, a key sequence > > or through the toolbar. > > > > I'm exploring two approaches: > > > > 1) Running gdb normally and accessing GDB/MI using "interpreter mi mi-command". > > I would recommend this aproach. > > Provides a path to a more incremental migration aproach. MI can be > exploited where it provides the greatest benefit. > > It also avoids an immediate rewrite of things like the conosle and > target I/O code. 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. > > 2) Running gdb with GDB/MI (-interp=mi) and accessing CLI using > > "-interpreter-exec console cli-command". > > I'd recommend this aproach in new development. > > > In both cases, the source file display is only updated if commands > > are issued through a lisp function. This is because in the first case the lisp > > function is bound to an mi command indirectly e.g > > > > (gud-def gud-run "interpreter mi -exec-run" nil "Run the program.") > > > > and in the second case it is bound to one directly e.g > > > > (gud-def gud-run "-exec-run" nil "Run the program.") > > 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. > ... > To clarify one point. > > GDB's biggest concern here isn't with run, et.al. Rather it is with > the IDEs relying on specific CLI output. For instance, to obtain the > information needed to display a breakpoint, a non MI IDE would issue a > command such as:... > > ... > > yypre-prompt-for-continue > > ---Type to continue, or q to quit--- > > yyprompt-for-continue > > (I think its funny here that it came back with the prompt - how does an > IDE live with this? :-) set height 0 > And then use custom pattern matching to extract the needed information. > > If GDB finds it necessary to modify the breakpoint output (add an extra > field, ...) it will likely break the GUIs that are dependant on it. > This is bad since it inhibits GDB's ability to evolve it's user > interface(1). > > On the other hand, if an MI command is used vis:... > > ... > While unreadable to the naked eye it is easily parsable by software. > Further, since the gdb.mi/* testsuite is testing this behavior the > likelyhood of unintentional breakage is lessened (of course the MI > interface will evolve, but the evolution can be managed). Yes. I follow this. > > Conversely, in both cases, GDB commands entered through the GUD buffer do not > > currently generate `*stopped' and source display is not updated. > > > > QUESTION: Is it possible to modify GDB so that it does generate `*stopped' in > > these cases? > > > > The first case would require that a cli command generates out of bound > > records. This would require a change in behaviour in gdb so need its own flag > > e.g gdb -emacs > > > > The second case would require that "-interpreter-exec console cli-command" > > generates out of bound records. This could be its defined behaviour as it > > probably would be appropriate to others. > > 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. > 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? > 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 Nick