From: Eli Zaretskii <eliz@gnu.org>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb@sources.redhat.com
Subject: Re: MI -break-info command issues
Date: Fri, 27 Jan 2006 17:12:00 -0000 [thread overview]
Message-ID: <ud5idehd5.fsf@gnu.org> (raw)
In-Reply-To: <drdchc$672$1@sea.gmane.org> (message from Vladimir Prus on Fri, 27 Jan 2006 17:59:56 +0300)
> 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?
next prev parent reply other threads:[~2006-01-27 17:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-24 14:22 Vladimir Prus
2006-01-24 14:48 ` Bob Rossi
2006-01-24 15:02 ` Vladimir Prus
2006-01-24 21:24 ` Eli Zaretskii
2006-01-24 23:35 ` Bob Rossi
2006-01-25 16:05 ` Vladimir Prus
2006-01-25 19:42 ` Eli Zaretskii
2006-01-26 12:09 ` Vladimir Prus
2006-01-26 20:48 ` Eli Zaretskii
2006-01-27 12:16 ` Vladimir Prus
2006-01-27 14:55 ` Eli Zaretskii
2006-01-27 15:00 ` Bob Rossi
2006-01-27 15:12 ` Vladimir Prus
2006-01-27 15:48 ` Daniel Jacobowitz
2006-01-27 15:51 ` Vladimir Prus
2006-01-27 16:01 ` Daniel Jacobowitz
2006-01-27 16:11 ` Daniel Jacobowitz
2006-01-27 16:44 ` Vladimir Prus
2006-01-27 17:00 ` Bob Rossi
2006-02-10 12:03 ` Documenting MI stability (Was: MI -break-info command issues) Vladimir Prus
2006-01-27 17:41 ` MI -break-info command issues Eli Zaretskii
2006-01-27 17:16 ` Eli Zaretskii
2006-01-27 17:53 ` Bob Rossi
2006-01-28 14:48 ` Eli Zaretskii
2006-01-27 17:12 ` Eli Zaretskii [this message]
2006-03-17 17:07 ` -data-read-memory docs (Was: MI -break-info command issues) Vladimir Prus
2006-03-18 11:26 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ud5idehd5.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb@sources.redhat.com \
--cc=ghost@cs.msu.su \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).