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

Doug Evans
2012-04-13T00:04:38Z

On Thu, Apr 12, 2012 at 1:06 PM, Daniel Jacobowitz
<daniel.jacobowitz@gmail.com> wrote:
> The more things we add to gdbserver, the less I think it meets the
> goal of "simple, light-weight target agent".  I resisted code sharing
> with GDB for a long time.  If the consensus nowadays is that code
> sharing is the way to go, then I think it behooves someone to figure
> out the needs of a modern light-weight target agent that's a lot
> smaller than gdbserver.
>
> 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.  So I think
> there's room for a potential C++ gdbserver and a small C gdbserver.

[filing for reference sake]

I'd (ultimately) like to see gdb and gdbserver built up out of a set
of, umm, libraries ("We need more libraries!").
Exporting the functionality of the libraries to scripting languages
(e.g., python) through these libraries would involve more of a C API
than C++.

With said partitioning of functionality, it shouldn't be that hard to
have either a small and simple gdbserver or a large and feature-rich
gdbserver.

[side question: Do people that want a small embedded-system-like
gdbserver, also want it to have same features as the the massively
feature rich gdbserver of a non-embedded-system gdbserver? I'd expect
that they're ok that the overarching need of smallness precluding
some, umm, bloatware. :-)]