<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">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><br>Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp<br>===================================================================<br>--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp  (revision 288181)<br>+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.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::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>