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

Stan Shebs
2012-11-27T01:29:57Z

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