From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53816 invoked by alias); 9 Apr 2015 07:02:06 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 53807 invoked by uid 89); 9 Apr 2015 07:02:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout22.012.net.il Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Apr 2015 07:02:03 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NMJ0070025OJ900@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Thu, 09 Apr 2015 10:02:01 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMJ007KA27CIK10@a-mtaout22.012.net.il>; Thu, 09 Apr 2015 10:02:00 +0300 (IDT) Date: Thu, 09 Apr 2015 07:02:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH 3/7] Clarify doc about memory read/write and non-8-bits bytes In-reply-to: <1428522979-28709-4-git-send-email-simon.marchi@ericsson.com> To: Simon Marchi Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83lhi1g4y2.fsf@gnu.org> References: <1428522979-28709-1-git-send-email-simon.marchi@ericsson.com> <1428522979-28709-4-git-send-email-simon.marchi@ericsson.com> X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00312.txt.bz2 > From: Simon Marchi > CC: Simon Marchi > 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.