From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WHGjGsvpkl8NYwAAWB0awg (envelope-from ) for ; Fri, 23 Oct 2020 10:33:47 -0400 Received: by simark.ca (Postfix, from userid 112) id 697BA1EE09; Fri, 23 Oct 2020 10:33:47 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 1DA321E58D for ; Fri, 23 Oct 2020 10:33:46 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C9584398B166; Fri, 23 Oct 2020 14:33:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C9584398B166 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1603463625; bh=zlhFB9P+wKXYAmlONenzlK98vx9Kcn9i+p4yzK9jvI4=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=pbWPyhdi+flxpb7Mg+/tKVxemrt39IYGoG++THtfSdk7oYglWQUJpH2+lKXEQPJjo nS2rUg3ndq9Ko1As4HKNbIcM+nBZvfF39CwAM04ditGpR1h2dzsn+EQ0gXZ+CgV1N8 A4LhNsAnTqzZ8lUb+6AN9yoTl3HE9sMVemmewDBE= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 3AD4D3987C1A for ; Fri, 23 Oct 2020 14:33:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3AD4D3987C1A Received: from fencepost.gnu.org ([2001:470:142:3::e]:50669) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kVy8U-00024l-NQ; Fri, 23 Oct 2020 10:33:42 -0400 Received: from [176.228.60.248] (port=4410 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kVy8U-0003ko-5o; Fri, 23 Oct 2020 10:33:42 -0400 Date: Fri, 23 Oct 2020 17:33:27 +0300 Message-Id: <831rhpj9l4.fsf@gnu.org> To: Luis Machado In-Reply-To: <42ae2b44-67de-3860-2e3a-941392cac68a@linaro.org> (message from Luis Machado on Fri, 23 Oct 2020 11:07:48 -0300) Subject: Re: [PATCH v2 07/24] Documentation for memory tagging remote packets References: <20201022200014.5189-1-luis.machado@linaro.org> <20201022200014.5189-8-luis.machado@linaro.org> <838sbxlaqv.fsf@gnu.org> <42ae2b44-67de-3860-2e3a-941392cac68a@linaro.org> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: david.spickett@linaro.org, gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" > Cc: gdb-patches@sourceware.org, david.spickett@linaro.org > From: Luis Machado > Date: Fri, 23 Oct 2020 11:07:48 -0300 > > >> +@var{type} is the type of tag, a signed integer, the request wants to fetch. > > > > This is ambiguous: does "the request wants to fetch" refer to the tag > > or to the "signed integer" part? Suggest to move the "a signed > > integer" part to the end of the sentence. > > Yeah. It reads a bit funny. How about the following? > > @var{type} is the type of tag the request wants to fetch. The type is a > signed integer. Fine, thanks. > >> +If the number of memory tags, @var{nt}, is greater than or equal to the > >> +number of memory tag granules, @var{ng}, only @var{ng} tags will be > >> +stored. > > > > It is not clear here how NT and NG are related to the parameters of > > the packet. Can you add something that explains the relation? > > > > How about the following? > > NT is the number of memory tags contained in @var{tag bytes}. Only > target-specific code can determine this value. For example, AArch64's > tags are stored 1 per byte. > > NG is the number of memory tag granules in the memory range > @w{@r{[}@var{start address}, @var{start address} + @var{length}@r{)}}. > Only target-specific can determine this value. For example, AArch64 has > a tag granule size of 16 bytes. That is, it has one memory for every 16 > bytes of memory. This is okay, but I think you in fact had already explained that, in this text: > +The interpretation of how many tags should be written to how many memory tag > +granules is also architecture-specific. The behavior is > +implementation-specific, but the following is suggested. So I think the only change you need to do is to mention @var{nt} and @var{ng} in that text: The interpretation of how many tags (@var{nt}) should be written to how many memory tag granules (@var{ng}) is also architecture-specific. The behavior is implementation-specific, but the following is suggested. WDYT? > I did... > > "The remote stub supports and implements the required memory tagging > functionality and understands the @samp{qMemTags} (@pxref{qMemTags}) and > @samp{QMemTags} (@pxref{QMemTags}) packets." > > And I've added a couple anchors to the packets. > > Is that what you had in mind? Yes, thanks.