From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 9CCF03858C2C for ; Fri, 22 Apr 2022 08:43:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9CCF03858C2C Received: from fencepost.gnu.org ([2001:470:142:3::e]:53794) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhosd-00075O-IN; Fri, 22 Apr 2022 04:43:08 -0400 Received: from [87.69.77.57] (port=2861 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 1nhosc-00041F-S9; Fri, 22 Apr 2022 04:43:07 -0400 Date: Fri, 22 Apr 2022 11:43:04 +0300 Message-Id: <83tualpkyv.fsf@gnu.org> From: Eli Zaretskii To: Luis Machado Cc: gdb-patches@sourceware.org In-Reply-To: (message from Luis Machado on Fri, 22 Apr 2022 09:37:47 +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> <83v8v1plkl.fsf@gnu.org> X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: * 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: Fri, 22 Apr 2022 08:43:10 -0000 > Authentication-Results-Original: dkim=none (message not signed) > header.d=none;dmarc=none action=none header.from=arm.com; > Date: Fri, 22 Apr 2022 09:37:47 +0100 > Cc: gdb-patches@sourceware.org > From: Luis Machado > NoDisclaimer: true > Original-Authentication-Results: dkim=none (message not signed) > header.d=none;dmarc=none action=none header.from=arm.com; > > On 4/22/22 09:30, Eli Zaretskii wrote: > >> 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. > > No external tools are required. GDB already supports displaying memory > tags automatically if it detects the process is using those. We can > explicitly mention the 'm' modifier for the x command and the memory-tag > sub-commands. > > Would this be more appropriate for the manual entry? Or do you think it > makes sense to mention it in the NEWS as well? It's okay to only mention that in the manual. NEWS should just say that GDB can display those tags automatically. Thanks.