From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13451 invoked by alias); 11 Jul 2008 12:40:07 -0000 Received: (qmail 13436 invoked by uid 22791); 11 Jul 2008 12:40:05 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Jul 2008 12:39:47 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6BCdh9e001565; Fri, 11 Jul 2008 08:39:43 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BCdhmn031373; Fri, 11 Jul 2008 08:39:43 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BCdf72028344; Fri, 11 Jul 2008 08:39:42 -0400 Message-ID: <48775496.7030203@gnu.org> Date: Fri, 11 Jul 2008 12:40:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Stan Shebs CC: Paul Koning , mark.kettenis@xs4all.nl, gdb@sourceware.org Subject: Re: Move GDB to C++ ? References: <487658F7.1090508@earthlink.net> <200807101901.m6AJ1UMQ007185@brahms.sibelius.xs4all.nl> <48766A88.1050402@earthlink.net> <18550.27427.430241.185251@gargle.gargle.HOWL> <48767395.7080905@gnu.org> <48767F78.8060806@earthlink.net> In-Reply-To: <48767F78.8060806@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; 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/msg00113.txt.bz2 Stan Shebs wrote: > Andrew Cagney wrote: >> The one question I would pose though, is bashing up the current GDB >> code base until it compiles with C++ a reasonable approach? Each >> time C++ has been suggested previously, that has been the proposed >> path forward, and each time it has not moved (I've even tried it my >> self). Perhaps, instead, we should approach this more on a component >> basis - stack, expr, type, proc, debug-info, ..., and convert each >> chunk in turn. And also make use of newer technology such as some of >> the technology that accompanied GOLD. This would suggest working in >> parallel, in a src/gdbxx (gdb++) directory; while this is of course >> longer and harder, I believe we'll see better results. > It's certainly an approach worth thinking about. Presumably the point > of working in a different directory is that the code might be expected > to be broken or nonportable for a period of time, but when that > happens you can run afoul of limited commitment levels, with people > only able to work on gdbxx when they don't have regular gdb tasks. If > everyone is forced into the same straitj^Wsource tree, dealing with > mid-transition brokenness is (usually :-) ) justifiable as part of the > job. I don't think it is reasonable to allow mod-transition brokenness, a code base, allowing for the usual fubars, should always build and pass its testsuite. > > An intermediate strategy might be to enable C++ in the trunk, then do > component replacement on branches. GCC has been having some success > with this; if a branch has something like rewritten symbol handling, > then regular merges will go pretty quickly, and people that don't want > to deal with symbol stuff can continue to work on trunk, knowing that > the branch code will come in when it's ready. > While I agree that this looks reasonable, I've reservations as to its apparent simplicity. Lets consider a moment GDB's vs GCC's architectures (the high level view): -> a compiler such as GCC has a pipeline architecture: each pass or filter implementing a specific algorithm and working in relative isolation; communication with the next pass being through simple (ok in theory :-) and tight interfaces. (There are exceptions such as the symbol table of course :-) For instance the front-end churns out GIMPLE, while the back-end continues to be fed RTL. A filter, the bulk of its code being an algorithm, can be re-implemented in C++ without modifying the interfaces it uses; and a structure can be changed to C++ while retaining compatible C/MACRO interfaces. -> a debugger such as gdb has an object-oriented architecture: there are a number of objects and relationships that reflect the system it is modelling. For instance, a stack has-a frame, a variable has-a location|type, and so on. When talking about changing GDB to C++ we're in fact talking about changing the implementation of each of these objects from a struct/union to a classes. I would consider that a far more invasive change. As a way of getting a better feel for this, lets consider two previous structural efforts: the unwinder and the architecture vector. I mention them as they are obvious first candidates for switching to C++. For each project the work was largely implemented incrementally in the mainline, consequently I would suggest, each project also took, not weeks or months, but years of effort. I suspect that, when we're talking about that sort of time scale for an incremental approach, it too runs the risk of limited commitment levels, and GDB finding itself in a C vs C++ no-where land. If only life were simple. -