That first change looks ok. Feel free to submit a patch for the multiple <feature> request. Someone added this on linux a while back and was probably just working with their gdbserver that only sent a single packet. Shouldn't be too hard to fix.
Feel free to submit a patch via Phabricator: http://llvm.org/docs/Phabricator.html > On Dec 2, 2016, at 9:21 PM, jw4...@gmail.com via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > Hi all, > > I've been adding support for the qXfer:features:read:target.xml message for > our tools at $WORK and have run into a couple hiccups to puzzle over. > First off, the request message as defined at > https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20target%20description%20read > > <https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20target%20description%20read> > is in the form qXfer:features:read:annex:offset,size. When talking to GDB > it works to respond with a 'l' or 'm' message smaller than size, then GDB > proceeds to request the next chunk, and so on until the debug server says > there is no more data. I believe there is a bug in lldb's handling of this > message in that if the response is shorter than 'size' while also being > incomplete, lldb requests the next chunk with a giant offset. This patch > fixes the behavior: > > Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp > =================================================================== > --- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp > (revision 288181) > +++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp > (working copy) > @@ -3342,7 +3342,7 @@ > case ('m'): > if (str.length() > 1) > output << &str[1]; > - offset += size; > + offset += str.length() - 1; > break; > > // unknown chunk > > Secondly, it appears that lldb only processes a single <feature> element per > "file" when discovering the register descriptions, the workaround seems to be > to put each individual feature in an <xi:include> file or conglomerate > everything under a single feature in target.xml, but that has an unfortunate > side effect of not working right when talking to GDB. This one I didn't dig > too far into that code but it looks like > ProcessGDBRemote::GetGDBServerRegisterInfo only extracts a single <feature> > node (the last one) from the target description. > > In any case, these are both able to be worked around in my environment > without too much work but it would be nice to get at least that first item > fixed. > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
