[lldb-dev] GDB Remote target descriptions

Greg Clayton via lldb-dev lldb-dev at lists.llvm.org
Thu Feb 23 16:09:58 PST 2017


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, jw4242 at gmail.com via lldb-dev <lldb-dev at 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170223/8f280787/attachment-0001.html>


More information about the lldb-dev mailing list