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

[Shahbaz Youssefi <shabbyx at gmail dot com>]

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
>