Re: [PATCH v3 07/24] Documentation for memory tagging remote packets

Luis Machado via Gdb-patches
2020-11-16T17:23:05Z

On 11/16/20 1:04 PM, David Spickett wrote:
> Also with regard to the "type" field.
>
>> +@var{type} is the type of tag the request wants to fetch. The typeis a signed
>> +integer.
>
> (typo aside) Is this field architecture specific and will there be a
> list of these type numbers documented anywhere? (or already is)
> For example would 1 on AArch64 be MTE, and on <other arch> be <other
> tag type>. Or would that <other tag type> be 2.
>
> My assumption has been that it is the latter and that a value means a
> kind of tagging extension. So for example 1=MTE rather than
> 1= mte logical and 2 = mte allocation. Correct me if I am wrong there.

Right now the design makes these types architecture-specific. It would
be nice to have more documentation about them, for sure.

But there's one catch right now. The user-visible commands know about
two types of tags (logical and allocation). The native/remote side of
GDB only sees one type, the allocation one, as it doesn't make sense to
ask the native/remote target about logical tags.

This is slightly messy and, in my opinion, should be an implementation
detail.

So, in summary... We have a couple generic tag types GDB knows about:
logical and allocation.

Those types get translated to an arch/a target-specific type when they
cross the native/remote target boundary.

In theory we could have generic tag types 1 and 2 in generic code, but
tag type 2 gets translated to type 1 in a remote packet.

Maybe we could improve this a little.

>
> A page like:
> https://sourceware.org/gdb/current/onlinedocs/gdb/ARM-Breakpoint-Kinds.html#ARM-Breakpoint-Kinds
>
> Or just a short note, given that there's only one type right now.

Yes, that would be nice to expand for the tag types.

>
> Also, I may have suggested the type be a string at some point. However
> based on examples like the link above
> I don't see much advantage to it apart from making packet dumps easier
> to read. Just wanted to close the loop on that
> if I didn't before.

I don't have a strong preference here. I'm just forwarding the tag type
from generic code.

If we want to pass strings, we will need a gdbarch hook that maps a type
to a string in the remote target layer.

Otherwise we'd need to standardize on particular tag type names across
different architectures, like "hw memory tag", "sw memory tag",
"capability tag" etc.

>
>
>
> On Mon, 16 Nov 2020 at 15:44, David Spickett <david.spickett@linaro.org> wrote:
>>
>> Minor thing, there is a missing space here in "typeis".
>>
>>> +@var{type} is the type of tag the request wants to fetch. The typeis a signed
>>> +integer.
>>
>> On Mon, 9 Nov 2020 at 17:08, Eli Zaretskii <eliz@gnu.org> wrote:
>>>
>>>> Date: Mon, 9 Nov 2020 14:04:18 -0300
>>>> From: Luis Machado via Gdb-patches <gdb-patches@sourceware.org>
>>>> Cc: david.spickett@linaro.org
>>>>
>>>> gdb/doc/ChangeLog:
>>>>
>>>> YYYY-MM-DD Luis Machado <luis.machado@linaro.org>
>>>>
>>>> * gdb.texinfo (General Query Packets): Document qMemTags and
>>>> QMemTags. Document the "memory-tagging" feature.
>>>> ---
>>>> gdb/doc/gdb.texinfo | 96 +++++++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 96 insertions(+)
>>>
>>> OK for this part, thanks.