From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23333 invoked by alias); 18 Apr 2012 19:07:56 -0000 Received: (qmail 23322 invoked by uid 22791); 18 Apr 2012 19:07:55 -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; Wed, 18 Apr 2012 19:07:22 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3IJ7LeK029846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2012 15:07:21 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3IJ7K0B004265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 Apr 2012 15:07:21 -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> Date: Wed, 18 Apr 2012 19:07:00 -0000 In-Reply-To: <201204181748.q3IHm1cF002815@new.toad.com> (John Gilmore's message of "Wed, 18 Apr 2012 10:48:01 -0700") Message-ID: <87pqb4q2on.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-04/txt/msg00133.txt.bz2 >>>>> "John" == John Gilmore writes: I didn't reply to some of your earlier notes since they were just clearly bogus -- straw men, weird characterizations and generalizations bordering on the insulting, etc -- but a couple people asked me privately about these. So I guess I'll respond to this one after all. John> If you are arguing that our test suite does not exercise gdb well John> enough to detect simple coding bugs, that argues for spending more John> time on the test suite, not rewriting working code into C++. It doesn't really work this way. Test suites and reviews are good tools but of course they are imperfect. You can grind away to the point of diminishing returns, but the point is not perfection but rather to accelerate development at a reasonable cost, not an unreasonable one. The thrust of the argument that I posted, which you have basically ignored in all its particulars, is (1) gdb is already quite close to C++ in practice, albeit a badly broken dialect, and (2) the constructs gdb implements are in fact difficult to use correctly in practice. The evidence for #2 is all in the gdb-patches archives, mostly along the lines of bug fixes for various purely avoidable problems. In programming there are usually two sets of problems to solve. First, there are the domain problems. Then, there are the problems of expression; these are largely self-induced problems which tend to get worse as your program ages. My view is that gdb is hampered, though not crippled, by the latter class. John> BTW, someone argued that C++ would improve memory allocation for John> e.g. symtabs. We used to allocate those in our own region-based memory John> allocator, so thousands of symbols could be freed at once when new John> symbol files are loaded. Do we not do that any more? We do. Full symbols are already reasonably C++y, what with the ops vector. There are some threads on gdb-patches recently about lazy CU expansion where, reading between the lines (as one must usually do on gdb-patches, since bringing up C++ just makes for a distracting argument), you can see how C++ would help. Namely, we'd like to change symbol so that it can optionally point to the corresponding psymbol, but that means wackiness in the accessors; a problem easily and cleanly solved by subclassing and virtual methods. Note that we already have one subclass of symbols, and there's some indication we'll need more regardless. Anyway, this is a case where there would be a clarity benefit without any loss of space (in fact it would be in service of space and performance gains). Partial symbols are a different matter. I think they are a bad candidate for any sort of change, on the grounds that they are both reasonably isolated and also extremely space critical. Tom