From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id yNkzIOnLBWBaIwAAWB0awg (envelope-from ) for ; Mon, 18 Jan 2021 12:56:57 -0500 Received: by simark.ca (Postfix, from userid 112) id 816F01EF80; Mon, 18 Jan 2021 12:56:57 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 32FB41E940 for ; Mon, 18 Jan 2021 12:56:57 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E2250388C014; Mon, 18 Jan 2021 17:56:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E2250388C014 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610992616; bh=RnUnjvhe/upqp+gzHjpTFeGbuJaANzytc7EHtmcUg14=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Zc5mv3MTlFR8dMObCWiqf4PpoFxpoo7lbdWkK5Nu0H22F3qUi748s5dfoAIN2+M9H kq0GVvEiXVcwlUdP1l0gVHDc3VES9bES6nSZJNtx+OUYaXoVXl2hBaQwcPfxi0NgSe LZNQUWZyP6Z9n3Ql671E6ieuN9mOf6ifAntLZMV0= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 6FF9A388A40D for ; Mon, 18 Jan 2021 17:56:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6FF9A388A40D 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 10IHum6o006980 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Jan 2021 12:56:52 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 10IHum6o006980 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 DD9011E940; Mon, 18 Jan 2021 12:56:47 -0500 (EST) Subject: Re: [PATCH v3 21/24] Extend "x" and "print" commands to support memory tagging To: Luis Machado , gdb-patches@sourceware.org References: <20201109170435.15766-1-luis.machado@linaro.org> <20201109170435.15766-22-luis.machado@linaro.org> <19b87dc2-9192-c5d5-9534-b21d747e7e8c@polymtl.ca> <6e10ecee-e09f-70a2-f388-e7767e4fdd88@linaro.org> Message-ID: Date: Mon, 18 Jan 2021 12:56:47 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <6e10ecee-e09f-70a2-f388-e7767e4fdd88@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 18 Jan 2021 17:56:48 +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 Cc: david.spickett@linaro.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2020-12-29 1:50 p.m., Luis Machado wrote: > The switch that controls this is the one that enables/disables memory tagging. It controls both the print command behavior and the "x" command behavior. > > Do you think we should have a command for each individual command? Hmm well I'm comparing it to the other "set print" options. If you add an option (say, "memory-tag-violations" to the value_print_option_defs array, you get both set print memory-tag-violations on/off and print -memory-tag-violations on/off options for free. And now that I think about it a bit more, I am not sure why the "set memory-tagging" exists (at least as of today). It controls whether you can use the "memory-tag" commands, but I don't really see why that's useful. If you don't want to use these commands, you can just not use them not need for them to be disabled. Otherwise, the memory_tagging global is only used to control whether "print" and "x" should talk about memory tags. With my suggestion above, print already has its -memory-tag-violations flag and "set print memory-tag-violations" option. And the "x" command already has its /m option that you implemented. So I don't see a need for the "set memory-tagging" option. If tracking memory tags required maintaining a state as the program runs, then it would make sense to have a "set memory-tagging on/off" option to enable/disable that feature. And I think that printing memory tags and printing memory tag violations are two separate things, so we should be precise in the option names. We might later want to implement a "print" option to print the logical tags every time a pointer value is printed (a bit like symbols are printed when the pointer points to a symbol). That could then be controlled by set print memory-logical-tags print -memory-logical-tags By naming the new print option "memory-tag-violations" (rather than say "memory-tags"), we leave the door open to things like that. Random usage questions: If I do (gdb) print myptr and myptr has the wrong logical tag for the pointed memory area, it will print that there is a memory tag violation. But will it also print it if myptr is dereferenced in an expression, like this? (gdb) print *myptr + 2 I guess not, as this is only checked when the final value is printed. Is this something we might want in the future? What happens for arrays? If the granule size is 16 bytes, but you have an array of 32 bytes, does the array have two different allocation tags? But then the pointer (that points to the beginning of the array) can only contain a single logical tag. What happens when you use the pointer to access the various areas of the array? Simon