[lldb-dev] Increasing support for other gdbservers

Wed Apr 1 00:46:10 PDT 2015

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/f63c6b3b/attachment.html>