From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18861 invoked by alias); 18 May 2012 18:36:41 -0000 Received: (qmail 18652 invoked by uid 22791); 18 May 2012 18:36:40 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 May 2012 18:36:22 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4IIaLd9003270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 May 2012 14:36:21 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4IIaJPE030036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 18 May 2012 14:36:20 -0400 From: Tom Tromey To: John Gilmore Cc: Jan Kratochvil , Pedro Alves , gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F832D5B.9030308@redhat.com> <20120409190519.GA524@host2.jankratochvil.net> <4F833D29.4050102@redhat.com> <20120416065456.GA30097@host2.jankratochvil.net> <4F8ECB72.70708@redhat.com> <20120418151553.GA16768@host2.jankratochvil.net> <4F8EDD7B.2010602@redhat.com> <20120418155354.GA17912@host2.jankratochvil.net> <201204181748.q3IHm1cF002815@new.toad.com> <87pqb4q2on.fsf@fleche.redhat.com> <201204182309.q3IN9FcF019607@new.toad.com> Date: Fri, 18 May 2012 18:36:00 -0000 In-Reply-To: <201204182309.q3IN9FcF019607@new.toad.com> (John Gilmore's message of "Wed, 18 Apr 2012 16:09:15 -0700") Message-ID: <87k409gwv0.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00087.txt.bz2 I'm sorry this reply has taken so long. I didn't mean to let this drop off -- I think a sort of generic problem in gdb is over-use of the pocket veto -- but I've been away, sick, etc. John> I wish you'd retract the terms you used for my ideas (bogus, straw John> men, weird, etc). Ok, I retract those adjectives. John> All of my messages on this topic have been serious. Ok. John> Re (1), I could say that C is already quite close to C++, since GDB John> is written in C and you say GDB is already quite close to C++. Your statement here is a generic one, disconnected from any particular fact about GDB -- a problem that pervades your response. It could apply to any C program. But, my argument is about GDB in particular; and cannot be transferred to any C program as-is. You can see this most easily if you re-read the bullet list in http://sourceware.org/ml/gdb/2012-04/msg00044.html John> Large modular programs use modularity techniques. Some of those John> are also used by C++. Again, nice observation, but what does it John> have to do with converting GDB to C++? The list isn't only about modularity techniques. For instance, few pure C programs use exceptions -- it is a rarity. But, GDB uses them ubiquitously, and we know that their current expression in GDB causes bugs; bugs which are easily avoided in C++. John> * Just because it's written in C++ doesn't make it John> maintainable. Nobody claims this. John> See, GDB was a large, complex program even in 1991. And the average John> guy who makes a patch to a large program, makes it solve his John> particular problem but usually breaks six other things in the process. There are lots of kinds of patches. And, there is no silver bullet. I don't think C++ will magically solve everything, but it will remove some subset of bugs and make some planned changes easier. And, this proposal can't really be disconnected from gdb as it currently is. For example, look at the Python layer. Despite patch review and our knowledge of the issues, we still have error-checking and reference-counting bugs in the code. You can go through the list archives and find them. This is an example of the sort of problem that we could define out of existence. Cleanups are another good example. I've personally fixed any number of small memory leaks, cleanup misuses, etc -- but more remain. RAII is simply a better programming technique. The frame cache is yet another example. There's a bunch of bugs relating to keeping frame_info objects across invalidations of the frame cache. These are very tricky to see via patch review. This is also a hard problem to fix systematically in C. In C++ you can do it pretty easily though. John> So if there are tons of contributed patches in gdb-patches, for John> "purely avoidable problems" that are in the shipping version of GDB, John> then they probably result from prior acts of the GDB maintainers, who John> inappropriately applied patches from people who don't understand the John> structure of GDB. Patch review will never be perfect. It is typical for even very experienced gdb hackers to miss things during review. My view is that we should use multiple tools to eliminate bugs at their source -- and that the cheapest way, by far, is to define them away by letting the compiler do the heavy work. Tom> There are some threads on gdb-patches recently about lazy CU expansion John> Also, I'm not sure what "lazy CU expansion" is. See http://sourceware.org/ml/gdb-patches/2012-04/msg00154.html Basically it is an attempt to scale gdb's symbol reading performance. Even this may not be sufficient, given the size of programs we're seeing now. I'll reply to the rest of this in a separate note. It is really a different thread. Tom