From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8iDFA6FuHWBvJAAAWB0awg (envelope-from ) for ; Fri, 05 Feb 2021 11:13:21 -0500 Received: by simark.ca (Postfix, from userid 112) id 02D8A1EFCB; Fri, 5 Feb 2021 11:13:20 -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 3807A1E939 for ; Fri, 5 Feb 2021 11:13:20 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B2A0639F8877; Fri, 5 Feb 2021 16:13:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B2A0639F8877 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1612541599; bh=9rQXZd7Kv7YRHA63VMoOR0vQjKxFhK3WiPz1a86l9hA=; 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=WHq18uuIoHM3NqW+6rxuQOivqxydz91QpC0IJpKyj5Ntb7t1qJZYjDPj2IzhVeclB qCGX1une3KyBrK2I83hQcXw5jtqHXX0wX6Zbs9QK2rvzFeKYDerj7z9HnQ0VSH3TzZ ytkrJ/X7wxWjf8wa5kHvkwy1d8sgpuO5JMxKZIQA= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 4AEB439F886D for ; Fri, 5 Feb 2021 16:13:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4AEB439F886D 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 115GDAag010741 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 5 Feb 2021 11:13:15 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 115GDAag010741 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 635451E939; Fri, 5 Feb 2021 11:13:10 -0500 (EST) Subject: Re: [PATCH v5 17/25] AArch64: Report tag violation error information To: Luis Machado , gdb-patches@sourceware.org References: <20210127202112.2485702-1-luis.machado@linaro.org> <20210127202112.2485702-18-luis.machado@linaro.org> <1bd853e9-00ce-9856-7bd6-f5ab0af88475@polymtl.ca> <8cd308f0-8a31-43d5-d540-e5315a25f41b@linaro.org> Message-ID: Date: Fri, 5 Feb 2021 11:13:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <8cd308f0-8a31-43d5-d540-e5315a25f41b@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 Fri, 5 Feb 2021 16:13:10 +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" > Right. This is being exposed so MI can potentially use the information (as is done for i386-linux). Though I wouldn't say it is guaranteed to be kept the same. > > Honestly, the goal is not to enable an MI MTE API right now. When the functionality is pushed and working well, then we can focus on making the MI layer MTE-aware. > > The new commands, for example, don't have MI counterparts at this point. > > Given only a handful of architectures are using tagged memory, I'm not even sure if it is worth coming up with an MI API yet. I'm not talking about new MI commands, but MI output. If these fields are emitted today (with this patch series), someone MI frontend could read and make use of them, so they should be considered API and not change (in a backwards-incompatible way) in the future. So we should at least make sure that what this outputs does not paint us in a corner. Simon