From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31673 invoked by alias); 4 Apr 2012 20:48:00 -0000 Received: (qmail 31662 invoked by uid 22791); 4 Apr 2012 20:47:59 -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, 04 Apr 2012 20:47:41 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q34Klfxl006179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 4 Apr 2012 16:47:41 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q34KldOK006712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 Apr 2012 16:47:40 -0400 From: Tom Tromey To: Jan Kratochvil Cc: gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? References: <20120330161403.GA17891@host2.jankratochvil.net> Date: Wed, 04 Apr 2012 20:48:00 -0000 In-Reply-To: <20120330161403.GA17891@host2.jankratochvil.net> (Jan Kratochvil's message of "Fri, 30 Mar 2012 18:14:03 +0200") Message-ID: <87aa2rjkb8.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/msg00044.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Jan> To C++ or not to C++? Unfortunately the discussion was here Jan> already before and I am aware several contributors are not welcome Jan> with it, I think it does not need to affect readability of C code Jan> much, there is not enough workforce to rewrite all the GDB code Jan> into C++ style anyway. Still C++ would help a lot, some kinds of Jan> bugs are not solvable without it. I'm strongly in favor of C++ for reasons I'll lay out below. I agree with all your points. But first: Jan> I am open to suggestions of static analysis tools to use instead Jan> but at least according to the experience of Tom Tromey it is not so Jan> easy / safe / foolproof to use, IIUC his words. Yes, when David Malcolm wrote his Python plugin for GCC, I decided to see whether we could get the equivalent maintainability benefits of C++ by writing in C and then using static analysis to fill the gaps. To this end I wrote a few small plugins to do analysis on gdb. My conclusion is that it is just too much work to iron out all the false reports from the plugins. Partly this is due to gdb's unusual structure, in particular the use of cleanups, which mean that any analysis requires a lot of hair to ensure its correctness. Last June (so long ago already?) I sent a draft of a proposal to migrate gdb to C++ to the Archer list (the thread is http://sourceware.org/ml/archer/2011-q2/threads.html#00028; the followups are worth reading, but I've incorporated most of it into the below). After some discussion and edits, I chickened out of sending it. Here it is now: At the GCC Summit, I once again brought up the perennial idea of moving GDB to be implemented in C++. There, we agreed that as a follow-on to that discussion that I would raise the topic among the GDB maintainers, and in particular present my migration plan. My goal for moving to C++ is to make GDB more robust. My view is that GDB is already written in a poor cousin of C++. Nearly every feature that people hate about C++ is already in use in GDB. This list is not exhaustive, just informational: * Subclasses. See general_symbol_info. struct value and struct type would be improved by them. * Virtual functions. gdbarch, languages, and values all use these. * Overloaded functions. Anywhere you see a _1 suffix. * Templates. Both observers and VEC are templates. * Exceptions. Used ubiquitously. * RAII. Cleanups, but they are dynamic and more error-prone. * Even global constructors -- init.c. In most cases, GDB's implementation of these features is inferior to that of the C++ compiler. Its exceptions are slower. Its data structures have less type-safety. Both cleanups and TRY_CATCH are error-prone in practice. GDB is needlessly verbose due to using callback-based container iteration and callback-based exception handling. We have run into various situations where errors could have been prevented through the use of better type-safety -- e.g., wrapper classes for the CU- versus section-offset case. I think a gradual move to C++ would enable us to fix these problems. I believe it would also provide us a way to fix the ongoing reference counting bugs in the Python layer. I don't believe we should convert all of GDB to C++. In particular I think gdbserver should remain as pure C, and likewise any code shared between gdbserver and gdb should be kept as such. I also think we should be reasonably conservative in our choices of C++ constructs to use. I think this should be a separate thread; I will be happy to write a draft proposal for this as well. We can also see what the GCC community comes up with here -- our needs are a little different, but probably not drastically so. My concrete transition proposal is: 1. Modify GDB so it can be compiled with -Wc++-compat. This would be the first patch series. There is already an archer branch for this. 2. Then, change GDB to compile with a C++ compiler (-Wc++-compat is not complete). This would be the second patch series. 3. Require C++. 4. Change selected modules to use C++ rather than C. I don't think a wholesale change makes sense, but some areas would benefit. My first target would be to change the exception handling system to use C++ exceptions. This would enable us to begin using RAII in some areas, which would help robustness. My concrete plan here is: * Use the GCC cleanup-checking plugin I already wrote to detect cleanup-aware functions. * Modify these functions, using a script, to add an RAII-using object to manage the local cleanups. This is important so that we run cleanups at the correct time during stack unwinding. * Change throw_exception to use 'throw' and all TRY_EXCEPT instances to try...catch. * Finally, convert functions to static RAII usage when appropriate; this will be an ongoing transition. I think our second target will be sorting out Python reference counting, so we can avoid the many problems we have had there. Tom