From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id tPE2DDyKIWBQRwAAWB0awg (envelope-from ) for ; Mon, 08 Feb 2021 14:00:12 -0500 Received: by simark.ca (Postfix, from userid 112) id 20F4C1EF4F; Mon, 8 Feb 2021 14:00:12 -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 C044E1E54D for ; Mon, 8 Feb 2021 14:00:07 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3B697384801D; Mon, 8 Feb 2021 19:00:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3B697384801D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1612810807; bh=ts74d/tj2qYlEfeuOUpp9ogD34lc4RrM1hRhCE0TsUc=; 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=HaHzLHnwZhWv4rjlF5n8paNLs1ycZjIJ12Tz9V9/Rhv12YLYgGQHdqfqnaRrpsl/m ecC4EVWI56Yq8VbAV5toklRSLwIC2rnYOJ3/PLkOVuWUD2T35rHegXtwUSYglzPhHN 5uwEEvl8pTbgZwza2/67Uv6CfrP62ahK29VXbbek= Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by sourceware.org (Postfix) with ESMTPS id 64E9E385800E for ; Mon, 8 Feb 2021 19:00:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 64E9E385800E Received: by mail-qk1-x733.google.com with SMTP id d85so15532116qkg.5 for ; Mon, 08 Feb 2021 11:00:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ts74d/tj2qYlEfeuOUpp9ogD34lc4RrM1hRhCE0TsUc=; b=PhDGGYkQh7s1WQJTixBK4AYX32D9YBRTJc4a/aKgM7EoEDLvEpiqrP2KzYrWja/LMB 00rV9fKQ7ETTlGpTHsJI8T81ftgJy0aXtjIPP2OqFB7HtNE/En6JuA1f/h6qDElyl2px d9F9U+7FejdATOF43gTr6YYKXUe5I0ojbX0Fkk4448VA+IBAFlQTfCJ/HwQs0MrPxNF3 rv66OyLeKkEZScH47jw9zrLBqui6dyGps20s3n8NT889hvNobGUMZTNx3APTXDgX0hD/ qnCXFBn46dn8VSlo8u5blfKEiTs9dLmbW8tolF6TTAxOhQwXSFOHmO2EnjtrnzWgfh9s cn7g== X-Gm-Message-State: AOAM532Y8pro2u1b8T6X1eABGpyqVn3ugOiMi06E07e7/qbSCG5SQYYf 1g3zQZAQ9MbXXLJhDqu1utaWp1aKL8sM/A== X-Google-Smtp-Source: ABdhPJw1rXcPWv8G8lLMd4pYf8IYdCldDjlvrKh5E0rQjRYfIRRru2/qIC91BUg5CSWXHXDwHLPmZg== X-Received: by 2002:a37:9ec5:: with SMTP id h188mr1601379qke.474.1612810802896; Mon, 08 Feb 2021 11:00:02 -0800 (PST) Received: from ?IPv6:2804:7f0:8080:8c83:1018:b18e:9d50:bc53? ([2804:7f0:8080:8c83:1018:b18e:9d50:bc53]) by smtp.gmail.com with ESMTPSA id r17sm15009553qta.78.2021.02.08.11.00.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Feb 2021 11:00:02 -0800 (PST) Subject: Re: [PATCH v5 20/25] New memory-tag commands To: Simon Marchi , gdb-patches@sourceware.org References: <20210127202112.2485702-1-luis.machado@linaro.org> <20210127202112.2485702-21-luis.machado@linaro.org> Message-ID: <7de4f1b8-d210-67f3-f76a-ec953ee1fe6f@linaro.org> Date: Mon, 8 Feb 2021 15:59:58 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Luis Machado via Gdb-patches Reply-To: Luis Machado Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2/5/21 1:49 AM, Simon Marchi wrote: >> +/* 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? > It could. But it is unlikely, given architectures use spare bits of the virtual address. We could solve this by having another gdbarch constant that tells us the size of a tag in a particular architecture. Then we check for size * 2 characters. Or check for more than a couple characters, and let the architecture device if the tag value is sane or not. What do you think? >> 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: I don't have a preference, but the 'x' command, for example, does the opposite. I used it as reference. -- c = add_com ("x", class_vars, x_command, _("\ Examine memory: x/FMT ADDRESS.\n\ ADDRESS is an expression for the memory address to examine.\n\ FMT is a repeat count followed by a format letter and a size letter.\n\ Format letters are o(octal), x(hex), d(decimal), u(unsigned decimal),\n\ t(binary), f(float), a(address), i(instruction), c(char), s(string)\n\ and z(hex, zero padded on the left).\n\ Size letters are b(byte), h(halfword), w(word), g(giant, 8 bytes).\n\ The specified number of objects of the specified size are printed\n\ according to the format. If a negative number is specified, memory is\n\ examined backward from the address.\n\n\ Defaults for format and size letters are those previously used.\n\ Default count is 1. Default address is following last thing printed\n\ with this command or \"print\".")); -- Besides... > > Print the logical tag associated with a pointer. POINTER is an > expression that evaluates to a pointer. ...this is almost exactly the first line of the command documentation. Looking at 'x', it feels to me that the second portion of the documentation describes what GDB will acomplish in a more verbose manner, since the command's output is already described in the first line. Is there a standard for these command documentation bits somewhere? > > Also, use capital letters to refer to arguments, in the help and in the > error messages too. See this series for reference: I'll get these fixed. > > 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 It wasn't, and I appreciate you putting the time to go through these patches and making these observations. Thanks a lot. > 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. That's the correct understanding. Though in GDB, sometimes things get a bit fuzzy, and I may have exposed some of GDB's inner interpretation here. For example, when you pass in a constant to a command. Is that a pointer or an address? Maybe an address that gets converted to a typed pointer? For simplicity, I think we can go for pointers when talking about memory tags and memory when talking about 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? I'll revise the documentation and address this. My goal is to have something short and meaningful.