[lldb-dev] qfThreadInfo/qsThreadInfo stub impl and max packet size
todd.fiala at gmail.com
Wed May 21 09:35:15 PDT 2014
> It looks like the stub can report its max packet size (well, looks like
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.
On Wed, May 21, 2014 at 9:27 AM, Todd Fiala <todd.fiala at gmail.com> wrote:
> Hi all,
> I'm about to implement qfThreadInfo/qsThreadInfo in the lldb-gdbserver
> (llgs) branch<https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64>.
> 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
> 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!
> Todd Fiala
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev