qfThreadInfo/qsThreadInfo stub impl and max packet size

Hi all,

I’m about to implement qfThreadInfo/qsThreadInfo in the lldb-gdbserver (llgs) branch. The qsThreadInfo only gets called when the full thread list couldn’t fit into the qfThreadInfo packet. That brings up a question I haven’t paid too much attention to yet - maximum client packet length.

I seem to recall there being some max client-bound packet length that a stub should assume unless something else has been negotiated. The two cases I care about are

(1) llgs talking to an lldb client (that presumably could arrange for a larger max packet size, and/or can use the full lldb gdb remote packet extensions), and

(2) llgs talking to another client that is adhering to the gdb-remote protocol.

It looks like the stub can report its max packet size (well, looks like it must) via qSupported with a PacketSize response, listing max bytes including the leading $ and checksum suffix. But what about the reverse direction (the max packet length that the client can accept?) Is there a generally accepted default?

It also seems like the qSupported request to the stub can take client-side values pushed in as suffixes to the qSupported request. Is that the way to inform the stub of the client’s max accepted incoming packet length?

Thanks for clarifying!

Sincerely,
Todd Fiala

It looks like the stub can report its max packet size (well, looks like it must)

Ignore the “must” part. I think I was misreading the table that described it. I think the required part was that the size must be specified if the PacketSize argument is included.

The rest of the question still stands.

Todd Fiala wrote:

It also seems like the qSupported request to the stub can take client-side values pushed in as suffixes to the qSupported request. Is that the way to inform the stub of the client's max accepted incoming packet length?

I can't see "PacketSize" listed as a gdbfeature, in the "GDB Remote Serial Protocol" appendix. (I assuming that the document lists gdbfeature and stubfeature as exclusive sets).

It's possible that the client is intended to tolerate large packets, since it is envisaged to run on a machine with sufficient memory to keep reallocing it's recv buffer. However, (I'm guessing here) the stub is intended to run on a more constrained environment, and where it may not be possible to allocate as much memory, and therefore is reliant on a statically allocated fixed-size buffer. As a consequence, the designers of the protocol may have decided that there must be a way to constrain the client, but that the stub need not be similarly constrained? Well, that's my take on it.

Matt

Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.

Hey Matthew,

Thanks for your thoughts on this. Just had a minute to dig around the code a bit. I was thinking the potential limit on the stub => client communication was more oriented towards max packet sizes expected over the (historically) not-assumed-to-be-reliable communication pipe between the gdb client and stub.

I found the code that triggered my question on this, in RNBRemote.h:

/* Generally speaking, you can’t assume gdb can receive more than 399 bytes
at a time with a random gdb. This bufsize constant is only specifying
how many bytes gdb can receive from debugserver – it tells us nothing
about how many bytes gdb might try to send in a single packet. */
#define DEFAULT_GDB_REMOTE_PROTOCOL_BUFSIZE 399

So my question was really where did this number come from, and in which cases does it really matter, and is there some way to negotiate a much larger number or discard it entirely if - say - the communication medium is known to be reliable.

I found a bit of interesting content in the qSupported docs on the max packet length that the stub can assume of the gdb remote client end (https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qSupported):

Any GDB which sends a ‘’ packet supports receiving packets of unlimited length (earlier versions of GDB may reject overly long responses).

So it may be unclear to me exactly what the max length I can assume the stub can send until I get this packet, but after the stub receives that, it seems like any length goes.