From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8Rg4GMNhWmC9SQAAWB0awg (envelope-from ) for ; Tue, 23 Mar 2021 17:46:43 -0400 Received: by simark.ca (Postfix, from userid 112) id 55F301EF78; Tue, 23 Mar 2021 17:46:43 -0400 (EDT) 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 307BB1E54D for ; Tue, 23 Mar 2021 17:46:42 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7F4263858002; Tue, 23 Mar 2021 21:46:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7F4263858002 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1616536001; bh=GsuAPjPvHUAEwJxORPlRlSvJgEBAO69NIwZZ/JgubKU=; 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=yVj2kklZj6T54Lk3gNDDrnkXDPOp/Ocaot7R5RnKhWU5n2UfyIU1rGCa4pZ6AA4Jy 2NKK792qRl8DeHvHRt/5Wa5fC9xf3yvKXFutg9t6ZU3JAUXUNiVoTC/57BPyF0+6cU uEf0otxTgMJAG4n3XxvuQzkwu4voW8qhQJ2rQZkY= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 5CC9B3857829 for ; Tue, 23 Mar 2021 21:46:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5CC9B3857829 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 12NLkUPU013880 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Mar 2021 17:46:34 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 12NLkUPU013880 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) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 0A9AB1E54D; Tue, 23 Mar 2021 17:46:29 -0400 (EDT) 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> <7de4f1b8-d210-67f3-f76a-ec953ee1fe6f@linaro.org> Message-ID: <937b3823-7e50-3982-067c-4465692e5a5f@polymtl.ca> Date: Tue, 23 Mar 2021 17:46:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <7de4f1b8-d210-67f3-f76a-ec953ee1fe6f@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 Tue, 23 Mar 2021 21:46:30 +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" On 2021-02-08 1:59 p.m., Luis Machado wrote:> 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. Indeed, I realized later that the very first line was already the one-sentence description of what the command does (see my own reply to this message). > Is there a standard for these command documentation bits somewhere? Not sure it's spelled out anywhere. But IMO the first sentence should always be a very high level explanation of what the command does, so you can get a quick idea if this is what you're looking for without having to read a whole paragraph. Then I like when things (like description of each argument) are nicely separated in paragraphs instead of one big paragraph, so it's easy to scan and jump to what you are looking for. >> 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. I suppose you meant "... and address when talking about allocation tags". What you have in v6 LGTM. Simon