From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) by sourceware.org (Postfix) with ESMTPS id 8268539960F7 for ; Fri, 17 Jul 2020 15:08:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8268539960F7 Received: by mail-qt1-x843.google.com with SMTP id d27so7852123qtg.4 for ; Fri, 17 Jul 2020 08:08:32 -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=szMV7lkfYNI4TyyCavvBEKPQZ+n6S6pf5Ds/3rumaLM=; b=tb4IhL9UMNgp2fdst+6OlDjlDQFItiqOFsbpG1rMhK/CR3pmjXnJ0AmZA4fptC+Ei/ D5xbjOLGH0bHlg3M7D/G9zQvYPO9YPN1FNRZTTH0jCM+PboD+sjzhCi/1NQ4uon6T7wa g/m6FkV8Dfaqa0OpBtE6uY26zcwNkAKscL0m5e8/WUQEksdRE7/6fkAj4FB+H2sLwC2i Kmw1nBWwfhhXOYS/kyQgn/vqJg7AWqIhS3T0NkAYyZnBuEIJ3EXEmVnf/W1IGSVOPvBr U1jJ5lYgo5irXLUG9ghO+WYL7vxlfwvNUXTwkTssDIummJpeZWs4Wnrr81iXRCvK2Roc dt7Q== X-Gm-Message-State: AOAM531+12K2cRSLZTmsqr+YTPYQqBKnnL7K8hWuiBuuJgFQA3IByPAs jzdgFdZvp09H+RffJwyPq5ieLQ== X-Google-Smtp-Source: ABdhPJwqkkF2wtZ9U5MpDYBOFwHzqRhuAvJg1IH4f1bJTXWJMmS1qW90GSDyOjCqjuWMQMLkntiIiQ== X-Received: by 2002:aed:37a6:: with SMTP id j35mr10783441qtb.322.1594998511914; Fri, 17 Jul 2020 08:08:31 -0700 (PDT) Received: from ?IPv6:2804:7f0:8283:82c3:30f9:c348:a8bc:88d6? ([2804:7f0:8283:82c3:30f9:c348:a8bc:88d6]) by smtp.gmail.com with ESMTPSA id q13sm10522820qtp.42.2020.07.17.08.08.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jul 2020 08:08:31 -0700 (PDT) Subject: Re: [PATCH 19/23] Documentation for the new mtag commands To: Eli Zaretskii Cc: gdb-patches@sourceware.org, Alan.Hayward@arm.com, catalin.marinas@arm.com, david.spickett@linaro.org References: <20200715194513.16641-1-luis.machado@linaro.org> <20200715194513.16641-20-luis.machado@linaro.org> <83imemk6x6.fsf@gnu.org> <83v9imi59d.fsf@gnu.org> From: Luis Machado Message-ID: Date: Fri, 17 Jul 2020 12:08:28 -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: <83v9imi59d.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.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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, 17 Jul 2020 15:08:34 -0000 On 7/17/20 11:29 AM, Eli Zaretskii wrote: >> From: Luis Machado >> Cc: gdb-patches@sourceware.org, Alan.Hayward@arm.com, >> catalin.marinas@arm.com, david.spickett@linaro.org >> Date: Fri, 17 Jul 2020 11:20:17 -0300 >> >> The pointer tag must match the memory tag. The physical address space >> reference was to make it clear that the allocation tag was associated >> with the memory itself. >> >> I've rephrased this as the following now... >> >> "The pointer tag and the memory tag must match for the memory access to >> be validated." >> >> How does it look? > > It's okay, but I like this even better: > > The pointer tag must match the memory tag for the memory access to > be validated. > > (I stole the beginning from your explanation above ;-) > Fair enough. That does read better. Thanks. >>>> +If the underlying architecture supports memory tagging, like AArch64, >>> ^^^^^^^^^^^^ >>> "like AArch64 does" >>> >> >> How about "... like AArch64 MTE or SPARC ADI..."? > > Fine with me. > I realized I missed the point of the comment. I've made it... "... like AArch64 MTE or SPARC ADI do ..." >>>> +@item mtag setltag @var{address_expression} @var{tag_bytes} >>>> +Print the resulting pointer from evaluating the argument expression with a >>>> +logical tag of @var{tag_bytes}. >>> >>> I don't understand what "print the resulting point" means in this >>> context, and the sentence confused me, perhaps for this very reason. >>> can you elaborate what this means? >>> >> >> The goal of the command is to modify a particular address/pointer to >> include the specified logical tag. >> >> It will, therefore, print a modified version of the address given by >> @var{address_expression}, but containing the specified tag. >> >> So it doesn't "set" anything at the moment, it just prints what the >> pointer would look like with the user-passed tag. This may change based >> on reviews. >> >> How about the following? >> >> "Print the address given by @var{address_expression}, augmented with a >> logical tag of @var{tag_bytes}." > > That's okay, but since it is unusual for a "set" command to not set > anything, I think we should add to the manual some of the explanations > you gave above. > Right. I'll hold until we have some more consensus about that particular command. Then I'll update the documentation accordingly. >> "Check that the logical tag stored at the address given by >> @var{address_expression} matches the allocation tag for the same address." > > SGTM, thanks. > >>>> +When @value{GDBN} is debugging the AArch64 architecture, the program is >>>> +using the v8.5-A feature Memory Tagging Extension (MTE) and there is support >>>> +in the kernel for MTE, @value{GDBN} will make memory tagging functionality >>>> +available for inspection and editing of logical and allocation tags. >>> >>> Please add here a cross-reference to "Memory Tagging" subsection. >>> >> >> Like this? >> >> @cindex Memory Tagging > > No, @cindex produces an index entry. I meant @xref or @pxref. > > Thanks. > Ah! I've never used that. That's good to know. I've added those cross-references locally now. They'll be in v2. Thanks!