Re: [PATCH v3 7/7] gdb: Document qMemTagCheckAddr packet

[Luis Machado <luis.machado@arm.com>]

On 4/9/24 16:33, Tom Tromey wrote:
>>>>>> "Gustavo" == Gustavo Romero <gustavo.romero@linaro.org> writes:
> 
>>> Is querying really needed in this case?
>>> Like, if there is some user feature that requires knowing whether this
>>> work before ever trying it, then I guess that would be a good
>>> justification.  In other cases, it seems to me that simply trying to use
>>> a packet is better than a qSupported response; or at least I don't know
>>> why it wouldn't be.
> 
> Gustavo> That's right, I think we are in sync here. Luis communicated to me last week
> Gustavo> (private conversation) about this possibility, hence for v4 we just try to
> Gustavo> send the qMemTagCheckAddr packet, and if it fails (empty reply) there is a
> Gustavo> fallback to the current code path, which reads the smaps. So I'm dropping
> Gustavo> the memory-tagging-check-addr feature.
> 
> Great, thank you.
> 
> TBH I am not sure if my view on the desirability of probing versus
> qSupported is the correct one.  Like, there may be counterexamples I'm
> unaware of.

We already have a qSupported string that reports if memory tagging is
supported by the remote (memory-tagging+). So before we send this new
packet, gdb can check if it makes sense to send it. If the target
supports memory tagging, then the answer is yes. Otherwise no.

If we didn't have "memory-tagging+", I think it would make sense to
have a feature string in place, because then a remote can support
the packet itself, but not necessarily support checking if a particular
address is within a tagged memory range.

So probing seems fine in this case. In the future gdbserver may implement
it as well. Until then, an empty reply from gdbserver will tell gdb this method
of querying is not supported.