From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) by sourceware.org (Postfix) with ESMTPS id 1CAE43857C64 for ; Fri, 24 Jul 2020 16:10:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1CAE43857C64 Received: by mail-vs1-xe42.google.com with SMTP id x205so5166776vsc.11 for ; Fri, 24 Jul 2020 09:10:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kSaccDdaw6T4d3jnhkpVjHk6FH+SxYnL4mBa3jXwSpU=; b=XjFC4NiY6h0vH7yu+S8HAlFOIoEwnC7q70zhRsk75et6P/aJQkYnt5UGpW5oXdgVKu aPlO1Fb/R8C6JI5GtSB07Dlqlp2+z13EDf8J1ogyuoKQGjSSuOTfeMiLuBhNQ6DfGs+P dLU+Nh7Atm+KZFR/wpuYSSCHsZnluX7TNBsu6QBG+d6NKzR8FQ40xmLzmbt54QcsWe3+ vpo1AkS63QQSUZw9wuMOC4IYExu/quZEEUocA4RkiVDIIBegOVOODt1rT1nxjac4X3P4 1J/wyPkGFP6tadmJhI3XHg0TsDcaabolWZxepHyUga4B7wvyT708l3r+8+UYOFCmCvwi Gitg== X-Gm-Message-State: AOAM531WpU5ITUnqQifZOvjVUUXZkQTJp9w7HQYAjDvjIZtBsbWuC6fa stvWF9HSk4thgyMODPR3FOfacy3Hd5W9ZS+HiTyigpW22Bc= X-Google-Smtp-Source: ABdhPJzab11UAKM2yAVKgZL9KYqbW5g1R3cMiXfPtR0PUJh6+BEq5BukKWdbq2hkuz+J0bUd5EX3m9F/Y0kryBjssGI= X-Received: by 2002:a67:bc1:: with SMTP id 184mr7971571vsl.104.1595607049614; Fri, 24 Jul 2020 09:10:49 -0700 (PDT) MIME-Version: 1.0 References: <20200715194513.16641-1-luis.machado@linaro.org> <80627efe-3aa2-fe0d-98e3-b7e7640d3904@linaro.org> <453663e2-8992-762d-045c-f6b731be2f0c@FreeBSD.org> In-Reply-To: <453663e2-8992-762d-045c-f6b731be2f0c@FreeBSD.org> From: David Spickett Date: Fri, 24 Jul 2020 17:10:37 +0100 Message-ID: Subject: Re: [PATCH 00/23] Memory Tagging Support + AArch64 Linux implementation To: John Baldwin Cc: Luis Machado , gdb-patches@sourceware.org, Alan.Hayward@arm.com, Omair Javaid Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Fri, 24 Jul 2020 16:10:52 -0000 (if it wasn't already mentioned, I'm working on the lldb side of things) > - 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. +1 for this idea. The use case seems somewhat distant now but it'll save us doing fragile heuristics on the packed tags to differentiate them if it does happen. (and the tags potentially being a pattern to be repeated makes this even less viable) On Thu, 23 Jul 2020 at 17:49, John Baldwin wrote: > > 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