[lldb-dev] Increasing support for other gdbservers

Wed Apr 1 11:05:21 PDT 2015

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 <shankare at 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.woodward at codeaurora.org> <ted.woodward at 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:zturner at google.com <zturner at google.com>]
> *Sent:* Wednesday, April 01, 2015 10:37 AM
> *To:* Ted Woodward; Vince Harron
>
>
> *Cc:* lldb-dev at 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.woodward at codeaurora.org> <ted.woodward at 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-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu <lldb-dev-bounces at cs.uiuc.edu>]
> *On Behalf Of *Vince Harron
> *Sent:* Wednesday, April 01, 2015 2:46 AM
> *To:* Zachary Turner
>
>
> *Cc:* lldb-dev at 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 <vince at nethacker.com> <vince at 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 <zturner at google.com> <zturner at 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 <jmolenda at apple.com> <jmolenda at 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 <vince at nethacker.com> <vince at 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" <colin at codeplay.com> <colin at 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 <zturner at google.com> <zturner at 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 <gclayton at apple.com> <gclayton at apple.com>
>
>  wrote:
>
>   On Mar 31, 2015, at 3:35 AM, Aidan Dodds <aidan at codeplay.com> <aidan at 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 at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
>
> _______________________________________________
> lldb-dev mailing listlldb-dev at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
> _______________________________________________
> lldb-dev mailing listlldb-dev at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
>
> _______________________________________________
> lldb-dev mailing listlldb-dev at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
>
>
>
>
>
> _______________________________________________
> lldb-dev mailing listlldb-dev at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150401/00d01eaa/attachment.html>