This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

fwd: is LLDB a threat to GDB's success? #999


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]