From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16828 invoked by alias); 10 Aug 2004 23:02:29 -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 16820 invoked from network); 10 Aug 2004 23:02:27 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 10 Aug 2004 23:02:27 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i7AN3wBV010214 for ; Tue, 10 Aug 2004 16:03:58 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Tue, 10 Aug 2004 16:02:22 -0700 Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id i7AN25F3003536 for ; Tue, 10 Aug 2004 16:02:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v670) In-Reply-To: <1092177534.30930.ezmlm@sources.redhat.com> References: <1092177534.30930.ezmlm@sources.redhat.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4F8671D3-EB21-11D8-A697-000A958F4C44@apple.com> Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: GDB/XMI (XML Machine Interface) Date: Tue, 10 Aug 2004 23:02:00 -0000 To: gdb@sources.redhat.com X-SW-Source: 2004-08/txt/msg00156.txt.bz2 This seems like a worthy effort, since there are XML parsers out there for folks to use. I have just a couple of comments about this. 1) You can run gdb and use the tty command to send inferior output to a separate pty. That's what we do with Xcode, and it works fine. This should work fine on all Unix systems, and under Cygwin. We should use this solution to separate the output, and fix anywhere it doesn't work. That seems much simpler than the whole escape code thing... 2) The XML output should just be another ui_out. If there is any reason that the ui_out architecture doesn't support outputting XML, it should be enhanced to do that. We definitely DON'T need another output gathering architecture (having now both ui_out and annotate...). I think it should work pretty straightforwardly. This will allow gdb to continue supporting the MI for any clients that use it while you are developing the XML version. It should also mean that you can just plug in the XML version of the ui_out into the existing MI commands, so you could share the command implementations with the regular MI. 3) From our usage, the most annoying part of the MI is that the input command syntax is not well specified, and is still too much like a human interface (-break-insert should take -file & -line or -address, not rely solely on decode_line_1, there are still magic cookies all over the place, etc.) The input is also where you need to be most careful about change in the commands. Right now, if you add elements to the output, it is pretty easy to just ignore them. But if you change the input, the UI usually does have to change to support them. If more of the commands had a -flag value or similar structure, and were not order dependent, then you could ignore new options till you needed them, and it would be easier to write a robust driver. So if you are really concerned about making a robust machine interface, I think you have to address the input side of things. OTOH, as a developer of MI commands, you DO end up typing them into the MI a lot as you are working on gdb. So I would not favor using XML input. XML is very verbose, and having to type XML at gdb all the time would really drive me mad! It is also overkill. Some kind of flag value syntax would work just fine. Jim On Aug 10, 2004, at 3:38 PM, gdb-digest-help@sources.redhat.com wrote: > > > Hi, > > As most of you know, I have been writing a front end to GDB called > CGDB. > However, for a while now, I have been a little disappointed with the MI > interface. In my RFC I have described the problems I have with MI and I > have proposed a new method of communication between GDB and the front > end. > > If there is good feedback on this RFC, I will continue research on it, > filling in details that I thought would be best to wait until after an > initial acceptance. > > If the RFC is accepted by the community I plan on implementing an > initial version of the XMI interface in GDB, and programming CGDB to > sit on top of GDB. This will at least give the community one open > source front end to GDB and an example to prove that the new > machine interface works. > > I can't wait to hear your opinions/comments. > > Thanks, > Bob Rossi