I think I get it. Objection withdrawn. On Wed, Apr 1, 2015 at 12:44 AM, Vince Harron <vi...@nethacker.com> wrote:
> This is a pretty cool feature for people who want to use lldb on windows > against gdbserver > > > On Tue, 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
