Because it communicates via the gdb remote protocol, and part of that involves xml across the wire.
On Wed, Apr 1, 2015 at 10:55 AM Shankar Easwaran <shank...@codeaurora.org> wrote: > May be this is a stupid question, are there reasons that lldb needs to > use xml format ? Can it switch to using YAML ? > > If not, may be having a XML parser like a YAML parser would be useful > inside of LLVM ?? > > Shankar Easwaran > > > On 4/1/2015 11:37 AM, Zachary Turner wrote: > > I think forcing python would be significantly worse actually. libxml2 is > already used in some places in the code, and is used by clang. So it's > already the accepted way to parse xml in LLVM projects, and even in LLDB > since it's already used in a couple places like what Jason mentioned > earlier. Plus, how would you do it in python? It seems like you'd have to > write hundreds of lines of ugly C code to set up callables and invoke them > with the right arguments, since we would be calling Python from C. And > then what happens when you don't want to link against python? You lose the > ability to use these seemingly unrelated features. > > On Wed, Apr 1, 2015 at 9:26 AM Ted Woodward <ted.woodw...@codeaurora.org> > <ted.woodw...@codeaurora.org> > wrote: > > > But which is a worse dependency when we want to parse gdbserver’s xml > files – add a dependency to libxml2, or force python? > > > > *From:* Zachary Turner [mailto:ztur...@google.com <ztur...@google.com>] > *Sent:* Wednesday, April 01, 2015 10:37 AM > *To:* Ted Woodward; Vince Harron > > > *Cc:* lldb-dev@cs.uiuc.edu > *Subject:* Re: [lldb-dev] Increasing support for other gdbservers > > > > You mean write python code to do xml parsing? I've done some work lately > to separate python from the rest of the codebase so that in theory it can > be replaced with an interpreter for a different language. Plus there's > already LLDB_DISABLE_PYTHON, and since the functionality that the xml > parser is needed for is not logically tied to the python interpreter, it > would be a shame to make them physically tied. > > Plus clang already uses libxml2 so it makes some sense to remain > consistent > > On Wed, Apr 1, 2015 at 8:29 AM Ted Woodward <ted.woodw...@codeaurora.org> > <ted.woodw...@codeaurora.org> > wrote: > > Since you mentioned Python…a thought came to mind. Python includes several > XML parsers. I use minidom to parse the TLB and Pagetable XML files that > the Hexagon Simulator produces and Hexagon GDB consumes. If we’re going to > require a dependency, why not one that we already use, and use a Python XML > parser? > > > > *From:* lldb-dev-boun...@cs.uiuc.edu [mailto:lldb-dev-boun...@cs.uiuc.edu > <lldb-dev-boun...@cs.uiuc.edu>] > *On Behalf Of *Vince Harron > *Sent:* Wednesday, April 01, 2015 2:46 AM > *To:* Zachary Turner > > > *Cc:* lldb-dev@cs.uiuc.edu > *Subject:* Re: [lldb-dev] Increasing support for other gdbservers > > > > I think I get it. Objection withdrawn. > > > > On Wed, Apr 1, 2015 at 12:44 AM, Vince Harron <vi...@nethacker.com> > <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> > <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> > <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> > <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> > <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> > <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> > <gclay...@apple.com> > > wrote: > > On Mar 31, 2015, at 3:35 AM, Aidan Dodds <ai...@codeplay.com> > <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-...@cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > _______________________________________________ > lldb-dev mailing > listlldb-...@cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing > listlldb-...@cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > _______________________________________________ > lldb-dev mailing > listlldb-...@cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > > > > _______________________________________________ > lldb-dev mailing > listlldb-...@cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by > the Linux Foundation > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
