Will therefore GDB utilize C++ or not?

[Stan Shebs]

On 11/22/12 10:46 AM, Jan Kratochvil wrote:
> On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote:
>> If you asked me not too long ago, I'd have been strongly in favor
>> of C++.  However, that is no longer the case.  I'm now pending
>> towards "no C++".
> I have re-read now the thread and I have not found any blocker issues left.
>
> Here is a plan that should IMHO satisfy all the requirements stated here.
> I did not reply to C++ disagreements which were already well enough replied
> here.
>
>
> Current gdbserver will be also in C++.
>
> 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).
>
> There will be also separate minimal gdbserver in plain C.  For some very
> minimal targets still running Linux kernel but no longer having C++-capable
> compiler or having some other problem running C++.  There was stated no
> concrete such target but maybe there exists one.  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.
>

I think for this it should be sufficient to announce an end-of-C point 
for gdbserver, tag it, and record it on a web page; while it's certainly 
possible that someone in the future will have need for a C-only 
gdbserver, I think the chances are vanishingly small, and we shouldn't 
be using up too many brain cycles designing it.

People that are space-conscious are already using their own stubs or 
forked versions of gdbserver.  I note for instance that we nearly 
doubled the size of gdbserver's code when we added target-side 
tracepoint bits a couple years ago, and I don't recall any grousing 
about it getting too big then.  In a world where mega-programs like 
Firefox fit easily onto a cell phone *now*, I'm not just seeing that any 
future projects are going to be so tightly constrained that gdbserver 
size is noticeable.

Stan
stan@codesourcery.com