I noticed that use in cmake also. FWIW, my primary LLDB platform is
Windows, which is why we were using TinyXML2 for ease of prototyping. If
libxml2 works on all the targets we will use it - I do worry about the
usual issues you get with windows prebuilts. So source may still be
required. We'll look into it.
Colin
On 31/03/2015 20:45, Zachary Turner wrote:
There's already some stuff in the CMake to try to find libxml, but
it's behind a Darwin specific branch in the CMake. So I think what
would need to happen is that we move this into a platform agnostic
codepath, and then set a define like LLDB_HAVE_LIBXML2 in the code to
a value that indicates whether it is present (search clang
for CLANG_HAVE_LIBXML in *.* to see how this is done). Then, in the
code, we would need to put xml code behind a check for this define.
On Tue, Mar 31, 2015 at 10:02 AM Zachary Turner <ztur...@google.com
<mailto:ztur...@google.com>> wrote:
A good rule of thumb for anything is that "Windows doesn't have
it" and that holds true for libxml2 as well. It appears that
libxml2 does support Windows though
(http://xmlsoft.org/downloads.html), it just isn't something
that's there by default. It would be nice if everyone were using
the same thing, could we clone this repo in our own repo and then
just build it ourselves as part of the build process. The license
looks very permissive, but IANAL.
On Tue, Mar 31, 2015 at 9:47 AM Greg Clayton <gclay...@apple.com
<mailto:gclay...@apple.com>> wrote:
> On Mar 31, 2015, at 3:35 AM, Aidan Dodds <ai...@codeplay.com
<mailto:ai...@codeplay.com>> wrote:
>
> 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.
Most unix variants have libxml2 that is available. I am not
sure on windows though. I have CC'ed Zachary to get some input
on windows XML (in case LLVM doesn't already have some support
for this).
> 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.
It would be great to stick with stuff that everyone has
installed and hopefully that is libxml2. Windows is the
biggest question. I am also not sure if llvm or clang has any
XML support, but we should first look to see if llvm has XML
support and if not, then look for alternatives. We definitely
do not want to write our own.
>
> 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.
I say just build all and any support it into
GDBRemoteCommunicationClient and GDBRemoteCommunicationServer.
I don't see the need to break it up.
Greg Clayton
_______________________________________________
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
