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

[John Baldwin]

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