This immediate use in this thread would be in the gdb remote support, which certainly should be compiled on Windows so you can use lldb as a remote debugger there.
Jim > On Mar 31, 2015, at 5:57 PM, Zachary Turner <ztur...@google.com> wrote: > > I think uses of it would only need to be guarded if we plan to use it in > generic code. So yea, if all the code that uses it goes into a file that > isn't compiled on windows anyway, then the problem becomes very simple > On Tue, Mar 31, 2015 at 5:41 PM Jason Molenda <jmole...@apple.com> wrote: > fwiw on Mac OS X we use libxml2 over in > Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.cpp. That plugin's > initialization is #ifdef __APPLE__ over in SystemInitializerFull.cpp; we > don't have ifdef guard around the use of libxml2 in SymbolVendorMacOSX itself. > > > > On Mar 31, 2015, at 4:18 PM, Vince Harron <vi...@nethacker.com> wrote: > > > > I really don't want LLDB to embed a copy of libxml2. I think we should > > build it externally and reference it from LLDB. Systems with package > > managers can get this trivially. Windows can download and build all > > dependencies with one script. > > > > On Mar 31, 2015 2:10 PM, "Colin Riley" <co...@codeplay.com> wrote: > > 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> 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 > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
