From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2610:1c1:1:606c::19:2]) by sourceware.org (Postfix) with ESMTPS id 49DCD3847835 for ; Fri, 21 May 2021 17:20:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 49DCD3847835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jhb@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id D86ED9E015; Fri, 21 May 2021 17:20:39 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fmtfb5BjSz4dHn; Fri, 21 May 2021 17:20:39 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id D4B106FB9; Fri, 21 May 2021 17:20:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: Luis Machado , Alan Hayward Cc: "gdb-patches\\@sourceware.org" , "david.spickett@linaro.org" , Catalin Marinas , nd References: <20210518202047.3492211-1-luis.machado@linaro.org> <8214C923-1DC2-4996-B070-FF248FE1669C@arm.com> <5b09fe6a-3d94-c355-8c81-6d7327760cb6@linaro.org> From: John Baldwin Subject: Re: [PATCH] [AArch64] MTE corefile support Message-ID: Date: Fri, 21 May 2021 10:20:35 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <5b09fe6a-3d94-c355-8c81-6d7327760cb6@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 21 May 2021 17:20:44 -0000 On 5/21/21 8:30 AM, Luis Machado wrote: > Hi Alan, > > On 5/21/21 12:12 PM, Alan Hayward wrote: >> >> >>> On 18 May 2021, at 21:20, Luis Machado wrote: >>> >>> Teach GDB how to dump memory tags when using the gcore command and how >>> to read them back from a core file generated via gcore or the kernel. >>> >>> Each tagged memory range (listed in /proc//smaps) gets dumped to its >>> own NT_MEMTAG note. A section named ".memtag" is created for each of those >>> when reading the core file back. >>> >>> Dumping memory tags >>> - >>> >>> When using the gcore command to dump a core file, GDB will go through the maps >>> in /proc//smaps looking for tagged ranges. Each of those entries gets >>> passed to an arch-specific gdbarch hook that generates a vector of blobs of >>> memory tag data that are blindly put into a NT_MEMTAG note. >>> >>> The vector is used because we may have, in the future, multiple tag types for >>> a particular memory range. >>> >>> Each of the NT_MEMTAG notes have a generic header and a arch-specific header, >>> like so: >>> >>> struct tag_dump_header >>> { >>> uint16_t format; // Only NT_MEMTAG_TYPE_AARCH_MTE at present >>> uint64_t start_vma; >>> uint64_t end_vma; >>> }; >>> >>> struct tag_dump_mte >>> { >>> uint16_t granule_byte_size; >>> uint16_t tag_bit_size; >>> uint16_t __unused; >>> }; >>> >>> The only bits meant to be generic are the tag_dump_format, start_vma and >>> end_vma fields. >>> >>> The format-specific data is supposed to be opaque and only useful for the >>> arch-specific code. >>> >>> We can extend the format in the future to make room for other memory tag >>> layouts. >>> >> >> This is a wider question than this patch - but is there someplace this format will >> be documented? Ideally either Linux or GDB needs something written down in >> text format. >> >> A few nits below too, but mostly looks fine. > > Yes. I'm still thinking whether this should go into the Linux Kernel's > documentation or somewhere in the GDB manual. > > Given GDB reads core files generated by the Linux Kernel and also > creates cores files itself, I'm thinking it may be best to put it in the > GDB manual. > > I want to wait for possible feedbacks about the format before we > document how it will look like in the manual. Also, NT_MEMTAG is not inherently OS specific and I plan to reuse whatever format is used here for CHERI tags on RISC-V and Morello in CheriBSD (a CHERI-aware version of FreeBSD). If someone adds MTE support in FreeBSD that would use the same format as well. To that end, I think we should aim to have the tag "type" values be OS independent (so just depending on the arch). Having an actual value of NT_MEMTAG that is portable is harder as various OS's already have conflicting NT_* namespaces. If we wanted something truly independent we could perhaps choose a neutral note name (e.g. "memtag" instead of "Linux", "CORE", or "FreeBSD") and then the note type could instead take the place of the type of tag, but that may be overly complicated compared to just having OS-specific NT_MEMTAG values. -- John Baldwin