From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11066 invoked by alias); 27 Jan 2006 08:15:43 -0000 Received: (qmail 11054 invoked by uid 22791); 27 Jan 2006 08:15:40 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jan 2006 08:15:38 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1F2Olb-00024x-0q for gdb@sources.redhat.com; Fri, 27 Jan 2006 11:15:35 +0300 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1F2OlT-000224-5I; Fri, 27 Jan 2006 11:15:27 +0300 From: Vladimir Prus To: Eli Zaretskii Subject: Re: MI -break-info command issues Date: Fri, 27 Jan 2006 12:16:00 -0000 User-Agent: KMail/1.7.2 References: In-Reply-To: Cc: gdb@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601271115.22939.ghost@cs.msu.su> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00292.txt.bz2 On Thursday 26 January 2006 23:43, Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Thu, 26 Jan 2006 10:01:43 +0300 > > > > Eli Zaretskii wrote: > > >> The extra information doesn't pertain to breakpoint itself, it's gdb > > >> opinion on formatting and is hardly usefull for machine interface. > > >> IMO, of course. > > > > > > This output is produced by the UI-independent output functions. So > > > judging its usefulness from the point of view of a GUI is taking a too > > > narrow view. The advantage of ui_out routines is that .... > > > > I'm actually talking about MI *protocol*. > > What ``protocol''? Let's replace "protocol" with "formal interface". I was told here that all frontends should use MI, because unlike console output, it's a formal interface. And I'd expect that "formal" means "designed in detail for specific task". That's why I don't understand the reasoning that MI response contains certain field just because some internal code works that way. That's backward -- if MI is to be formal interface, then MI spec should drive the code, not the other way around. > > I think that usefulness of that > > should be judged from the point of view of its intended clients -- that > > are frontends, which nowdays means GUI. If MI is protocol specifically > > designed for some task, then it should not include some fields just > > because TUI needs those fields. > > You may, of course, unilaterally decide that GDB/MI was (or should be) > meant for GUIs only, but that's not what it actually is about, as far > as GDB development is concerned. Can you name frontend that uses MI and that is not GUI, just as example. > > > whoever writes > > > the code defines the layout once, and then each UI gleans whatever it > > > needs from the results. The programmer who wrote the code does not > > > need to bother which UI needs what information. Yes, that means some > > > of the info will be redundant or useless for certain types of UI, but > > > that's by design, and I think the advantages of a single interface far > > > outweigh the small annoyances of having to read and discard unused > > > parts of the output. > > > > Why can't MI layer weed out unnecessary information? > > And we are back to the beginning of this discussion, sigh... Ok, let's consider another command which does not share any implementation with console output: -data-read-memory, implemented entirely in mi-main.c. The output from that command is: (gdb)5-data-read-memory shorts+64 d 2 1 1 5^done,addr="0x00001510",nr-bytes="2",total-bytes="2", next-row="0x00001512",prev-row="0x0000150e", next-page="0x00001512",prev-page="0x0000150e",memory=[ {addr="0x00001510",data=["128"]}] (gdb) It includes fields like "next-page", which IMO, are not sufficiently documented. At the same time, the code to compute that field is this: ui_out_field_core_addr (uiout, "next-page", addr + total_bytes); What is the point for machine interface to have a field that is not documented and that can be trivially computed by the frontend if needed? If you had the luxury to design MI from the start, would you include this field? - Volodya