<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">Feel free to submit a patch via Phabricator:</div><div class=""><br class=""></div><div class=""><a href="http://llvm.org/docs/Phabricator.html" class="">http://llvm.org/docs/Phabricator.html</a></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 2, 2016, at 9:21 PM, <a href="mailto:jw4242@gmail.com" class="">jw4242@gmail.com</a> via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class="">Hi all,<br class=""><br class=""></div>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.<br class=""></div>First off, the request message as defined at <a href="https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20target%20description%20read" class="">https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20target%20description%20read</a> 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:<br class=""><br class="">Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp<br class="">===================================================================<br class="">--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp (revision 288181)<br class="">+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp (working copy)<br class="">@@ -3342,7 +3342,7 @@<br class=""> case ('m'):<br class=""> if (str.length() > 1)<br class=""> output << &str[1];<br class="">- offset += size;<br class="">+ offset += str.length() - 1;<br class=""> break;<br class=""><br class=""> // unknown chunk<br class=""><br class=""></div>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.<br class=""><br class="">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.<br class=""></div></div>
_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<br class=""></div></blockquote></div><br class=""></div></body></html>