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

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

[Joel Brobecker]

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

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

[Pedro Alves]

I should perhaps add that the opinion expressed was mine alone
and does not represent the opinions of my past, present, and
future employer(s).  :-)

Pedro alves wrote:

>> - 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.

This of course was missing lots of context, but, I'll add that
GDB's not actually sitting and waiting here.  There's a project
going on already that is exactly about reusing GCC/G++ in GDB.

The first step has landed in GDB 7.9 already, in the form of
the "compile" command, which compiles, injects, and executes
a C expression, making use of GCC through a plugin.  See:

  https://sourceware.org/gdb/current/onlinedocs/gdb/Compiling-and-Injecting-Code.html

We're discussing next steps for the project here:

 https://sourceware.org/ml/gdb/2015-02/msg00019.html

Everyone's more than welcome to join!

Thanks,
Pedro Alves

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

[Shahbaz Youssefi]

If you don't mind some random guy chipping in:

First off, I hadn't heard of lldb until just now, but I'm actually
happy about it. Without competition, improvement is slow.

That said, I would like to ask the gdb developers to please not be
arrogant like developers of some other GNU software are. It is easy to
become this way when your tool is ubiquitous, and that's also why
people would stop using it as soon as a decent alternative surfaces. I
am sure you have seen this in ways much deeper than me, but here are
at least some basic examples from a user's point of view. automake
maintainers didn't want to introduce silent rules, but when people
loved Linux's make system, they added it. gcc maintainers didn't want
to add color support to output until llvm came, did that and people
loved it. You can see more influences from llvm on gcc as well which
I'm sure at some point in the past had been suggested to the
maintainers and had fallen to deaf ears.

So if you do care about gdb's survival, please pay attention to what
users of gdb want or what they complain about. While gdb was the only
debugging tool, you could just tell them off, have them suffer and
what not because that's how you thought gdb should work. If lldb
addresses those usability problems, you can't then ask people not to
switch.

On Fri, Feb 13, 2015 at 1:35 PM, Pedro Alves <palves@redhat.com> wrote:
> I should perhaps add that the opinion expressed was mine alone
> and does not represent the opinions of my past, present, and
> future employer(s).  :-)
>
> Pedro alves wrote:
>
>>> - 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.
>
> This of course was missing lots of context, but, I'll add that
> GDB's not actually sitting and waiting here.  There's a project
> going on already that is exactly about reusing GCC/G++ in GDB.
>
> The first step has landed in GDB 7.9 already, in the form of
> the "compile" command, which compiles, injects, and executes
> a C expression, making use of GCC through a plugin.  See:
>
>   https://sourceware.org/gdb/current/onlinedocs/gdb/Compiling-and-Injecting-Code.html
>
> We're discussing next steps for the project here:
>
>  https://sourceware.org/ml/gdb/2015-02/msg00019.html
>
> Everyone's more than welcome to join!
>
> Thanks,
> Pedro Alves
>