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

[Pedro Alves <palves@redhat.com>]

On 04/12/2012 09:06 PM, Daniel Jacobowitz wrote:

> On Mon, Apr 9, 2012 at 3:48 PM, Pedro Alves <palves@redhat.com> wrote:
>> 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++.
> 
> The more things we add to gdbserver, the less I think it meets the
> goal of "simple, light-weight target agent".


Most things we add to gdbserver are optional.  E.g., tracepoints, and the
accelerated DSO list reading.  It'd be simple to add a --bare-bones configure
switch that disabled all the optional features.

> Yes, multiprocess debugging with gdbserver is an awesome development.

> No, you don't need it in the stage of system bringup where you don't
> have C++, if you're planning to have C++ eventually.  


I don't think multiprocess debugging adds much in terms of
code size.  It touches a lot, because it paremetrizes things with
additional structures instead of globals, but mostly, that's it.
A lot of code needed to _change_, not be added.

> So I think
> there's room for a potential C++ gdbserver and a small C gdbserver.

Seriously, I'd very very much like to fuse GDB's and GDBserver's backends,
to eliminate the duplication, which really gets in the way.  I should know;
adding multi-process and non-stop to gdbserver wasn't that much accelerated
from having added it to gdb itself, given how the codebases are similar, yet
so different.
So on order to remove the duplication, we'd end up with _two_ gdbservers, written
in different languages, each with its own bugs and need for maintenance, adding of
new arch ports, etc.?  Doesn't seem like a net win to me.  :-)

-- 
Pedro Alves