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: Wed, 11 Feb 2015 17:43:14 +0200 Message-ID: <83egpw78tp.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1423669507 2899 80.91.229.3 (11 Feb 2015 15:45:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Feb 2015 15:45:07 +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 Wed Feb 11 16:44:59 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 1YLZTD-0004uy-TN for ged-emacs-devel@m.gmane.org; Wed, 11 Feb 2015 16:44:56 +0100 Original-Received: from localhost ([::1]:45598 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLZTD-0000OG-Df for ged-emacs-devel@m.gmane.org; Wed, 11 Feb 2015 10:44:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48644) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLZT5-0000GG-Me for emacs-devel@gnu.org; Wed, 11 Feb 2015 10:44:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLZT4-0004P3-Az for emacs-devel@gnu.org; Wed, 11 Feb 2015 10:44:47 -0500 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:49092) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLZT0-0004OE-DJ; Wed, 11 Feb 2015 10:44:42 -0500 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NJM00B005XLCW00@mtaout27.012.net.il>; Wed, 11 Feb 2015 17:37:22 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJM0063C62AG150@mtaout27.012.net.il>; Wed, 11 Feb 2015 17:37:22 +0200 (IST) In-reply-to: <87mw4lnked.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.183 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:182894 Archived-At: > From: "Stephen J. Turnbull" > Cc: Eli Zaretskii , > emacs-devel@gnu.org > Date: Wed, 11 Feb 2015 13:26:34 +0900 > > > Eli Zaretskii 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.