On Mon, 4 Aug 2025 at 16:34, Alex Bennée <alex.ben...@linaro.org> wrote: > > Vacha Bhavsar <vacha.bhav...@oss.qualcomm.com> writes: > > > This patch increases the value of the MAX_PACKET_LEGNTH to > > 131100 from 4096 to allow the GDBState.line_buf to be large enough > > to accommodate the full contents of the SME ZA storage when the > > vector length is maximal. This is in preparation for a related > > patch that allows SME register visibility through remote GDB > > debugging. > > > > Signed-off-by: Vacha Bhavsar <vacha.bhav...@oss.qualcomm.com> > > --- > > Changes since v3: > > - this patch was not present in version 3 > > > > gdbstub/internals.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/gdbstub/internals.h b/gdbstub/internals.h > > index bf5a5c6302..b58a66c201 100644 > > --- a/gdbstub/internals.h > > +++ b/gdbstub/internals.h > > @@ -11,7 +11,7 @@ > > > > #include "exec/cpu-common.h" > > > > -#define MAX_PACKET_LENGTH 4096 > > +#define MAX_PACKET_LENGTH 131100 > > This is a rather large expansion for something that ends up in a static at: > > char line_buf[MAX_PACKET_LENGTH]; > > I think maybe its time to get rid of this hardcoded define and make line_buf a > dynamically re-sizeable buffer along the lines of str_buf and mem_buf. > In fact make it a GString and we can get rid of line_buf_index as well.
What exactly is the packet/response where MAX_PACKET_LENGTH is causing problems? The commit message doesn't say. In general I thought the gdbstub protocol was supposed to handle a fixed packet length (e.g. in handle_query_xfer_features() the response packet indicates truncation via "l" vs "m" so the gdb end knows it needs to send another request to get the rest of the data). So if we run into something which seems to be fixed by raising MAX_PACKET_LENGTH I would first want to look at whether the underlying problem is that we're not indicating to gdb "this data is incomplete, you'll need to ask for more of it" or something of that nature. thanks -- PMM
