FYI, I'm back on the C++ camp now.

If you asked me a couple years ago, I'd have been strongly in
favor of use of C++ in GDB.  However, last year, when the subject
was brought up, for the Nth time, after a lot of thinking, I ended
up pending for "no C++" [1].

My main reasoning at the time was that GDBserver should be
lean, and that that would require staying in C.  And then, we're
trying to merge a lot of GDB and GDBserver backend code, so mixing
in C++ and C would mean we'd still end up with GDB's own C idiom,
and so newbies would still need to learn it, in addition to
whatever new GDB-specific C++ idioms we come up with, which
I see as a potential net loss.  Also, GDBserver and
the in-process agent code are very tightly coupled, sharing
a lot of code, so whatever language GDBserver is implemented
in, the in-process agent would follow suit.  I mentioned
then that switching the in-process agent to C++ would not
be a good idea.

For the past few weeks, I've been thinking this through
again (blame it on summer vacations!).  I've reviewed the whole
discussion, and I now believe all my counter arguments
have been addressed.

Tom's code size experimentations with different C++ compiler
options have addressed my concerns.  In particular, we have
The -static/-static-libstdc++/-static-libgcc options as
well as --enable-sjlj-exceptions, which all should
allow building a lean self-contained in-process agent that
doesn't force much into the target process, as well as
providing an option for deploying a self-contained, lean
GDBserver for constrained/embedded environments with possibly
no shared C++ runtime deployed.  If we can move GDBserver
to C++, then I no longer have issues with moving GDB as well.

Host system toolchain support for C++ exceptions was something
that concerned me somewhat too.  Android was one such example.
It used to be C++ exceptions weren't really supported by the Android
SDK, but things may have moved on since.  From some google searches,
it seems it should be easier to use exceptions there nowadays, at
least if using GNU's libstdc++.  It might still be necessary to
build a custom toolchain, but I'm not sure about that -- I'd be
curious to know.  I don't know whether other supported hosts/targets
(particularly the older Unix-like ones, where we might not have
gcc available) are a concern here, but perhaps we should just
move on, and have people port gcc for them if they want gdb too.
Older gdb's will always be available.

Well, that's it.  Yep, I've changed my mind.

[1] http://sourceware.org/ml/gdb/2012-04/msg00063.html

Thanks,
-- 
Pedro Alves