[lldb-dev] Increasing support for other gdbservers

Tue Mar 31 16:51:34 PDT 2015

I hate them too.  The amount of effort I spent removing them from Host
(even though there's still some there) is a testament to that.  But we
already have enough external dependencies on Windows as is (building Python
is already a huge chore, for example), and adding more to the mix is kind
of a blocking issue for me unless it's for really critical functionality.
Windows is in the unfortunate position of it being a pain to build most
open source libraries.  I don't want to make it even harder for people to
build LLDB on Windows just because of an xml library.

On Tue, Mar 31, 2015 at 4:36 PM Vince Harron <vince at nethacker.com> wrote:

> I hate ifdefs, especially the ones that we've added to the code. I would
> hate to see any others go in.  It's our plan for example to remove ifdefs
> that we have added .
> On Mar 31, 2015 4:28 PM, "Zachary Turner" <zturner at google.com> wrote:
>
>> As long as it's possible to build lldb without it I'm fine with whatever,
>> including downloading it separately, building it, and referencing it
>> externally.  But I don't want it to be a forced dependency.
>>
>> On Tue, Mar 31, 2015 at 4:19 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 listlldb-dev at cs.uiuc.eduhttp://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/20150331/193340a5/attachment.html>