From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id B7504388A828 for ; Thu, 23 Jul 2020 16:49:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B7504388A828 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 "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 699686888D; Thu, 23 Jul 2020 16:49:01 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BCJFT1P26z3YMc; Thu, 23 Jul 2020 16:49:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-274.local (unknown [IPv6:2601:648:8203:2990:a49c:d31e:c824:33c0]) (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 47C9C1C50A; Thu, 23 Jul 2020 16:49:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: [PATCH 00/23] Memory Tagging Support + AArch64 Linux implementation To: Luis Machado , gdb-patches@sourceware.org, Alan.Hayward@arm.com Cc: david.spickett@linaro.org, Omair Javaid References: <20200715194513.16641-1-luis.machado@linaro.org> <80627efe-3aa2-fe0d-98e3-b7e7640d3904@linaro.org> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <453663e2-8992-762d-045c-f6b731be2f0c@FreeBSD.org> Date: Thu, 23 Jul 2020 09:48:58 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <80627efe-3aa2-fe0d-98e3-b7e7640d3904@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, 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: Thu, 23 Jul 2020 16:49:02 -0000 On 7/23/20 6:59 AM, Luis Machado wrote: >> - One thing I do see is that this currently assumes only a single memory tag >> type for a given architecture, but there may be architectures in the future >> which have multiple types of tags. For APIs we can always add that later >> if needed, but retroactively adding it to the remote protocol might prove >> more sticky. One alternative might be to do something like >> >> qMemTags::
: >> >> and similarly for QMemTags. >> >> For MTE could be "MTE" or "mte". In the case that an architecture >> provides multiple tag types, then could be used to disambiguate. > > That sounds reasonable, but I'd still like to leave the interpretation > of the type field to the target-specific code. Remote stubs would just > parse the field and pass it on to the target-specific layers. Agreed. > Out of curiosity, what other types of tags do you think could be used in > the future? The Morello prototype architecture includes "cheri" memory tags on aarch64, and while Morello doesn't include MTE, it is within the realm of possibility that a future aarch64 architecture will contain both MTE and CHERI and will thus include two sets of memory tags. One option would be for this to be provided as a special "combined" tag since MTE and CHERI both have the same tag stride (16 byte boundaries), but that might be more fragile to implement compared to having them named separately. >> - It might be better to not refer to tags specifically as "allocation tags" >> in the generic code like gdbarch.*. I do think the 'mtag' commands are >> also still a bit MTE-specific, but that is probably fine for now. > > I'm open to suggestions, but right now the two candidates we have are > ADI "versions" and MTE "tags". I guess I view "tags" as a generic way of having a parallel address space of memory (and in some cases registers) where metadata about the "normal" memory or register contents are stored. In that context "tag" is the general name for metadata and MTE happens to use the general name directly. I would perhaps just call them "tags" or "memory tags" in gdbarch, but that's a minor quibble. > We need a way to distinguish between the memory tags and the pointer > tags. "mtag", "atag" and "ltag" are documented in the manual so > developers can understand what their purpose is, even though those may > not match their particular architecture naming scheme. > > GDB can also put together aliases for the commands, so targets can > define their own naming scheme for memory tagging commands. That's fine. -- John Baldwin