This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI -break-info command issues


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]