Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb@sourceware.org
Subject: fwd: is LLDB a threat to GDB's success? #999
Date: Fri, 13 Feb 2015 11:09:00 -0000	[thread overview]
Message-ID: <20150213110919.GN5709@adacore.com> (raw)

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


             reply	other threads:[~2015-02-13 11:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-13 11:09 Joel Brobecker [this message]
2015-02-13 12:35 ` Pedro Alves
2015-02-13 15:51   ` Shahbaz Youssefi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150213110919.GN5709@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox