On Wed, 6 Aug 2025 at 22:18, Vacha Bhavsar <vacha.bhav...@oss.qualcomm.com> wrote: > > Hi, > > I reached out to the gdb dev team regarding these questions > on how to correctly handle the SME za storage. This discussion > can be found here: > > https://sourceware.org/pipermail/gdb/2025-August/051858.html > https://sourceware.org/pipermail/gdb/2025-August/051860.html > > It seems this approach of increasing the buffer size to above > 131100 has also been applied to gdbserver as there currently > isn't support for partial data transfers.
Thanks for chasing that up. (1) I note that gdb bumped this to 131104, and we only have 131100. We should check what the worst-case is and make sure our number is big enough (maybe we count different things in our buffer size than gdbstub does?) (2) We should add a comment to MAX_PACKET_LENGTH, something like: /* * Most "large" transfers (e.g. memory reads, feature XML * transfer) have mechanisms in the gdb protocol for splitting * them. However, register values in particular cannot currently * be split. This packet size must therefore be at least big enough * for the worst-case register size. Currently that is Arm SME * ZA storage with a 256x256 byte value. We also must account * for the conversion from raw data to hex in gdb_memtohex(), * which writes 2*size + 1 bytes, and for other overhead like * the command itself or the checksum. */ (but ideally check the figures and be a bit less vague about the "other overhead" :-)) -- PMM
