From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) by sourceware.org (Postfix) with ESMTPS id 87F91385802A for ; Mon, 24 May 2021 13:41:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 87F91385802A Received: by mail-qt1-x82d.google.com with SMTP id t20so20607604qtx.8 for ; Mon, 24 May 2021 06:41:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cL1N5TpLzdONJL9DmoCsmXFVKE+A1ydo9LmS0L24fLU=; b=qbs2lT2tFkmF0KJYetPnRBLpbuykb/yNeN/SYZ3POsBxRJa44ywcMbVrwlw0mR7aaJ ioGMCWFvWzEIwVjGsIJKiCiiI3psZCkE1/dm5W2gRvuv7A+bJU3NuSySbrizY5rYsSju YKInhFEa5xc+Km23jeUvz8EFSIpjVTQDIQswDt1sbVeDAlbVjK2XjS12obiFZZHA/inZ LFQflINvvlFcMRkQc368Q0G3MgAaiJc7IhvUqjtJ8wdnA9/5nfA8BuwTSRfrHOW25bdg i72v1DDf7TNRjV4IjNMQU6mRB4wNvQFYtgWdtl1JOso90sKUXKj9WvjAKl1v7glG70qA kJgg== X-Gm-Message-State: AOAM531pwqDZfBF3eJw+KJeDvWmztBiDQgVNN71MSuQ/w69LC0/eM2Zr vLZMunIPbPdxK8+WNnxTthb88Q== X-Google-Smtp-Source: ABdhPJzgUHG7huQ4fd6v6QVyE2b5uRcbvqHmT76CJF57tZS/spBg4+kSlUW07dp8ZyGIujz0DAUTgA== X-Received: by 2002:ac8:c86:: with SMTP id n6mr27257136qti.100.1621863711054; Mon, 24 May 2021 06:41:51 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:5c9d:b127:8b5d:e87f:5e7d? ([2804:7f0:4841:5c9d:b127:8b5d:e87f:5e7d]) by smtp.gmail.com with ESMTPSA id k23sm754458qkk.71.2021.05.24.06.41.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 May 2021 06:41:50 -0700 (PDT) Subject: Re: [PATCH] [AArch64] MTE corefile support To: John Baldwin , 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: Luis Machado Message-ID: Date: Mon, 24 May 2021 10:41:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, 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: Mon, 24 May 2021 13:41:53 -0000 Hi John, On 5/21/21 2:20 PM, John Baldwin wrote: > 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 Just recently Andrew added the NT_GDB_TDESC note type, which is supposed to be OS-independent. The value for that (0xff000000) was picked out of a range that doesn't overlap with existing OS-specific definitions. I'm doing the same for NT_MEMTAG. You can use it for any OS (or bare-metal), as it doesn't have anything Linux-specific. > wanted something truly independent we could perhaps choose a neutral > note name (e.g. "memtag" instead of "Linux", "CORE", or "FreeBSD") and I'm using CORE right now. But we could change it to something else if needed. Isn't CORE something any OS can work with? > 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. >