Re: Move GDB to C++ ?

[Michael Eager <eager@eagercon.com>]

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