<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">May be this is a stupid question, are
      there reasons that lldb needs to use xml format ? Can it switch to
      using YAML ?<br>
      <br>
      If not, may be having a XML parser like a YAML parser would be
      useful inside of LLVM ??<br>
      <br>
      Shankar Easwaran<br>
      <br>
      On 4/1/2015 11:37 AM, Zachary Turner wrote:<br>
    </div>
    <blockquote
cite="mid:CAAErz9iEfCc_TWNLzNuG3jL9rKK964kDa2jF3RjBbMcjtF_zcQ@mail.gmail.com"
      type="cite">
      <pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:ted.woodward@codeaurora.org"><ted.woodward@codeaurora.org></a>
wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">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 [<a class="moz-txt-link-freetext" href="mailto:zturner@google.com">mailto:zturner@google.com</a>]
*Sent:* Wednesday, April 01, 2015 10:37 AM
*To:* Ted Woodward; Vince Harron


*Cc:* <a class="moz-txt-link-abbreviated" href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a>
*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 <a class="moz-txt-link-rfc2396E" href="mailto:ted.woodward@codeaurora.org"><ted.woodward@codeaurora.org></a>
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:* <a class="moz-txt-link-abbreviated" href="mailto:lldb-dev-bounces@cs.uiuc.edu">lldb-dev-bounces@cs.uiuc.edu</a> [<a class="moz-txt-link-freetext" href="mailto:lldb-dev-bounces@cs.uiuc.edu">mailto:lldb-dev-bounces@cs.uiuc.edu</a>]
*On Behalf Of *Vince Harron
*Sent:* Wednesday, April 01, 2015 2:46 AM
*To:* Zachary Turner


*Cc:* <a class="moz-txt-link-abbreviated" href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a>
*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 <a class="moz-txt-link-rfc2396E" href="mailto:vince@nethacker.com"><vince@nethacker.com></a> 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 <a class="moz-txt-link-rfc2396E" href="mailto:zturner@google.com"><zturner@google.com></a>
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 <a class="moz-txt-link-rfc2396E" href="mailto:jmolenda@apple.com"><jmolenda@apple.com></a> 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.


</pre>
        <blockquote type="cite">
          <pre wrap="">On Mar 31, 2015, at 4:18 PM, Vince Harron <a class="moz-txt-link-rfc2396E" href="mailto:vince@nethacker.com"><vince@nethacker.com></a> wrote:

I really don't want LLDB to embed a copy of libxml2.  I think we should
</pre>
        </blockquote>
        <pre wrap="">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.
</pre>
        <blockquote type="cite">
          <pre wrap="">
On Mar 31, 2015 2:10 PM, "Colin Riley" <a class="moz-txt-link-rfc2396E" href="mailto:colin@codeplay.com"><colin@codeplay.com></a> wrote:
I noticed that use in cmake also. FWIW, my primary LLDB platform is
</pre>
        </blockquote>
        <pre wrap="">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.
</pre>
        <blockquote type="cite">
          <pre wrap="">
Colin

On 31/03/2015 20:45, Zachary Turner wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">There's already some stuff in the CMake to try to find libxml, but it's
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="">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.
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">
On Tue, Mar 31, 2015 at 10:02 AM Zachary Turner <a class="moz-txt-link-rfc2396E" href="mailto:zturner@google.com"><zturner@google.com></a>
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="">wrote:
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">A good rule of thumb for anything is that "Windows doesn't have it" and
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="">that holds true for libxml2 as well.  It appears that libxml2 does support
Windows though (<a class="moz-txt-link-freetext" href="http://xmlsoft.org/downloads.html">http://xmlsoft.org/downloads.html</a>), 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.
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">
On Tue, Mar 31, 2015 at 9:47 AM Greg Clayton <a class="moz-txt-link-rfc2396E" href="mailto:gclayton@apple.com"><gclayton@apple.com></a>
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="">wrote:
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">
</pre>
            <blockquote type="cite">
              <pre wrap="">On Mar 31, 2015, at 3:35 AM, Aidan Dodds <a class="moz-txt-link-rfc2396E" href="mailto:aidan@codeplay.com"><aidan@codeplay.com></a> wrote:

On 30/03/2015 18:38, Greg Clayton wrote:
</pre>
              <blockquote type="cite">
                <pre wrap="">
I know about the register numbering stuff and I would love to see
</pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">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:
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">
</pre>
              <blockquote type="cite">
                <pre wrap="">
So please do submit patches that implement this and we will be
</pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">happy to approve them.
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">
I am currently prototyping $qXfer:features support in LLDB with an
</pre>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">aim to upstream it. It will require an XML parser, so I wanted to have a
discussion about adding one to LLDB.
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">
Most unix variants have libxml2 that is available. I am not sure on
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="">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).
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">
</pre>
            <blockquote type="cite">
              <pre wrap="">I have been using TinyXML2 in my prototype, which is open sourced
</pre>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">under the ZLib license. Is there any policy in LLDB for handling external
library dependencies?
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">Would there be objections to TinyXML2 making its way into the LLDB
</pre>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">code base as an external? Writing a new XML parser from scratch in LLDB
isn't ideal.
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">
It would be great to stick with stuff that everyone has installed and
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="">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.
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">
I would still like to have a discussion about adding a plugin
</pre>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">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.
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">
I say just build all and any support it into
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="">GDBRemoteCommunicationClient and GDBRemoteCommunicationServer. I don't see
the need to break it up.
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">
Greg Clayton


_______________________________________________
lldb-dev mailing list

<a class="moz-txt-link-abbreviated" href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a>
</pre>
          </blockquote>
          <pre wrap="">

_______________________________________________
lldb-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a>

_______________________________________________
lldb-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a>
</pre>
        </blockquote>
        <pre wrap="">

_______________________________________________
lldb-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a>






</pre>
      </blockquote>
      <pre wrap="">
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
lldb-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation</pre>
  </body>
</html>