[PATCH 00/23] Memory Tagging Support + AArch64 Linux implementation

[David Spickett]

(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 <jhb@freebsd.org> 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:<type>:<address>:<length>
> >>
> >>    and similarly for QMemTags.
> >>
> >>    For MTE <type> could be "MTE" or "mte".  In the case that an architecture
> >>    provides multiple tag types, then <type> 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