Re: Question about gdb expectations on SME ZA storage

Hi Vacha,

On 8/5/25 22:23, Vacha Bhavsar via Gdb wrote:
> Hi,
> 
> I am developing a patch for QEMU which would allow QEMU to expose
> SME registers, such as the ZA storage, via is gdbstub to a remote
> gdb client session.
> 
> The change that I have suggested and the discussion regarding it
> can be found here:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2025-08/msg00716.html
> https://lists.gnu.org/archive/html/qemu-devel/2025-08/msg00733.html
> https://lists.gnu.org/archive/html/qemu-devel/2025-08/msg00748.html
> https://lists.gnu.org/archive/html/qemu-devel/2025-08/msg00749.html

That's a good addition. Thanks for pursuing it.

> 
> The main issue I was facing was that when we attempt to set the
> value of the za register, and the gdb client sends out a P packet
> as large as the entire za register, the gdb client gets stuck and
> doesn't return a prompt, until the timeout is hit.
> 
> My understanding is that the current implementation of QEMU, which is
> similar to the sample stub code provided in sparc-stub.c, has too small
> a value for MAX_PACKET_LENGTH (analogous to BUFMAX from sparc-stub.c).
> Due to this, when the stub has read MAX_PACKET_LENGTH bytes without
> having hit a checksum, it resets the state machine and begins waiting
> for the beginning of a command again, as is the case in the sparc
> example provided in gdb. Thus, I have found that appropriately increasing
> the value of MAX_PACKET_LENGTH to encompass the full size of the za storage
> resolves this issue.

Right, there is a similar change that has been done to gdbserver to 
handle such a large register. In the following commit, you can see where 
the PBUFSIZ constant was bumped to a much bigger value:

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b816042e88583f280ad186ff124ab84d31fb592b

> 
> However, there is discussion as to whether there is an underlying issue
> of something like not indicating to the gdb client that there is more data
> and it must be requested. This discussion can be found at the link provided
> above.
> 
> So, I was hoping to get some guidance on how gdb expects the SME ZA storage
> to be handled and if any of the above mentioned approaches would be
> appropriate for a gdbstub to handle the SME ZA storage.

The problem here is that the register fetch/store packets (G/g or P/p) 
don't support partial transfers. With register increasing in size (in 
particular vector registers), it might be sensible to handle this in the 
future and have register fetch/store packets that support partial transfers.

For now, I think the correct solution for your SME implementation for 
the QEMU gdbstub is to increase the buffer size for the G/g P/p packets. 
And you've done that.

It is worth mentioning two things...

1 - Make sure you check the gdb documentation here 
(https://sourceware.org/gdb/current/onlinedocs/gdb#AArch64-SME-registers-feature) 
and report the correct SME/SME2 feature XML. That way gdb can spot the 
XML features and enable additional features internally.

2 - Please be aware that gdb does not support changing the SVE/SME 
vector length mid-execution when connected to a remote gdbstub, so that 
includes QEMU's gdbstub. If the vector length changes mid-execution, gdb 
will not notice the change and gdb and the gdbstub will have differing 
ideas of what the SVE/SME register sizes are.

A fix for this is being pursued by the community, but it is not yet ready.