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.
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
