From: Eli Zaretskii <eliz@gnu.org>
To: Simon Marchi <simon.marchi@ericsson.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 3/7] Clarify doc about memory read/write and non-8-bits bytes
Date: Thu, 09 Apr 2015 07:02:00 -0000 [thread overview]
Message-ID: <83lhi1g4y2.fsf@gnu.org> (raw)
In-Reply-To: <1428522979-28709-4-git-send-email-simon.marchi@ericsson.com>
> From: Simon Marchi <simon.marchi@ericsson.com>
> CC: Simon Marchi <simon.marchi@ericsson.com>
> Date: Wed, 8 Apr 2015 15:56:15 -0400
>
> This patch modifies the manual to clarify the MI, RSP and Python APIs in
> regard to reading/writing memory on architectures with non-8-bits bytes.
>
> Care is taken to use the word byte when referring to one piece of the
> smallest addressable size on the current architecture and the word octet
> when referring to an 8-bits data piece. I try to avoid "word", because
> it can be ambiguous.
Thanks. However, I think we need to be more explicit about this
issue. Just using "target memory bytes" without ever explaining what
that means, or how it is different from the host bytes, makes these
changes more accurate, but not more clear to the reader.
So please add some short discussion of this issue (the node "Data"
sounds pertinent, or maybe "Memory"), and introduce there the "target
memory byte" term.
> +Optional argument indicating the number of target bytes to be written.
^^^^^^^^^^^^
Let's be consistent and use "target memory bytes" everywhere.
> -Read @var{length} bytes of memory starting at address @var{addr}.
> +Read @var{length} octets of memory starting at address @var{addr}.
"Octet" is not defined anywhere, so I think it should be part of the
above-mentioned introduction. Here, I would add a cross-reference to
that place.
> -Read @var{length} bytes of memory from the inferior, starting at
> +Read @var{length} target bytes of memory from the inferior, starting at
^^^^^^^^^^^^^^^^^^^^^^
"target memory bytes"
Thanks.
next prev parent reply other threads:[~2015-04-09 7:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-08 19:56 [PATCH 0/7] Support reading/writing memory on architectures with non 8-bits bytes Simon Marchi
2015-04-08 19:56 ` [PATCH 1/7] Various cleanups in target read/write code Simon Marchi
2015-04-08 19:56 ` [PATCH 5/7] target: consider byte size when reading/writing memory Simon Marchi
2015-04-08 19:56 ` [PATCH 3/7] Clarify doc about memory read/write and non-8-bits bytes Simon Marchi
2015-04-09 7:02 ` Eli Zaretskii [this message]
2015-04-08 19:56 ` [PATCH 7/7] MI: Consider byte size when reading/writing memory Simon Marchi
2015-04-08 19:56 ` [PATCH 4/7] gdbarch: add memory_byte_size method Simon Marchi
2015-04-08 19:56 ` [PATCH 2/7] Cleanup some docs about memory write Simon Marchi
2015-04-08 19:56 ` [PATCH 6/7] remote: Consider byte size when reading/writing memory Simon Marchi
2015-04-09 8:20 ` [PATCH 0/7] Support reading/writing memory on architectures with non 8-bits bytes Eli Zaretskii
2015-04-09 15:39 ` Simon Marchi
2015-04-09 16:29 ` Eli Zaretskii
2015-04-09 21:00 ` Simon Marchi
2015-04-10 8:11 ` Eli Zaretskii
2015-04-10 16:01 ` Simon Marchi
2015-04-10 16:35 ` Pedro Alves
2015-04-10 16:39 ` Paul_Koning
2015-04-10 17:34 ` Simon Marchi
2015-04-10 17:42 ` Eli Zaretskii
2015-04-10 18:01 ` Simon Marchi
2015-04-10 18:16 ` 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=83lhi1g4y2.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@ericsson.com \
/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