From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KAjQJz7vAmEjSgAAWB0awg (envelope-from ) for ; Thu, 29 Jul 2021 14:11:10 -0400 Received: by simark.ca (Postfix, from userid 112) id A11951EDFB; Thu, 29 Jul 2021 14:11:10 -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=unavailable 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 A7F9A1E813 for ; Thu, 29 Jul 2021 14:11:09 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4243E393C87A for ; Thu, 29 Jul 2021 18:11:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4243E393C87A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1627582269; bh=8WtPGd8Xrs4QlFePlGHLc263yAZx23hdpOdHYCU3Fvg=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=RY+SWU4MNhmtJe4hrGQkqqC536uqYjC5Gno4Op6xztVff3ubABGAOfHVxSAZn1eUk JgnibulBImL+hVLMopmbELU956+q2t5kUIB6+FpLX95IVmM/SNXdRrs7s2N+YiJaLY Mpqg4PTms4mypySmw3Yj0vzoiPXBFePuF/G+WJ4k= Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by sourceware.org (Postfix) with ESMTPS id 409D9384601E for ; Thu, 29 Jul 2021 18:10:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 409D9384601E Received: by mail.kernel.org (Postfix) with ESMTPSA id 89AAD60E94; Thu, 29 Jul 2021 18:10:47 +0000 (UTC) Date: Thu, 29 Jul 2021 19:10:44 +0100 To: Simon Marchi Subject: Re: [PING][PATCH,v5][AArch64] MTE corefile support Message-ID: <20210729181044.GD31848@arm.com> References: <20210518202047.3492211-1-luis.machado@linaro.org> <20210601174519.4157316-1-luis.machado@linaro.org> <20210711142200.GA637634@adacore.com> <20210714130702.GA9376@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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: Catalin Marinas via Gdb-patches Reply-To: Catalin Marinas Cc: david.spickett@linaro.org, Luis Machado via Gdb-patches , Joel Brobecker Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Wed, Jul 28, 2021 at 10:26:58PM -0400, Simon Marchi wrote: > On 2021-07-14 9:07 a.m., Catalin Marinas wrote: > > On Sun, Jul 11, 2021 at 07:22:00AM -0700, Joel Brobecker wrote: > >> Luis is trying to have this new feature ready for the GDB 11.1 > >> release. As I understand it, the AArch64-specific part has already > >> been approved, so he's waiting for someone to review the rest of > >> the changes. Is there a Global Maintainer who would feel comfortable > >> doing so and who would have the time? > > > > I'm a Linux kernel maintainer, so not much for me to review on the gdb > > front. But feedback from the gdb maintainers would be appreciated. > > > > W.r.t. upstreaming the feature in gdb, I'd wait until the Linux > > counterpart is merged. We agreed in principle on the ABI but I wouldn't > > consider it stable until the feature hits a kernel release. > > I reviewed a few of the previous iterations, and there were only really > some nits remaining, so I am confident that this version is OK, from a > GDB point of view. > > ABI-wise, I tend to agree with Catalin: as long as it's not in a > released kernel, the format *could* change. But is it a problem in > practice? Let's say this happens: > > - We merge support for MTE core files in GDB 11 > - The format gets changed, merged and released in a kernel > - We fix GDB 12 based on the new format > > Then GDB 11 users end up with a GDB that can't read MTE notes. But had > we not merged the support for it, they would also end up with a GDB that > can't read MTE notes. In both cases, we'll tell them "upgrade to GDB > 12" (once it's released). I'm more worried about GDB 11 reading the MTE notes incorrectly rather than not reading them at all. > If we merge support for MTE in core files now and if the format > doesn't change, everybody is happy. I guess it depends on how likely it > is that the format is going to change. That's hard to say before we go through at least one Linux kernel mailing review. -- Catalin