From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id C1D8E3858404 for ; Mon, 2 Aug 2021 12:06:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C1D8E3858404 Received: by mail-pl1-x635.google.com with SMTP id e21so19355648pla.5 for ; Mon, 02 Aug 2021 05:06:05 -0700 (PDT) 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=7J9uhT/Ci9e/59v/8KRSNCgkgYPB5/4+jpgGjBlsqIY=; b=uljh6kaSe0h7TiefnmPg4eaOqDwb4BDt8asDTkkfe1+GuezlqIeIWQB1lDZxONrBZE 7sHTaGfFh1oo0ClInrlPeNUIH5/wzeNv98hGdPCo1yP+Ul9WSa2yDJivE0+6C1uuYO45 qTsPC5XlgDFs367Ae7xG2C//nqHKoVTQLkAmPaRGP0AhxQ0mE448lhq4mcuxs2hFSSas Ws9eHmbBhWp7uR+MWA/4EI10pNSJa8I3TIUjChToaZQuXFBa/gcLhc37aRiim5a+wIIg i+U7pQLZDrsi4M/WWHJFNqMmgq65gy1cHWJpDP0ykRtKXs8ViQVll1o7FuUIdycyeXk0 aDpQ== X-Gm-Message-State: AOAM5304WLKvPpGLVlE5ktFO8Iii3fas29wp1agPUHmE0kdRYH1D/Zpd vT5JyPqewNa1l6ffzU0PcpKDbA== X-Google-Smtp-Source: ABdhPJxQHbaXDgUMbzd+tZm2vcMi3hyPGzSQ34RMxE/P5kplCjpVDkpSpD9o60zfMt47VGslsPrzXA== X-Received: by 2002:a63:215a:: with SMTP id s26mr184553pgm.448.1627905964494; Mon, 02 Aug 2021 05:06:04 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:25bc:25ec:a674:2085:682d? ([2804:7f0:4841:25bc:25ec:a674:2085:682d]) by smtp.gmail.com with ESMTPSA id z11sm2066085pfr.201.2021.08.02.05.06.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Aug 2021 05:06:04 -0700 (PDT) Subject: Re: [PING][PATCH,v5][AArch64] MTE corefile support To: Joel Brobecker , Simon Marchi Cc: Catalin Marinas , Luis Machado via Gdb-patches , david.spickett@linaro.org References: <20210518202047.3492211-1-luis.machado@linaro.org> <20210601174519.4157316-1-luis.machado@linaro.org> <20210711142200.GA637634@adacore.com> <20210714130702.GA9376@arm.com> <20210729181044.GD31848@arm.com> <7d85da38-1e88-1f1f-77fa-15dbe483538b@polymtl.ca> <20210801154405.GA471794@adacore.com> From: Luis Machado Message-ID: <9f5c7aff-40a3-5d4f-6f2c-b9d9e855916b@linaro.org> Date: Mon, 2 Aug 2021 09:06:00 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210801154405.GA471794@adacore.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 02 Aug 2021 12:06:07 -0000 On 8/1/21 12:44 PM, Joel Brobecker wrote: >> On 2021-07-29 2:10 p.m., Catalin Marinas wrote: >>> I'm more worried about GDB 11 reading the MTE notes incorrectly rather >>> than not reading them at all. >> >> Yeah, if a GDB 11 that knows how to read the pre-standardized notes does >> not fail gracefully when encountering the standardized notes, it would >> be bad. If it just skipped them and said "I don't recognize them", it >> would be ok. > > Agreed. > > Is there a way we could check the notes? I looked at the patch, > and it doesn't seem like there is any kind of versioning or > identifier we could use to determine which version of the notes > we get. But perhaps we can at least do some kind of consistency We have a generic header containing NT_MEMTAG and an arch-specific header identifier containing NT_MEMTAG_TYPE_AARCH_MTE. The arch-specific identifier can be versioned as needed. We could, for example, have NT_MEMTAG_TYPE_AARCH_MTE_V2. > check, such as for instance comparing the size of the section > with the contents of the section header, and generate an error > if that doesn't match. The error might not be as informative, > but perhaps still good enough? On further discussion with the Linux Kernel developers, we're going to take the safe path and will wait for this part to be under review on the Linux Kernel ML before adopting it in GDB. > >> Oh, ok, I thought it had already gone through some review cycles. Then >> I'll leave it to you all to decide, those who have some stakes in this. >