From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9075 invoked by alias); 27 Jan 2006 15:00:30 -0000 Received: (qmail 9067 invoked by uid 22791); 27 Jan 2006 15:00:29 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jan 2006 15:00:27 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1F2V58-00013B-Hc for gdb@sources.redhat.com; Fri, 27 Jan 2006 16:00:10 +0100 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Jan 2006 16:00:10 +0100 Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Jan 2006 16:00:10 +0100 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: MI -break-info command issues Date: Fri, 27 Jan 2006 15:12:00 -0000 Message-ID: References: <200601271115.22939.ghost@cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.8.2 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/msg00295.txt.bz2 Eli Zaretskii wrote: >> 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'. Yes, and the only extra information this paragraph adds to the names of fields is that the value of those fields are addresses. Otherwise it repeats the name of fields in more verbose english. > 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. This misses the definition of 'page' and definition of 'next'/'prev'. Based on looking on the code, I could suggest this: Assuming memory is a sequence of "pages", where each "page" is "total-nr" bytes the "next-page" is the address of page directly after the page returned by -data-read-memory, and "prev-page" is the address of the first byte of the directly preceding page. Likewise, assuming memory is a sequence of rows, where each row is word_size*nr_cols bytes, "next-row" is the address of the row directly after the first one in the -data-read-memory output (that is, the address of the second row of the output, if there's second row). The "prev-row" is the start address of the row directly preceding the first output row. Another variant: The 'next-page' field gives the address of the memory immediately following the memory returned by the command. The 'prev-page' gives the memory address that's 'total-bytes' before the starting address of the memory region returned by the command. ..... >> 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. That's only valid if it's easier for UI programmer to understand how those fields are to be used, than to write the simular pointer code. The second variant of docs I suggested basically documents address manupulation gdb will do, it's not conceptually better then doing the manupulation itself. The first variant of docs introduces the concept of "page" which can be confusing it itself. >> 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? That's a good question. The general design of MI is good, and extracting information from MI replies is much easier then from console output. But there are some issues: 1. Some commands produce fields that appear to be unnecessary. The documentation does not say why they are useful. For example table heading for -break-list, prev/next for -data-read-memory. I also recall a related issue: http://sources.redhat.com/ml/gdb/2005-07/msg00164.html where again gdb outputs information that not all frontends need (and which KDevelop has to explicitly eliminate, which is not that simple). 2. The documentation is incomplete. All MI commands are documented with examples. It's not clear if all shown fields in replies will always be output, or if not, in what combinations. 3. It's not sufficiently clear what commands are implemented, and what are not. Consider -break-info that's marked with "N.A" but still implemented. 4. There's too little rationale. Why "variable-objects" are better interface? It's not stated anywhere, so how I can use them efficiently? This leaves very simple approach for porting to MI: pick a command that looks suitable, then look at the output, and pick used the parts that look suitable. It might even work. But I think a machine protocol must be minimal and documented (if minimal protocol is easier to document). If "minimal" protocol is explicitly not a goal of MI, or changing MI is prohibited, just say so and I'll stop asking why there are unnecessary fields. - Volodya