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: Defending GCC considered futile Date: Tue, 10 Feb 2015 17:57:51 +0200 Message-ID: <8361b992tc.fsf@gnu.org> References: <20150207202952.1042BC00A6@snark.thyrsus.com> <87wq3rocqb.fsf@uwakimon.sk.tsukuba.ac.jp> <20150209172445.290dc20e@jabberwock.cb.piermont.com> <83mw4m8mi8.fsf@gnu.org> <54D9C18B.7060302@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1423583946 23650 80.91.229.3 (10 Feb 2015 15:59:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Feb 2015 15:59:06 +0000 (UTC) Cc: esr@snark.thyrsus.com, stephen@xemacs.org, emacs-devel@gnu.org, rms@gnu.org, perry@piermont.com To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 10 16:58: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 1YLDDG-0002Fb-R1 for ged-emacs-devel@m.gmane.org; Tue, 10 Feb 2015 16:58:58 +0100 Original-Received: from localhost ([::1]:40437 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLDDG-00038f-Dq for ged-emacs-devel@m.gmane.org; Tue, 10 Feb 2015 10:58:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57530) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLDD3-00038Y-S4 for emacs-devel@gnu.org; Tue, 10 Feb 2015 10:58:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLDD0-0003VK-Kb for emacs-devel@gnu.org; Tue, 10 Feb 2015 10:58:45 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:41352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLDD0-0003Uy-D0; Tue, 10 Feb 2015 10:58:42 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NJK00700C76Q300@a-mtaout20.012.net.il>; Tue, 10 Feb 2015 17:58:02 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJK007N9CCPQG00@a-mtaout20.012.net.il>; Tue, 10 Feb 2015 17:58:02 +0200 (IST) In-reply-to: <54D9C18B.7060302@dancol.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:182813 Archived-At: > Date: Tue, 10 Feb 2015 00:30:03 -0800 > From: Daniel Colascione > 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).