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> 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> wrote: > >> >> > On Mar 31, 2015, at 3:35 AM, Aidan Dodds <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
