Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: dak@gnu.org,
>     emacs-devel@gnu.org
> Date: Thu, 12 Feb 2015 14:41:58 +0900
> 
> Eli Zaretskii writes:
> 
>  > And what about all the advanced features, like fork-following, JIT
>  > debugging, probe points, reverse execution, record and replay, etc.?
> 
> What in the world are you talking about? ;-)  At my level, I could care
> less.

Well, others don't.  And if LLDB never implements those, I don't think
we need to worry about it ever becoming a contender.

> Furthermore, those features aren't discoverable unless you are
> enough of a specialist to need them.  (I have to browse the gdb help
> almost every time I do any debugging, and this is the first I've heard
> of any of them.)  That is precisely the point here.

LLDB doesn't even _have_ a manual.  So much for its discoverability.

> (BTW, a technical point: I wonder how many of them are inspired by the
> need to get at information that gcc could provide, but doesn't?)

None, AFAIK.

>  > 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.
> 
> One man's feature is another man's YAGNI.  It's just personal
> preference.  A difference in terminology about "taste", that's all.

I don't think so.  Modern debuggers are expected to provide a certain
list of features.  E.g., without remote debugging, you cannot
conveniently debug embedded software, which is a large part of the
industry these days.  I guess that's why LLDB developers are working
hard on adding it.

> But you seem to missing the point of the "innovator's dilemma," which
> is that by deliberately targeting "downmarket", you can acquire the
> resources to develop quickly.

I don't think LLDB is targeting some "downmarket", they target the
same population of software developers as GDB.  You and Stefan and me
and all of us here.

> IOW, lldb *will* grow those advanced features.

I'm sure it will.  But if GDB's development continues at its present
pace, GDB will have additional features by that time.  And if GDB
stagnates and LLDB (or some other package) surpasses it, then I'll
agree that supporting a better contender becomes an important goal of
Emacs.

> What the LLVM devotees claim is that a better factored design for the
> whole toolchain allows extremely rapid development of features that
> the front-runner got only with great effort.

I have no doubt that being a later project, developed with newer
technology up front, is an advantage.  For starters, they don't need
to invent the features, they can (and do) just copycat them (ideas,
not code).  Which means they won't need all those years it took GDB to
get to the same point.  But it remains to be seen whether this
advantage is enough to unseat the champion in the observable future.
Personally, I think it takes more than just better factored design;
YMMV.

> I get the impression that GDB's needs are not so high on GCC's
> priority list.

Not sure why you get that impression.  Several GDB developers are
involved with GCC one way or another.  As one data point, the recent
addition to GDB of JIT compilation and injection of code was a product
of cooperation between GCC and GDB developers, as significant changes
were needed on both sides.

> Who's *rushing*?  There is *already* a patch, produced by interested
> volunteers.  The issue is when will the *foot-dragging* *stop*?

I'm saying that in this case there's no reason to be worried about the
foot-dragging.

> Think about it: Richard is trying to suppress free software
> distribution temporarily, in one special -- and especially important
> -- channel, because he's considering making that decision permanent.
> This is an issue of concern to all free software advocates.  We need
> to understand what is happening here, or we're mere fanboys.

There's any number of issues of concern to me at any given moment.
The important question is what to do about each and every concern in
each practical case.  I'm saying that in the case of LLDB support
doing nothing for a while is far from being a catastrophe.

You seem to see some ominous signs in what Richard wrote, but I don't.
Having known Richard for many years, having met him face to face
several times, and yes, having sparred with him on a few occasions, I
see no conclusions here to be drawn that go beyond this specific
issue.  And this specific issue is insignificant, because the need for
urgently incorporating LLDB support in Emacs is insignificant.

I feel quite differently in the issue with IDE functionalities that
need help from a compiler.  There, I wish the decision-making process
could have been much speedier, because we are already losing the IDE
battle.  (Of course, having no one but David Engster working on that
means that even if this roadblock were removed, we'd be unable to
catch up any time soon, maybe never.)

But our job of convincing Richard in the IDE case is not getting any
easier by starting a similar argument about LLDB.  On the contrary: it
is now harder, because Richard now has to invest some of his scarce
time in learning about LLDB.

IOW, we should choose very carefully which LLVM-related issues we want
to raise urgently, and which we don't.  Our cause of advancing Emacs
is certainly not served by supporting LLDB; by contrast, making Emacs
a modern IDE does serve that goal.  We should decide whether we want
to advance Emacs or waste time and energy on every tempest in every
teapot that has "LLVM" label stuck onto it.