Move GDB to C++ ?

[Andrew Cagney]

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.

-