RE: [RFC PATCH] gdb, rsp: clarify a 0-length memory access

[Andrew Burgess <aburgess@redhat.com>]

"Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com> writes:

> On Thursday, March 28, 2024 3:13 PM, Andrew Burgess wrote:
>> Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> writes:
>> 
>> > Currently GDB uses a 0-length write access to probe for the 'X' packet
>> > support.  However, it is not clear from the document what a 0-length
>> > read or write attempt should do.  Clarify the document that it is
>> > an error.  Also update gdbserver's implementation to return an error.
>> 
>> We're usually pretty conservative about changing existing remote
>> protocol behaviour.
>> 
>> If I understand the current behaviour correctly, we treat the zero
>> length access as always succeeding, but you propose to change this to
>> always fail.
>> 
>> What's the motivation for this change?  Does the existing behaviour
>> cause some problem?
>> 
>> Usually, when the docs are ambiguous we update the docs to reflect GDB's
>> current behaviour, unless the current behaviour is clearly wrong.
>> 
>> Thanks,
>> Andrew
>
> Hi Andrew,
>
> The background of the submission is the thread linked below, where Tom expressed
> his tendency to think that a 0-length access should be an error:
>
> https://sourceware.org/pipermail/gdb-patches/2024-March/207411.html

OK.  But here's my real worry.  Right now gdbserver always succeeds for
a zero length read/write, and it's possible that there exists other
remote targets that have copied this behaviour.

If we change the behaviour for this case, and an updated GDB, that
expects zero length will result in failure, connects to an old gdbserver
(or some other remote target), what happens?

Even if *this* patch doesn't introduce a dependency on the new
behaviour, future patches might, so the question I think is still a
valid one to ask.

Maybe we can show that older GDBs would _never_ send a zero length
request?  In that case maybe this is OK.

The solid solution would be to add a qSupported packet to control the
behaviour of a zero length access.  The default would continue the
current "success" strategy, while if the remote supports the new packet
the behaviour can switch to a "failure" strategy.

Thanks,
Andrew



>
> Thanks
> -Baris
>
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928