From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6739 invoked by alias); 19 Jul 2008 18:25:48 -0000 Received: (qmail 6729 invoked by uid 22791); 19 Jul 2008 18:25:48 -0000 X-Spam-Check-By: sourceware.org Received: from shell4.bayarea.net (HELO shell4.bayarea.net) (209.128.82.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 19 Jul 2008 18:25:28 +0000 Received: (qmail 30047 invoked from network); 19 Jul 2008 11:25:26 -0700 Received: from 209-128-106-254.bayarea.net (HELO redwood.eagercon.com) (209.128.106.254) by shell4.bayarea.net with SMTP; 19 Jul 2008 11:25:25 -0700 Message-ID: <48823195.6000802@eagercon.com> Date: Sun, 20 Jul 2008 14:36:00 -0000 From: Michael Eager User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Stan Shebs CC: gdb@sourceware.org Subject: Re: Move GDB to C++ ? References: <487658F7.1090508@earthlink.net> In-Reply-To: <487658F7.1090508@earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2008-07/txt/msg00227.txt.bz2 Stan Shebs wrote: > As many know, there is a project afoot to investigate the recoding of > GCC from C into C++. I believe the C++ idea was briefly touched on for > GDB at the summit, although I don't remember much discussion. Anyway, > this would be a good time to start thinking about it, and if people are > generally in favor of the idea, we can start small by tweaking the > sources to be C++-friendly, avoiding keywords and so forth; GCC has a > new warning flag -Wcxx-compat that can help. > > For my part, I think we should do it. GDB has quite a bit of object-like > structure internally, and while in the past it was taking a bit of a > chance to rely on the availability and reliability of C++ compilers, > those concerns are now generally outdated; I'm not sure any of the > potential problem hosts are even supported any longer. I'll offer my two cents worth. Last year, I suggested porting portions of GDB to C++. This had been previously discussed, but was basically shouted down for a variety of reasons. I'm glad to see it being discussed again. Some long time ago, I converted Sun Microsystem's DBX initially to the C-compatible subset of C++, then extended it with classes and a few other C++ features in areas where the feature matched the logic, such as handling symbol tables or object file structures. No templates, no STL, retained previous exception handling; essentially, the conversion was to "C with Classes". This led to a significant improvement in maintainability and reduced bug count. Many parts of GDB (I think of gdbarch) appear to be coded to implement objects, classes, and members, exactly if it had been generated from C++ objects. It seems to me that these would convert to "C with Classes" easily, with improvement in both performance and clarity. Despite having served on the C++ Standards Committee some time ago, and having taught many C++ classes, I am not very fond of C++ for many of the reasons that others have mentioned. Templates and the template libraries can generate error messages which range the entire spectrum from obscure to incomprehensible. Debugging support for several features is spotty. The remedy for the latter is to improve GDB support for these features. For the former, avoid features which are problematic. The problems that I see in converting GDB to C++ are that it is huge (600K+ lines) and not really modular. The source tree is very shallow, with architecture-dependent and -independent code mixed in with core gdb functionality, user interface, host support and other stuff (some of which may not be functional, like gdblib). This makes any wholesale conversion of GDB somewhat daunting. Here is the approach I would take to converting GDB to C++: 1) Build existing GDB with C++ and correct any C/C++ incompatibilities. 2) Identify functional modules (e.g., cli, target support, gdbarch) 3) For each functional module: 3a) Create subdirectory for functional module 3b) Build library for functional module and link with GDB 3c) Convert from C-style to C++-style interface (if necessary) 3d) Document module functionality It seems to me that this could be done incrementally with limited impact on existing development. I also think that this could have many other beneficial effects on GDB, including making it easier to understand and modify, making it less brittle, and perhaps even working toward a fully functional gdblib. I think that making GDB more modular is the key -- this allows conversion to C++ to be done in smaller bites, rather than wholesale. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077