RE: [PATCH 1/1] gdb, gdbserver: replace PBUFSIZ with a target op

[Andrew Burgess <aburgess@redhat.com>]

"Gerlicher, Klaus via Gdb-patches" <gdb-patches@sourceware.org> writes:

> Hi Simon,
>
> Thanks for the quick response.
>
> At least the initial buffer size needs to be fixed since now most
> clients aren't aware of any dynamic behavior here and therefore we
> need at least something pre-allocated for these clients.

I don't understand your concerns here.  For this patch we're only
talking about the gdbserver client, right?  And your patch (rightly)
doesn't change things on the GDB side.

GDB already uses a dynamic packet buffer size.  So the only initial
buffer I think you can be talking about here is the gdbserver buffer,
which I think could be made dynamic, just as GDB's is.

We could hard-code gdbserver to return some stupidly large number for
the PacketSize in the qSupported reply, say MAX_INT?  Or (MAX_INT / 4),
you pick, this could be anything really, just something huge.

Then on the gdbserver side we can use a dynamic packet size, and we just
take care to throw an error if GDB ever tries to grow it past our
(stupidly large) max packet size -- but this doesn't mean we actually
need to pre-allocate that large of a buffer.

Alternatively, we can always extend the remote protocol with a new
reply, say 'PacketSize=*' to indicate that the client supports variable
packet buffers -- but that would require GDB to first advertise that it
understands that syntax, then clients will need to deal with GDBs that
don't support it .... and it's a whole big thing.  Maybe easier just to
work within the current framework?  Though maybe not as clean.

Now for other clients (i.e. not gdbserver) they are free to keep using a
pre-allocated buffer, and they'll send back a much smaller PaketSize,
but that should be fine.  Nothing changes for them.

> For the clients interested we could change the CS buffer to a
> re-allocatable type that is pre-allocated with the current PBUFSIZ. We
> could pass this buffer around with a target op. The target could
> resize at will instead of letting it return a fixed number.

I didn't understand this paragraph.  I don't know what 'CS buffer'
means.  And I'm not sure why we're need a target op to pass the buffer
around -- but maybe that would become obvious if I looked at the code a
little more...

Thanks,
Andrew

>
> Is this something in line that you would support?
>
> Klaus
>
> -----Original Message-----
> From: Simon Marchi <simon.marchi@polymtl.ca> 
> Sent: Tuesday, September 19, 2023 4:08 PM
> To: Gerlicher, Klaus <klaus.gerlicher@intel.com>; gdb-patches@sourceware.org
> Subject: Re: [PATCH 1/1] gdb, gdbserver: replace PBUFSIZ with a target op
>
> On 9/19/23 01:45, Klaus Gerlicher via Gdb-patches wrote:
>> From: "Gerlicher, Klaus" <klaus.gerlicher@intel.com>
>> 
>> PBUFSIZ is a hardcoded value that needs to be as least twice as big as 
>> the register set.
>> 
>> This means that this could be tailored to the target register size as 
>> not all targets need a big buffer. For SIMD targets the buffer will 
>> obviously be much bigger than for regular scalar targets.
>> 
>> This patch changes this and adds a target op query_pbuf_size (). It 
>> also moves the static global client_state into the get_client_state () 
>> function and lazily dynamically allocates storage for its own_buf.
>
> Just throwing an idea out there... instead of trying to determine a buffer size that is large enough, can we instead pass something like an std::vector (gdb::char_vector or gdb::byte_vector) around, and whatever builds the packets and replies makes sure there is enough space?
>
> Simon
> 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