This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
fwd: is LLDB a threat to GDB's success? #999
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb at sourceware dot org
- Date: Fri, 13 Feb 2015 15:09:19 +0400
- Subject: fwd: is LLDB a threat to GDB's success? #999
- Authentication-results: sourceware.org; auth=none
Hello,
RMS started a private discussion yesterday with the GNU Maintainers
of the GDB project about LLDB, and he was asking whether LLDB is
a thread to GDB's success. I found Pedro Alves' answer very interesting.
BTW, Pedro is an extremely competent engineer working for RedHat
from Portugal, I believe.
Pedro allowed me to share his answer with you. Let's try not to
let it out of AdaCore, though. Although I don't think Pedro would
mind, until he releases his message in public, I don't want us to
be the one doing that...
Note the reference to Google and Android...
> I've been following their development list for a while, and from what
> I see, most of the serious contributions come from developers
> employed to work on it. Most of the current development comes out
> or either Apple or Google. AFAICS, Apple has a handful of contributors
> working on it (a couple used to be GDB developers a long time ago), and
> since recently, Google seems to have increased its investment in LLDB,
> from one developer to a whole team working on it full time. AFAICS,
> Google is driving the ports to GNU/Linux, Android and Windows too. I'd bet
> that their plans are to make LLDB the default debugger engine in whatever
> integrated development environment GUI they support to debug Android, but
> that's just a guess.
>
> As to why we're seeing growing investment from companies other than
> Apple, in addition to the reasons you've already mentioned, I'd
> also say:
>
> - Good C++ support.
>
> This stems from modularity. lldb reuses llvm/clang (the C/C++ compiler
> frontend) for expression evaluation/parsing, thus it has excellent
> C++ support. GDB has its own built in C++ expression parser, which
> is poor. GNU of course already has excellent parsers inside GCC/G++,
> but unfortunately, for years GCC did not really welcome modularity
> and reuse, and that now bites back, hard. As the C++ world shifts
> more and more to C++11/C++14, the more GDB is bitten by this,
> as it doesn't understand basic new features that have been added
> to the language. LLDB gains support for such new features for
> free whenever clang gains support for the same.
>
> - It's natural to invest in lldb if you've already investing in
> clang/llvm, given a lot of of components are reused in the projects.
> IOW, lldb becomes a thread to gdb as consequence of clang/llvm
> becoming a thread to gcc.
>
> - Like it or not: license.
Assigned to brobecker, prio D.
Copy to gnatgcc, pelt
Perhaps worth sharing with PTD as well? PELT?
--
Joel