Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Eli Zaretskii <address@hidden>,
>     address@hidden
> Date: Wed, 11 Feb 2015 13:26:34 +0900
> 
>  > Eli Zaretskii <address@hidden> writes:
> 
>  > > When LLDB gets anywhere near GDB in functionality and usability,
>  > > let alone surpasses it, maybe then I might get interested.
> 
>  > > When LLDB gets anywhere near GDB in functionality and usability,
>  > > let alone surpasses it, maybe then I might get interested.
> 
> Your personal preference for GNU software is well-known.  But your
> preference doesn't help explain, let alone fight, the increasing
> popularity of LLVM

I really doubt that people prefer using a debugger that lacks basic
features, like remote debugging, even on GNU/Linux, more so on *BSD.
If they do, perhaps printf debugging is a contender as well?

And what about all the advanced features, like fork-following, JIT
debugging, probe points, reverse execution, record and replay, etc.?

IOW, the above is not just personal preference, it has at least some
basis in GDB features that LLDB lacks.  Until it grows them, it is not
a serious contender, and not just for personal preference reasons.

> But this difference indicates you should be careful to worry about the
> "innovator's dilemma", where an inferior product is "cheaper" (in some
> sense) and takes over the non-power-user market, and in that way gains
> the resources needed to improve rapidly and decisively.

If you mean that GDB development should not rest on its laurels, then
I very much agree.  I don't see any signs that it does, fortunately.

>  > > For now, it's a niche debugger, not unlike dbx.
> 
> Hardly.  True, from one point of view Mac OS X itself is a niche OS.
> But from the same point of view, Emacs itself is a niche app.

We are not talking about replacing Emacs with LLDB, so this analogy,
even if true, doesn't get us anywhere.  We are talking about whether
we should rush to include LLDB support in Emacs.  I say a niche
application of insufficient usability doesn't justify any rush.

>  > > Why should we care so much if LLDB support will land today, next
>  > > week, or next year?  We shouldn't burn so much energy on even
>  > > discussing it.
> 
> Perhaps not discussing the philosophy on this list.  But there are a
> *lot* of people using Emacs who are also using clang (essentially all
> Mac developers who use Emacs, for example).

Are you saying that GDB doesn't support clang on GNU/Linux well
enough, so LLDB is the only practical alternative for those who use
clang?  That's not my impression, and if it were so, I'd expect to
hear requests for LLDB support much earlier.

> LLVM support is important to some of us, and it *is* *free*
> software.

I didn't say we should never include its support.  I just said I see
no reason to consider waiting harmful in this case.  If someone needs
that yesterday, they can apply the patch submitted here, it's a simple
patch to a single Lisp file.

> My take is that Stefan is correct: Just Do It.

My take is that Stefan tries to make a point, and LLDB is just a
vehicle for that point.  _My_ point was that it's a shabby vehicle not
worthy of Stefan's point.  Just read the LLDB's "Status" page and
development list, and you will see what I mean.  We have created a
tempest in a teapot.

> IMHO, Richard should spend his energy on the hard, important problems,
> like whether gcc and gdb need a good ass-kicking to address these
> usability issues (from what you write, the issue may not exist for
> that combination), or whether gdb should try to compete with lldb even
> when the compiler isn't gcc.

AFAIK, Richard does precisely that.  Of course, you cannot expect more
than general guidance and questions from someone who is not intimately
involved in development of these projects.  The rest is up to the
development team.  At least in GDB case, development is to a large
degree driven by industry needs, since several core developers
actually get paid for their work.  That is why GDB sees so many new
features that support advanced CPU and systems development by major
vendors, like SysTaps, MPX, etc.