[lldb-dev] Increasing support for other gdbservers

[Aidan Dodds]

On 30/03/2015 18:38, Greg Clayton wrote:
 >
 > I know about the register numbering stuff and I would love to see 
support for the "$qXfer:features:" added to LLDB. The one thing this 
data doesn't contain is the register numbers for the ABI (DWARF register 
numbers (for debug info), compiler register numbers (for like 
.eh_frame)), but that info could be inferred from an ABI plugin that we 
could infer from the "osabi" of "GNU/Linux" in the target.xml:

 >
 > So please do submit patches that implement this and we will be happy 
to approve them.

I am currently prototyping $qXfer:features support in LLDB with an aim 
to upstream it. It will require an XML parser, so I wanted to have a 
discussion about adding one to LLDB.

I have been using TinyXML2 in my prototype, which is open sourced under 
the ZLib license. Is there any policy in LLDB for handling external 
library dependencies?
Would there be objections to TinyXML2 making its way into the LLDB code 
base as an external? Writing a new XML parser from scratch in LLDB isn't 
ideal.

I would still like to have a discussion about adding a plugin 
architecture to gdb-remote making it easier to handle packets outwith 
the LLDB based servers. The code in gdb-remote that sends and handles 
packets is scattered over one or two huge classes, it would be 
beneficial to start looking at breaking this up and modularizing it. At 
least for the packets which are not supported by lldb's own RSP producers.