From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JSLwDKtnYmL41AEAWB0awg (envelope-from ) for ; Fri, 22 Apr 2022 04:30:35 -0400 Received: by simark.ca (Postfix, from userid 112) id 237D01E058; Fri, 22 Apr 2022 04:30:35 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=LAnrqtV0; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 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 7550A1E01D for ; Fri, 22 Apr 2022 04:30:34 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B672E3857340 for ; Fri, 22 Apr 2022 08:30:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B672E3857340 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1650616233; bh=J/y0D5u057LS0Irh6/JOJy+itT8QLHvKwCiZoGbGxCU=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=LAnrqtV0TiG8wwALXCHCSDVgC/y2ZHPOF4yjhvRqZShuTVBTfifdnKeVGdcahRcQe DRvCtJw4Uom/7lbrGydhjz7pgpLApotunS+tsqidR/y7+Iju4tmLmowpXJF+EU8nDi hECOQwxKQaDXnoSbSq/QJkXTFj2kqIuLCZJVGggo= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id A48B53857340 for ; Fri, 22 Apr 2022 08:30:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A48B53857340 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53706) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhog8-00052v-OC; Fri, 22 Apr 2022 04:30:12 -0400 Received: from [87.69.77.57] (port=2020 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhog0-0002do-8i; Fri, 22 Apr 2022 04:30:12 -0400 Date: Fri, 22 Apr 2022 11:30:02 +0300 Message-Id: <83v8v1plkl.fsf@gnu.org> To: Luis Machado In-Reply-To: (message from Luis Machado on Fri, 22 Apr 2022 09:12:44 +0100) Subject: Re: [PATCH, v2] [AArch64] MTE corefile support References: <20220331140343.9047-1-luis.machado@arm.com> <20220421152040.128278-1-luis.machado@arm.com> <83pmlaqvrl.fsf@gnu.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: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > Date: Fri, 22 Apr 2022 09:12:44 +0100 > Cc: gdb-patches@sourceware.org > From: Luis Machado > > >> *** Changes since GDB 12 > >> > >> +* GDB now supports dumping memory tag data for AArch64 MTE. It also supports > >> + reading memory tag data for AArch64 MTE from core files generated by > >> + the gcore command or the Linux kernel. > >> + > > > > I think this should say something about the significance of this > > feature. Otherwise it is completely unclear why would GDB want to > > support that. > > > > Same comment for the addition to the manual. > > > > Thanks. > > It is a bit short. How about the following additional paragraph? > > "When a process uses memory-mapped pages protected by memory tags (for > example, AArch64 MTE), this additional information will be recorded in > the core file in the event of a crash or if GDB generates a core file > from the current process state. > > The memory tag data will be used so developers can display the memory > tags from a particular memory region, and will also be used to show a > detailed message about a crash that happened due to a memory tag violation." This is fine, but can what's described in the last paragraph be done by GDB commands, or does it require external tools? In the former case, we should mention those GDB commands; in the latter case I'd settle for mentioning the fact that external tools are required. Thanks.