Re: Question about gdb expectations on SME ZA storage

Hi Luis,

Thank you for the insights!

Thanks,
Vacha

On Wed, Aug 6, 2025 at 4:39 PM Luis <[email protected]> wrote:

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