<div dir="ltr">Never got a response to this, did I miss it somehow?  If not, please see below.<div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername"><a href="mailto:jw4242@gmail.com">jw4242@gmail.com</a></b> <span dir="ltr"><<a href="mailto:jw4242@gmail.com">jw4242@gmail.com</a>></span><br>Date: Fri, Dec 2, 2016 at 9:21 PM<br>Subject: GDB Remote target descriptions<br>To: <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br><br><br><div dir="ltr"><div><div><div><div>Hi all,<br><br></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></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" target="_blank">https://sourceware.org/gdb/<wbr>onlinedocs/gdb/General-Query-<wbr>Packets.html#qXfer%20target%<wbr>20description%20read</a> is in the form qXfer:features:read:annex:<wbr>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><br>Index: source/Plugins/Process/gdb-<wbr>remote/<wbr>GDBRemoteCommunicationClient.<wbr>cpp<br>==============================<wbr>==============================<wbr>=======<br>--- source/Plugins/Process/gdb-<wbr>remote/<wbr>GDBRemoteCommunicationClient.<wbr>cpp  (revision 288181)<br>+++ source/Plugins/Process/gdb-<wbr>remote/<wbr>GDBRemoteCommunicationClient.<wbr>cpp  (working copy)<br>@@ -3342,7 +3342,7 @@<br>     case ('m'):<br>       if (str.length() > 1)<br>         output << &str[1];<br>-      offset += size;<br>+      offset += str.length() - 1;<br>       break;<br><br>     // unknown chunk<br><br></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::<wbr>GetGDBServerRegisterInfo only extracts a single <feature> node (the last one) from the target description.<br><br>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></div></div>
</div><br></div></div>