[lldb-dev] Increasing support for other gdbservers

[Colin Riley]

In my opinion, forcing python is worse. 

-----Original Message-----
From: "Ted Woodward" <ted.woodward at codeaurora.org>
Sent: ‎01/‎04/‎2015 17:42
To: "'Zachary Turner'" <zturner at google.com>; "'Vince Harron'" <vince at nethacker.com>
Cc: "lldb-dev at cs.uiuc.edu" <lldb-dev at cs.uiuc.edu>
Subject: Re: [lldb-dev] Increasing support for other gdbservers

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] 
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> 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] 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> 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> 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> 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> 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> 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> 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> wrote:
>>
>> > On Mar 31, 2015, at 3:35 AM, Aidan Dodds <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.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev


_______________________________________________
lldb-dev mailing list
lldb-dev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150401/d0c24b79/attachment.html>