> 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. On Wed, May 21, 2014 at 9:27 AM, Todd Fiala <[email protected]> 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 > 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 > > -- -Todd
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
