[lldb-dev] Increasing support for other gdbservers

Zachary Turner zturner at google.com
Tue Mar 31 12:45:38 PDT 2015

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150331/c6e15264/attachment.html>

More information about the lldb-dev mailing list