[lldb-dev] Increasing support for other gdbservers

[Abid, Hafiz]

Hi Aidan,
+1 for this work. Please note that I did some work on making lldb understand
the xml description that came from target. Although it was not committed but
it may prove helpful to you.

http://lists.cs.uiuc.edu/pipermail/lldb-dev/2013-October/002510.html

Regards,
Abid


> -----Original Message-----
> From: lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu]
> On Behalf Of Aidan Dodds
> Sent: 31 March 2015 11:35
> To: Greg Clayton; Gary Benson
> Cc: lldb-dev at cs.uiuc.edu
> Subject: Re: [lldb-dev] Increasing support for other gdbservers
> 
> 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 at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev