From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id dBvED6ftBWDOJgAAWB0awg (envelope-from ) for ; Mon, 18 Jan 2021 15:20:55 -0500 Received: by simark.ca (Postfix, from userid 112) id 3175F1EF80; Mon, 18 Jan 2021 15:20:55 -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 5271A1E945 for ; Mon, 18 Jan 2021 15:20:54 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DB3693844062; Mon, 18 Jan 2021 20:20:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DB3693844062 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611001253; bh=DPu6UQKXb7pkFMmLhtJP5TjZ9ZpmEV8754a5isYWmDc=; 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=hDZDiNz6AVvOXUlwat8v5tOAN4m41VPVubdMLD+gPwsMe8WAJ7hif8tgjQZ2m7bS4 8Y5g4ZV6+vKHOoxsGN0Z432e+VIqlyBPkhadzL6oH0C7Wm18zY/zhu7ZCAeauOXlGP 0Uu53WHxv2ktduK8rHg9TiQHtBakD9H7dk/x2/J8= Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) by sourceware.org (Postfix) with ESMTPS id 309063844062 for ; Mon, 18 Jan 2021 20:20:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 309063844062 Received: by mail-qk1-x729.google.com with SMTP id f26so19865698qka.0 for ; Mon, 18 Jan 2021 12:20:51 -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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DPu6UQKXb7pkFMmLhtJP5TjZ9ZpmEV8754a5isYWmDc=; b=VayY9puMeKZbyZJ6TABdqmJVDuSM3EXD514wejGw7itledeyb8DPtR+BFWlzexZ3L2 UAeNjrCQ0dx2SlU7km9qFL7Vy2/+m2QWpuvu4T6TQuZQ1VMlYsXJXIg2fmev+KFrnIVz 2TfCaxCxOL1br9ow9qbMXgnp8zr4YfW5CCOg3k89noUSUEdgceOElXfdVKmcHZplLrsD LFOjQEZDg1b0N9cnez34SmQgz9PrfH3PjjjkZmFJv0F7GVOLCuIimgys8FotJbs8H+xh x8zDEOJENj9gp4ZRD3CLHAKrLs/aY72vkm+Dyon3vJH1kdGuhoXfxNam4ukJAPKrnC/1 TgKA== X-Gm-Message-State: AOAM530WfrNVzXyM9XQEwDm0R+OFaj4GFVcIr8VniI1FxNrv8O16FOhb 0OfDoroV2vzLG0txZnUEuprPoQ== X-Google-Smtp-Source: ABdhPJzi0r1v60moOIAEH1yMQzJI/uGLQZO4Wb5Fx1FV53kc/Mhtk4iFyGilfEwyLUD6841qnSnS8Q== X-Received: by 2002:a37:4796:: with SMTP id u144mr1256540qka.235.1611001250703; Mon, 18 Jan 2021 12:20:50 -0800 (PST) Received: from ?IPv6:2804:7f0:8284:874d:d01c:4557:3294:bc27? ([2804:7f0:8284:874d:d01c:4557:3294:bc27]) by smtp.gmail.com with ESMTPSA id b78sm11435792qkg.29.2021.01.18.12.20.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Jan 2021 12:20:49 -0800 (PST) Subject: Re: [PATCH v3 21/24] Extend "x" and "print" commands to support memory tagging To: Simon Marchi , 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: <26185397-e57f-0c69-4979-97770d903324@linaro.org> Date: Mon, 18 Jan 2021 17:20:47 -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: 8bit 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 Cc: david.spickett@linaro.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 1/18/21 2:56 PM, Simon Marchi wrote: > > > 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. Thinking about this, it makes sense. If a target does not implement the memory tagging commands, then GDB will display an error stating so. I can update v4 to follow this suggestion. > > 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? Right. GDB first evaluates the expression into a result (struct value *), then checks if the result is a pointer. If that is the case, then it proceeds to do the check. We don't check each individual element in an expression. We could do so in the future, of course. But, given the most common use case we're trying to cover, I don't think the extra complexity and verbosity would be worth it. The most common use case would be a faulty program that is running into a SIGSEGV due to a tag violation. Then the developer can use GDB to pinpoint where that violation is coming from, why it is happening and what the right tag should be for that particular case. Checking every individual element of an expression (tag-wise) would be a bit too much. And the default for this feature most likely would need to be "off" so we don't incur in unnecessary overhead. The answer to the question "is this particular pointer tagged?" is already a bit expensive to answer, given we need to go through the /proc//smaps file and parse each memory map entry. > > 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? Compiler-wise, I'm pretty sure a contiguous array of 32 bytes would have the same tag across its 2 granules. Of course you could create an area with 2 granules containing different tags, and then try to access those as an array of 32 bytes through some pointer. In GDB, "p array[0]" wouldn't cause warnings about tag mismatches because you're evaluating the expression and getting, say, an integer back. And integers don't hold logical tags. If you issue "p array" instead, then GDB will attempt to validate the tag for you. (gdb) ptype a type = unsigned char * (gdb) memory-tag print-allocation-tag &a[0] $3 = 0x0 (gdb) memory-tag print-allocation-tag &a[16] $4 = 0x0 (gdb) p a Logical tag (0x8) does not match the allocation tag (0x0). $1 = (unsigned char *) 0x800fffff7ffa000 "\001\002" (gdb) p a[0] $5 = 1 '\001' (gdb) p a[16] $6 = 0 '\000' (gdb) p &a[16] Logical tag (0x8) does not match the allocation tag (0x0). $7 = (unsigned char *) 0x800fffff7ffa010 "" > > Simon >