[lldb-dev] qfThreadInfo/qsThreadInfo stub impl and max packet size

Todd Fiala todd.fiala at gmail.com
Tue Jun 10 08:24:39 PDT 2014

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 (

Any GDB which sends a ‘qSupported’ 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.

On Fri, May 30, 2014 at 8:51 AM, Todd Fiala <todd.fiala at gmail.com> wrote:

> 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.  */
> 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.
> On Thu, May 22, 2014 at 12:45 AM, Matthew Gardiner <mg11 at csr.com> wrote:
>> 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.
> --
> -Todd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140610/8f12a2ae/attachment.html>

More information about the lldb-dev mailing list