Re: MI -break-info command issues

[Eli Zaretskii <eliz at gnu dot org>]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Fri, 27 Jan 2006 17:59:56 +0300
> 
> >     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.

Thanks, but this is too wordy.  I will try to come up with some
suitable definition of `page'.  (I don;t think that `previous' needs a
definition; perhaps you meant that `previous page' needs it.)

> 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?

All good points, IMHO.  Patches are welcome to fix them.

> 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.

It's not prohibited.  And if superfluous fields are a big annoyance,
how about an MI command that would remove them?  Would you like to
submit a patch along these lines?