Re: Defending GCC considered futile

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 10 Feb 2015 00:30:03 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: esr@snark.thyrsus.com, stephen@xemacs.org, rms@gnu.org, 
>  emacs-devel@gnu.org
> 
> >> No, actually. Because the rest of the compiler wasn't intentionally
> >> made non-modular, it was possible for the LLDB team to re-use the
> >> code from the rest of the toolchain. LLDB doesn't need things like its
> >> own expression parsing and interpretation code because it can call
> >> into Clang/LLVM at will.
> > 
> > Parsing source-code expression is a very small part of what GDB does.
> > So this is a red herring.
> 
> It's also one of the most frustrating parts of GDB.

I guess we have very different GDB experiences and/or needs, if this
is a significant issue for you.  I almost never need to type complex
source-level expressions into a debugger.  The reason is simple:
almost every interesting value is already assigned to some variable,
so most expressions I type are simple references to variables.

If you want to explore a complex data structure, you should use Python
or Guile scripting anyway.

> If GDB were able to reuse a common parsing system, AST library, and
> completion engine, it would be both smaller and more robust.

I'm entirely not sure about "smaller" (code bloat imported from
another project is still bloat) and "more robust" (what, only GDB has
bugs in its parsing of C++ monstrosities?).  Anyway, at 5.8MB
_stripped_ size, not including Python and Guile shared libraries, the
"smaller" ship sailed long ago and won't be coming back, certainly
once GDB becomes a C++ program (which happens as we speak).