Thanks for the link Abid, I'll have a look over that just now.

On 31/03/2015 11:47, Abid, Hafiz wrote:
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-boun...@cs.uiuc.edu [mailto:lldb-dev-boun...@cs.uiuc.edu]
On Behalf Of Aidan Dodds
Sent: 31 March 2015 11:35
To: Greg Clayton; Gary Benson
Cc: lldb-dev@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@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to