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

Pedro Alves
2012-04-09T19:49:18Z

On 04/09/2012 08:05 PM, Jan Kratochvil wrote:

> On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote:
>> Indeed, gdbserver would need to remain pure C,
> [...]
>> This is important, because we want gdbserver to be usable
>> in #1, resource constrained scenarios where the C++ dependency would
>> be unacceptable. We don't want there to need to be other gdbserver-like
>> programs specialized for such environments, and gdbserver to be usable only
>> on bigger machines. We want gdbserver to run everywhere. And #2, the debugger
>> is one of the first programs that is desirable to get running on a new
>> system/board. Usually you get C going much sooner than C++.
>
> While it was said before gdbserver should stay in C I did not see it long-term
> maintainable - due to the code sharing goals.

I do.

> While I wanted to simplify the
> talk excluding gdbserver first we can talk even about C++ization of gdbserver.
>
> Which specific platforms do you talk about which is UNIX compatible (=FSF
> gdbserver compatible, not just an embedded stub) and cannot run C++ programs?
> (*) Please give examples of viable platforms with future development.

GNU's not UNIX. Haven't you heard? And why do you keep excluding embedded
things? This is a recurrent point you raise in several discussions.
Haven't you noticed the trend towards mobile computing? Even Red Hat
has business in the embedded world since a long long time (GNUPro and
services). Even Android/Bionic doesn't support C++ exceptions (not sure
if it doesn't in recent versions or not).

I don't even need to leave my office to find such a system.

$ssh 192.168.0.253
[pedro@NAS][~]
>ls /usr/lib/libstd*
ls: cannot access /usr/lib/libstdc*: No such file or directory
> uname -a
Linux NAS 2.6.24.4 #1 Tue Feb 10 11:00:22 GMT 2009 armv5tejl unknown

>> The event-loop.c file is yet another thing.
>> It is currently duplicated (though a bit simplified) in gdbserver/event-loop.c.
>> There goes another use for C++ classes.
>
> The mail lists all the code parts which cannot be C++ized. I do not find that
> too interesting.

It explained that many core parts of GDB should stay in C. Which served
to raise awareness that converting just a few parts to avoid a few bugs and making
things neater here and there has a lot of potential for making things worse.
I find interesting code parts which can be C++ized - such as

> anything about symbols/types outside of gdbserver.

It is very much not clear to me that it is worth the pain (that I tried to show
we will end up with) to bring in C++ for this. Symbol/types even are long lived
objects, it's not common at all to need to worry about leaks (RAII/exceptions)
here. And all we have are simple hierarchies. As much as I like C++, C does
quite fine here too. The language it is written in is not the problem with
our symbol tables.

>

>
>> (On a sidenote: I get the impression from some that C++ would be mostly
>> useful for the stronger static typing,
>
> Not just that one, std::string vs. cleanups vs. exceptions are even more
> wanted (by me); just static typing (probably) cannot be done without C++,
> the other parts are still being fixed up without C++.

Sure, there will always be bugs. C++ doesn't magically make all bugs go away.
Even RAII is not _that_ different from cleanups. We still need to have a
way to tell the RAII wrapper objects to stop managing whatever they're managing,
for instance. And with C++98/03, we have to write these things out of line, like
cleanups too. What I'm saying is that our C mechanisms work. There is no need to
rush to replace them. We should consider this very very carefully, not just
flip just because.

--
Pedro Alves