From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 875733B79031 for ; Fri, 17 Jul 2020 14:30:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 875733B79031 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eliz@gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]:54404) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jwRNK-0001lH-7m; Fri, 17 Jul 2020 10:30:10 -0400 Received: from [176.228.60.248] (port=4024 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jwRND-0003Pd-TY; Fri, 17 Jul 2020 10:30:04 -0400 Date: Fri, 17 Jul 2020 17:29:50 +0300 Message-Id: <83v9imi59d.fsf@gnu.org> From: Eli Zaretskii To: Luis Machado Cc: gdb-patches@sourceware.org, Alan.Hayward@arm.com, catalin.marinas@arm.com, david.spickett@linaro.org In-Reply-To: (message from Luis Machado on Fri, 17 Jul 2020 11:20:17 -0300) Subject: Re: [PATCH 19/23] Documentation for the new mtag commands References: <20200715194513.16641-1-luis.machado@linaro.org> <20200715194513.16641-20-luis.machado@linaro.org> <83imemk6x6.fsf@gnu.org> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, 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 14:30:12 -0000 > 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 ;-) > >> +If the underlying architecture supports memory tagging, like AArch64, > > ^^^^^^^^^^^^ > > "like AArch64 does" > > > > How about "... like AArch64 MTE or SPARC ADI..."? Fine with me. > >> +@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. > "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.