From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf43.google.com (mail-qv1-xf43.google.com [IPv6:2607:f8b0:4864:20::f43]) by sourceware.org (Postfix) with ESMTPS id C8EE63858036 for ; Fri, 23 Oct 2020 14:39:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C8EE63858036 Received: by mail-qv1-xf43.google.com with SMTP id ev17so785657qvb.3 for ; Fri, 23 Oct 2020 07:39:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1gssbUfaeaNuNIi5sIL/MT6EEs2hGPAfT7ytSG+dJn4=; b=N5Omuh70oWQz5k519sNtdwY87ZslAn5KmLegtE4lU8jSTEM6JJsbl/vtOb+1OQqNZk P4NQn5LqS6uhXt6AH1/Y+6XGBkur+lwd4fIthxytoY5EauV4ooz34x7MwAAMG04LQYx9 gT8bjLfjhyaIlI7Sd/aKEzcg7WfSfAmiBAlyhIkWonVAUGXXZHzlyY7vnExbGWuAM/4b rZ9AsPhBqjihIRj8YZ5+6qZalaOGuXni/hjkDJ14OCyhEJCmEKC4PIIke/SVH9XH92MP cLc+qIep2uiSu5GcrhYDcLreeHqDHxIqadjYGWz3Ej38xfwFHS4CTRv6Nml6JNAohY1t suQQ== X-Gm-Message-State: AOAM532wEuz9iaHM/82jxkuXGAst9ngc+HEfo5CWnqTV8OeYaXTe78/P D+Rn+eHUz7f/93rWG1wo5Czhmg== X-Google-Smtp-Source: ABdhPJzQvlUsuzcGkUUUKewkxtA3QrNat1Jt2dWw8dSlsrbSgw11O07HEOYploghyiZ91mEfuSToVw== X-Received: by 2002:a0c:9e65:: with SMTP id z37mr2742334qve.39.1603463966356; Fri, 23 Oct 2020 07:39:26 -0700 (PDT) Received: from ?IPv6:2804:7f0:8284:1487:4913:3c4b:c60f:1010? ([2804:7f0:8284:1487:4913:3c4b:c60f:1010]) by smtp.gmail.com with ESMTPSA id v14sm941172qta.44.2020.10.23.07.39.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Oct 2020 07:39:25 -0700 (PDT) Subject: Re: [PATCH v2 07/24] Documentation for memory tagging remote packets To: Eli Zaretskii Cc: gdb-patches@sourceware.org, david.spickett@linaro.org 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> <831rhpj9l4.fsf@gnu.org> From: Luis Machado Message-ID: Date: Fri, 23 Oct 2020 11:39:22 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <831rhpj9l4.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.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: , X-List-Received-Date: Fri, 23 Oct 2020 14:39:28 -0000 On 10/23/20 11:33 AM, Eli Zaretskii wrote: >> 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: > Indeed. >> +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? > That works fine for me. Thanks! >> 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. > Great. I'll include the changes in v3.