From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21596 invoked by alias); 27 Jan 2006 12:16:09 -0000 Received: (qmail 21588 invoked by uid 22791); 27 Jan 2006 12:16:08 -0000 X-Spam-Check-By: sourceware.org Received: from gandalf.inter.net.il (HELO gandalf.inter.net.il) (192.114.186.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jan 2006 12:16:06 +0000 Received: from nitzan.inter.net.il (nitzan.inter.net.il [192.114.186.20]) by gandalf.inter.net.il (MOS 3.7.1-GA) with ESMTP id HRU13174; Fri, 27 Jan 2006 14:15:37 +0200 (IST) Received: from HOME-C4E4A596F7 (IGLD-80-230-206-144.inter.net.il [80.230.206.144]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id COU61801 (AUTH halo1); Fri, 27 Jan 2006 14:15:35 +0200 (IST) Date: Fri, 27 Jan 2006 14:55:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus CC: gdb@sources.redhat.com In-reply-to: <200601271115.22939.ghost@cs.msu.su> (message from Vladimir Prus on Fri, 27 Jan 2006 11:15:22 +0300) Subject: Re: MI -break-info command issues Reply-to: Eli Zaretskii References: <200601271115.22939.ghost@cs.msu.su> X-IsSubscribed: yes 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/msg00293.txt.bz2 > From: Vladimir Prus > Date: Fri, 27 Jan 2006 11:15:22 +0300 > Cc: gdb@sources.redhat.com > > 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. I'm not sure that's the main reason. AFAIK, the main reason is that MI was _designed_ to be easily understandable by programs (thus the `M' in "MI"), in contrast to annotations, which are after-thought ad-hoc additions to the CLI interface, which was originally designed for interaction with _humans_. > And I'd expect that "formal" means "designed in detail for specific > task". That's the theory, yes. > 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 didn't say that MI includes something just because the code ``works that way''. It includes those specific fields because some UI might need them. > Can you name frontend that uses MI and that is not GUI, just as example. Why should I bother? MI is a general-purpose interface, it's not limited to GUI. That's its design goal. Even if there's no UI at this time that uses MI, it doesn't necessarily mean we should forever ban such UIs from coming into existence, just because there are a few fields a GUI normally won't want. But if you insist, here's one example: Emacs's gdb-ui when Emacs runs on a text-mode display (e.g., when one logs into a remote machine through a telnet client). Yes, Emacs currently doesn't use MI, but AFAIR that's Nick's long-term goal, and there's even a development version of the interface that uses MI. But again, I don't think examples are important to this discussion. If you are willing to lobby us to drop text-mode front-end support in GDB/MI, then it's okay to discuss that, but I personally would then ask to come up with arguments against such support that are much more grave than just a few gratuitous fields. Dropping an existing feature, in general, needs a very good reason, because of the risk that we hurt some potential users somewhere. All unused fields do is make the interface more voluminous. Someone actually suggested to replace MI with XML a few months ago, so evidently at least that person didn't think the current interface is too wordy. > > > 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. I'm not sure where you are taking this discussion; can you please spell that out? Are you saying that MI's design is faulty? or perhaps that implementation of certain commands Needs Work(tm)? or that the documentation is not clear or detailed enough? or something else entirely? > 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. I see in the manual that next-page is documented thusly: The address of the next/previous row or page is available in `next-row' and `prev-row', `next-page' and `prev-page'. Now, if you are saying that this is unclear, I will happily try to make it better. How about this replacement text: The first memory address to be displayed on the next/previous row or page is given as the values of the fields `next-row' and `prev-row', `next-page' and `prev-page', respectively. > 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 But it _is_ documented. > and that can be trivially computed by the frontend if needed? This is trivial only when you look at how the values are computed. One reason why it might be useful for GDB/MI to return these values is that a UI programmer shouldn't have to look into the GDB sources to understand how to display the data. But that's a guess; I'm not one of the designers of MI. Perhaps someone else could give a more definitive answer to your question. > If you had the luxury to design MI from the start, would you include > this field? I don't know, and I don't have that luxury anyway.