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

[Daniel Jacobowitz <daniel.jacobowitz@gmail.com>]

On Wed, Apr 18, 2012 at 10:07 AM, Pedro Alves <palves@redhat.com> wrote:
> On 04/12/2012 09:06 PM, Daniel Jacobowitz wrote:
>> 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.

A complex program with optional features doesn't get simpler just
because the optional
bits are turned off.  The more configuration options there are, the
less likely any of them
work.  That's my position.

>> 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.

A lot of code needs to be *more complicated* because of it.  That's
what I think is the mistake.
I'll even argue that multi-threaded support with a C++ dependency is
basically OK.  If we're going to have
trouble because of uclibc or Android or LynxOS, then we can either
change the minimal feature set supported
by the C version or we can make the necessary runtime work on the
bigger platforms.

I really don't think it's infeasible.  I don't think that there's a
good reason to restrict the progress of the larger
program because we need a small program too.

>
>> 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.  :-)

Does seem like a win to me.  I think people overestimate how
complicated a basic gdbserver port is.
The bits that are hard to figure out you have to figure out for GDB
anyway, if you're going
to bother with GDB.  Especially if threading ends up above the language bar.

-- 
Thanks,
Daniel