gdbserver support is really something that fits well in the core of
gdb-remote as any development efforts
in supporting lldb-gdbserver and gdbserver will benefit each other,
which wouldn't be the case if gdbserver support
it pushed into a fringe python script.
I have had success building libxml2 from source on windows, which was my
main concern, and the process was relatively painless.
I don't think it will be too much of a hassle to build lldb with xml
support on windows, and likely free on unix systems.
Coupling python and gdbserver support sounds bad in the long term, so
I'll continue in favor of libxml2.
On 01/04/2015 18:19, Colin Riley wrote:
In my opinion, forcing python is worse.
------------------------------------------------------------------------
From: Ted Woodward <mailto:ted.woodw...@codeaurora.org>
Sent: 01/04/2015 17:42
To: 'Zachary Turner' <mailto:ztur...@google.com>; 'Vince Harron'
<mailto:vi...@nethacker.com>
Cc: lldb-dev@cs.uiuc.edu <mailto:lldb-dev@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: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 <mailto: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>
[mailto:lldb-dev-boun...@cs.uiuc.edu
<mailto: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 <mailto: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
<mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:gclay...@apple.com>> wrote:
>>
>> > On Mar 31, 2015, at 3:35 AM, Aidan Dodds
<ai...@codeplay.com <mailto: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 <mailto:lldb-dev@cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu <mailto: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
