Re: [PATCH v2 03/24] Add GDB-side remote target support for memory tagging

[Luis Machado via Gdb-patches <gdb-patches@sourceware.org>]

On 10/29/20 11:22 AM, Alan Hayward wrote:
> 
> 
>> On 22 Oct 2020, at 20:59, Luis Machado <luis.machado@linaro.org> wrote:
>>
>> Updates for v2:
>>
>> - Add type field to target hooks.
>> - Add type data to qMemTags and QMemTags. The packets now look like this:
>>
>> qMemTags:<address>,<length>:<type>
>> QMemTags:<address>,<length>:<type>:<uninterpreted tag bytes>
>>
>> --
>>
>> This patch adds memory tagging support to GDB's remote side, with
>> packet string checks, new packet support and an implementation of
>> the two new tags methods fetch_atags and store_atags.
>>
>> GDBserver needs to know how to read/write allocation tags, since that is
>> done via ptrace.  It doesn't need to know about logical tags.
>>
>> The new packets are:
>>
>> qMemTags:<address>,<length>
>> --
>>
>> Reads tags from the address range [<address>, <address + length>)
>>
>> QMemTags:<address>,<length>:<uninterpreted tag bytes>
>> --
>> Writes the tags represented by the uninterpreted bytes to the address range
>> [<address>, <address + length>).
>>
>> The interpretation of what to do with the tag bytes is up to the arch-specific
>> code.
>>
>> Note that these new packets consider the case of packet size overflow as an
>> error, given the common use case is to read/write only a few memory tags at
>> a time.  Having to use a couple new packets for multi-part transfers wouldn't
>> make sense for the little use it would have.
>>
> 
> Minor nit: "Having to use a couple new packets”. Even after adding an “of” I’m
> not fully sure if that’s what you meant to write.
> 
> 

I guess I could make it more clear. What I meant to say is that we would 
need to come up with new packets (in addition to the couple ones we've 
added) to extend the current design to cope with multi-part transfers of 
tags in the remote protocol.