Re: Will therefore GDB utilize C++ or not?

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> To C++ or not to C++?  Unfortunately the discussion was here
Jan> already before and I am aware several contributors are not welcome
Jan> with it, I think it does not need to affect readability of C code
Jan> much, there is not enough workforce to rewrite all the GDB code
Jan> into C++ style anyway.  Still C++ would help a lot, some kinds of
Jan> bugs are not solvable without it.

I'm strongly in favor of C++ for reasons I'll lay out below.

I agree with all your points.

But first:

Jan> I am open to suggestions of static analysis tools to use instead
Jan> but at least according to the experience of Tom Tromey it is not so
Jan> easy / safe / foolproof to use, IIUC his words.

Yes, when David Malcolm wrote his Python plugin for GCC, I decided to
see whether we could get the equivalent maintainability benefits of C++
by writing in C and then using static analysis to fill the gaps.

To this end I wrote a few small plugins to do analysis on gdb.

My conclusion is that it is just too much work to iron out all the false
reports from the plugins.  Partly this is due to gdb's unusual
structure, in particular the use of cleanups, which mean that any
analysis requires a lot of hair to ensure its correctness.


Last June (so long ago already?) I sent a draft of a proposal to migrate
gdb to C++ to the Archer list (the thread is
http://sourceware.org/ml/archer/2011-q2/threads.html#00028; the
followups are worth reading, but I've incorporated most of it into the
below).  After some discussion and edits, I chickened out of sending it.
Here it is now:


At the GCC Summit, I once again brought up the perennial idea of
moving GDB to be implemented in C++.  There, we agreed that as a
follow-on to that discussion that I would raise the topic among the
GDB maintainers, and in particular present my migration plan.

My goal for moving to C++ is to make GDB more robust.

My view is that GDB is already written in a poor cousin of C++.
Nearly every feature that people hate about C++ is already in use in
GDB.  This list is not exhaustive, just informational:

* Subclasses.  See general_symbol_info.  struct value and struct type
  would be improved by them.

* Virtual functions.  gdbarch, languages, and values all use these.

* Overloaded functions.  Anywhere you see a _1 suffix.

* Templates.  Both observers and VEC are templates.

* Exceptions.  Used ubiquitously.

* RAII.  Cleanups, but they are dynamic and more error-prone.

* Even global constructors -- init.c.

In most cases, GDB's implementation of these features is inferior to
that of the C++ compiler.  Its exceptions are slower.  Its data
structures have less type-safety.  Both cleanups and TRY_CATCH are
error-prone in practice.  GDB is needlessly verbose due to using
callback-based container iteration and callback-based exception
handling.  We have run into various situations where errors could have
been prevented through the use of better type-safety -- e.g., wrapper
classes for the CU- versus section-offset case.

I think a gradual move to C++ would enable us to fix these problems.
I believe it would also provide us a way to fix the ongoing reference
counting bugs in the Python layer.


I don't believe we should convert all of GDB to C++.  In particular I
think gdbserver should remain as pure C, and likewise any code shared
between gdbserver and gdb should be kept as such.


I also think we should be reasonably conservative in our choices of
C++ constructs to use.  I think this should be a separate thread; I
will be happy to write a draft proposal for this as well.  We can also
see what the GCC community comes up with here -- our needs are a
little different, but probably not drastically so.


My concrete transition proposal is:

1. Modify GDB so it can be compiled with -Wc++-compat.
   This would be the first patch series.  There is already an archer
   branch for this.

2. Then, change GDB to compile with a C++ compiler (-Wc++-compat is
   not complete).  This would be the second patch series.

3. Require C++.

4. Change selected modules to use C++ rather than C.
   I don't think a wholesale change makes sense, but some areas would
   benefit.

   My first target would be to change the exception handling system to
   use C++ exceptions.  This would enable us to begin using RAII in
   some areas, which would help robustness.

   My concrete plan here is:

   * Use the GCC cleanup-checking plugin I already wrote to detect
     cleanup-aware functions.

   * Modify these functions, using a script, to add an RAII-using
     object to manage the local cleanups.  This is important so that
     we run cleanups at the correct time during stack unwinding.

   * Change throw_exception to use 'throw' and all TRY_EXCEPT
     instances to try...catch.

   * Finally, convert functions to static RAII usage when appropriate;
     this will be an ongoing transition.

   I think our second target will be sorting out Python reference
   counting, so we can avoid the many problems we have had there.


Tom