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

[David Spickett]

> Right now the design makes these types architecture-specific.

This works too, in fact it matches the breakpoint types example better that way.

> 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.

Tell me if I have this right.

In gdb in overall you have these two types but the server only uses
one of them, the allocation tag type.
So only the allocation tag type will ever go over the protocol. (for
MTE at least)

Given that, if we assume that "mte allocation" type is 1. A future
AArch64 kind of memory tagging could allocate 2 and on for its tag
types.
Something like:
AArch64 Memory Tag types -
  0 : MTE logical (which is internal only, reserved but documented as
unused, or left out completely?)
  1 : MTE allocation (the one we use at present)
  2: <future tagging> logical tag (because maybe there is some server
component for this kind of tagging extension?)
  3: <future tagging> allocation tag

The reason I want to clarify is that I understood the type to
differentiate tagging technologies, not the kind of tag within them.
(the type tells you MTE vs <future tag type> instead of allocation vs logical)
The use case being what if you have MTE and <future tag type> active
in the same target and I want to set an MTE allocation tag,
how can the server tell them apart?

If the type numbers overlap between tagging technologies, we can't
tell them apart.
However if they encode what extension they are for and the
logical/allocation type (as in the example above) then we can.

A lot of that is probably academic given there's one relevant type but
we can at least document the intent of the field.
E.g. "these types are global to AArch64 so new types should not
overlap existing ones"

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

Well I was thinking of type more as a single value like "mte". Anyway
I'm fine with the integer route.

On Mon, 16 Nov 2020 at 17:23, Luis Machado <luis.machado@linaro.org> wrote:
>
>
>
> 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.