This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Move GDB to C++ ?
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.
-