From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Contributing LLVM.org patches to gud.el Date: Thu, 12 Feb 2015 18:33:53 +0200 Message-ID: <83h9ur5bta.fsf@gnu.org> References: <87mw4rxkzv.fsf@fencepost.gnu.org> <87y4oavxcy.fsf@fencepost.gnu.org> <87d25juy8m.fsf@fencepost.gnu.org> <83iofa8lu2.fsf@gnu.org> <87wq3qrvjz.fsf@fencepost.gnu.org> <83386d92ox.fsf@gnu.org> <874mqtsoqy.fsf@fencepost.gnu.org> <87mw4lnked.fsf@uwakimon.sk.tsukuba.ac.jp> <83egpw78tp.fsf@gnu.org> <878ug3ofdl.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1423758863 3439 80.91.229.3 (12 Feb 2015 16:34:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Feb 2015 16:34:23 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 12 17:34:10 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YLwiP-0007ex-R9 for ged-emacs-devel@m.gmane.org; Thu, 12 Feb 2015 17:34:10 +0100 Original-Received: from localhost ([::1]:50996 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLwiP-0004An-4J for ged-emacs-devel@m.gmane.org; Thu, 12 Feb 2015 11:34:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLwiL-0004Ah-KS for emacs-devel@gnu.org; Thu, 12 Feb 2015 11:34:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLwiK-0004Qn-AB for emacs-devel@gnu.org; Thu, 12 Feb 2015 11:34:05 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:38362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLwiG-0004Pv-9O; Thu, 12 Feb 2015 11:34:00 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NJO00H002X0I000@mtaout24.012.net.il>; Thu, 12 Feb 2015 18:25:42 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJO00GJ12YT9210@mtaout24.012.net.il>; Thu, 12 Feb 2015 18:25:42 +0200 (IST) In-reply-to: <878ug3ofdl.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182962 Archived-At: > From: "Stephen J. Turnbull" > 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.