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

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Thu, 22 Nov 2012 22:42:42 +0100, John Gilmore wrote:
> > For most embedded Linux kernel targets it will be enough to build the standard
> > fully featured gdbserver with static libstdc++ (making it only ~2x larger).
> 
> It becomes ~2x larger for what benefit?

http://sourceware.org/ml/gdb/2012-04/msg00044.html

Specifically the size of code itself is irrelevant.  It may have rather other
disadvantages such as clearly lower compatibility with compilers.  Not that it
would be a problem nowadays on GDB supported platforms.


> > There will be also separate minimal gdbserver in plain C.
> >					...	 This minimal server has no
> > need for non-stop/multi-inferior etc., it will be created by stripping down
> > the current one; but in fact one can be also easily code it from scratch.
> 
> Why in heaven's name would you take working code that's in the release
> today, and "strip it down" to be less functional?  What's wrong with
> continuing to ship it merely the way it is?

Because the advanced features (non-stop/multi-inferior etc.) are still not
fully stable, their require more fixes and extensions.

Coincidentally these features are not required on the very few target
platforms possibly not supporting C++ for gdbserver.

One option is to use existing C gdbserver as is on those few non-C++ target
platforms.  But if anyone tries to use some advanced feature there s/he may
face bugs/incompatibilities in those.  Therefore I believe it is easier for
everyone not to ship broken and unmaintained features at all.

The other option of keeping gdbserver in C faces the problem it could no
longer share significant code parts with gdb.  Problems from such design were
described by Pedro as not feasible:
	http://sourceware.org/ml/gdb/2012-04/msg00063.html


I was always against C++ till and including first years od GDB, this is why
I always preferred GTK with its C++-in-C GObject framework compared to Qt.
The reasons in my case were:
 * Compiler incompatibility, around 2000 C++ across GCC and compilers on
   commercial Unices was not compatible.  AFAIK C++ standardization is now OK
   and also the set of compilers/platforms in use is reduced compared to 2000.
 * Debugging C++ was a problem as GDB did not handle it well.  It has improved
   a lot and besides that the remaining issues will get fixed faster with GDB
   in C++.
 * That "tables of C pointers" as in GObject is good enough replacement for
   C++.  That was a misunderstand what is C++, virtual method table is
   a negligible part of what provides C++ and its STL/Boost libraries.

I do not want to start showing how easier are C constructs when written in
a proper way in C++, one such was already posted here with shared_ptr:
	http://sourceware.org/ml/gdb/2012-11/msg00063.html
	Although that was still overcomplicated to match Pedro's real pointer
	in the former code.  Usually one can keep and pass the variable by
	value (with no shared_ptr) thanks to the move constructor efficiency.

The repeating simple crasher bugs just due to the C++-in-C GDB framework which
is only reviewer checked and not compiler checked is too fragile.  You can
takeover fixing all these annoying crasher bugs like:
	https://bugzilla.redhat.com/show_bug.cgi?id=864575
Fortunately compilers have evolved during the years and what had to be
verified by hand can be now automated by the compiler.  There are still bugs
in the programs but people can spend more time fixing the bugs not caught by
the compiler instead of doing the same what the compiler does automatically.

While not the typical C++ purpose specifically now (again) I push for C++
because I have to upstream the 64-bit inferior offsets/sizes as present in
many patches posted by Siddhesh Poyarekar <siddhesh@redhat.com>.  After almost
the year of work we/I can start again as there no way for easy refactorization
of C code.  splint or compiler warnings were shown as incomplete for that
purpose, fixing very every '-Wconversion -Wno-sign-conversion' warning is many
times more expensive (than fixing just the cases requested to be fixed).
With C++ one can provide container classes for the numerical types and catch
just the operations violating the type width safety.
	#include <stdlib.h>
	class Type64 {
	private:
	  int64_t v;
	  operator int32_t () { abort (); } // error
	public:
	  operator int64_t () { return v; }
	  int64_t get () { return v; }
	  Type64() {}
	  Type64(int64_t i) { v = i; }
	  Type64& operator = (const Type64 &rhs) { v = rhs.v; return *this; }
	  Type64& operator ++ () { ++v; return *this; }
	  Type64 operator ++ (int) { Type64 retval(*this); ++v; return retval; }
	  Type64 operator += (const Type64 &rhs) { v += rhs.v; return *this; }
	};
	int main () {
	  Type64 v64 = 0;
	  v64++;
	  ++v64;
	  v64 += 2;
	  int error = v64; // error: ‘Type64::operator int32_t()’ is private
	  return v64.get (); // safe explicit request for width violation
	}


Jan