From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SS/MA1bOHGA/FQAAWB0awg (envelope-from ) for ; Thu, 04 Feb 2021 23:49:26 -0500 Received: by simark.ca (Postfix, from userid 112) id F124A1EFCB; Thu, 4 Feb 2021 23:49:25 -0500 (EST) 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 1EFA21E945 for ; Thu, 4 Feb 2021 23:49:25 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 73BAF3857810; Fri, 5 Feb 2021 04:49:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 73BAF3857810 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1612500564; bh=4aoptnJglbBDYUG52I6qmSFr88I4Qe7FHAxQVPSO2Ww=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=T+b4TKEyiqGaWdig0nXX+iyW5ChCVUXWK49q96sadw97HUmrgaUAxXuKIOtzEb9eV /FqpBY2GAtYp1NezlT0Qk+ZAR/Xw9p5vfOTwTTCURwHpqcJ6gfeUCyzPD+t1/CNxd0 SpmIO7lxcZE84lsDiLqSouEQ6BG8loJLzK6Bco04= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 55FEC3857810 for ; Fri, 5 Feb 2021 04:49:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 55FEC3857810 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 1154nFRV013761 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 4 Feb 2021 23:49:20 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 1154nFRV013761 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 3B7521E945; Thu, 4 Feb 2021 23:49:15 -0500 (EST) Subject: Re: [PATCH v5 20/25] New memory-tag commands To: Luis Machado , gdb-patches@sourceware.org References: <20210127202112.2485702-1-luis.machado@linaro.org> <20210127202112.2485702-21-luis.machado@linaro.org> Message-ID: Date: Thu, 4 Feb 2021 23:49:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <20210127202112.2485702-21-luis.machado@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 5 Feb 2021 04:49:15 +0000 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: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" > +/* Parse ARGS and extract ADDR and TAG. > + ARGS should have format . */ > + > +static void > +parse_with_logical_tag_input (const char *args, struct value **val, > + gdb::byte_vector &tags, > + value_print_options *print_opts) > +{ > + /* Fetch the address. */ > + std::string address_string = extract_string_maybe_quoted (&args); > + > + /* Parse the address into a value. */ > + *val = process_print_command_args (address_string.c_str (), print_opts, > + true); > + > + /* Fetch the tag bytes. */ > + std::string tag_string = extract_string_maybe_quoted (&args); > + > + /* Validate the input. */ > + if (address_string.empty () || tag_string.empty ()) > + error (_("Missing arguments.")); > + > + if (tag_string.length () != 2) > + error (_("Error parsing tags argument. The tag should be 2 digits.")); Can't an hypothetical architecture use more than one byte for a tag? > void _initialize_printcmd (); > void > _initialize_printcmd () > @@ -2982,4 +3263,63 @@ Construct a GDB command and then evaluate it.\n\ > Usage: eval \"format string\", ARG1, ARG2, ARG3, ..., ARGN\n\ > Convert the arguments to a string as \"printf\" would, but then\n\ > treat this string as a command line, and evaluate it.")); > + > + /* Memory tagging commands. */ > + add_prefix_cmd ("memory-tag", class_vars, memory_tag_command, _("\ > +Generic command for printing and manipulating memory tag properties."), > + &memory_tag_list, "memory-tag ", 0, &cmdlist); > + add_cmd ("print-logical-tag", class_vars, > + memory_tag_print_logical_tag_command, > + ("Print the logical tag for an address.\n\ > +Usage: memory-tag print-logical-tag
.\n\ > +
is an expression that evaluates to a pointer or memory address.\n\ > +GDB will print the logical tag associated with
. The tag\n\ Instead of saying "GDB will print the...", use the infinite "Print the ...". I would also swap the two sentences to say what the command says first, before describing the argument. Something like: Print the logical tag associated with a pointer. POINTER is an expression that evaluates to a pointer. Also, use capital letters to refer to arguments, in the help and in the error messages too. See this series for reference: https://sourceware.org/pipermail/gdb-patches/2018-September/152361.html > +interpretation is architecture-specific."), > + &memory_tag_list); > + add_cmd ("print-allocation-tag", class_vars, > + memory_tag_print_allocation_tag_command, > + _("Print the allocation tag for an address.\n\ > +Usage: memory-tag print-allocation-tag
.\n\ > +
is an expression that evaluates to a pointer or memory address.\n\ > +GDB will print the allocation tag associated with
. The tag\n\ > +interpretation is architecture-specific."), > + &memory_tag_list); > + add_cmd ("with-logical-tag", class_vars, memory_tag_with_logical_tag_command, > + _("Set the logical tag for an address.\n\ > +Usage: memory-tag with-logical-tag
\n\ > +
is an expression that evaluates to a pointer or memory address.\n\ > + is a sequence of hex bytes that will be interpreted by the\n\ > +architecture as a single memory tag.\n\ > +GDB will set the logical tag for
to , and will print the\n\ > +resulting address with the updated tag."), > + &memory_tag_list); > + add_cmd ("set-allocation-tag", class_vars, > + memory_tag_set_allocation_tag_command, > + _("Set the allocation tag for an address.\n\ > +Usage: memory-tag set-allocation-tag
\n\ > +
is an expression that evaluates to a pointer or memory address\n\ > + is the number of bytes that will get added to
to calculate\n\ > +the memory range.\n\ > + is a sequence of hex bytes that will be interpreted by the\n\ > +architecture as one or more memory tags.\n\ > +Sets the tags of the memory range [
,
+ )\n\ > +to the specified tag bytes.\n\ > +\n\ > +If the number of tags is greater than or equal to the number of tag granules\n\ > +in the [
,
+ +number of tag granules will be stored.\n\ > +\n\ > +If the number of tags is less than the number of tag granules, then the\n\ > +command is a fill operation. The tag bytes are interpreted as a pattern\n\ > +that will get repeated until the number of tag granules in the memory range\n\ > +[
,
+ ] is stored to."), > + &memory_tag_list); > + add_cmd ("check", class_vars, memory_tag_check_command, > + _("Validate the logical tag against the allocation tag.\n\ > +Usage: memory-tag check
\n\ > +
is an expression that evaluates to a pointer or memory address\n\ > +GDB will fetch the logical and allocation tags for
and will\n\ > +compare them for equality. If the tags do not match, GDB will show\n\ > +additional information about the mismatch."), > + &memory_tag_list); > } I don't know if this has been discussed before, but something confuses me about saying "evaluates to a pointer or memory address". The way I understand it is that logical tags are encoded into pointers, whereas allocation tags are associated to memory addresses. So I think it would make more sense to use "pointer" for things related to logical tags and "address" for things related to allocation tags. With "memory-tag check", you would pass a pointer, and it verifies whether the pointer's logical tag matches the pointed to memory address' allocation tag, so that one involves both. Otherwise, if the distinction is not so important or just confusing, maybe just use "address" and drop "pointer", to make the text lighter? Simon