This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Will therefore GDB utilize C++ or not?
Yes, it's good to be watchful for code bloat on gdbserver. But a very big difference between it and gdb is that the symbol tables are at the gdb end. In our case, that's the main reason we use gdbserver. It would be tolerable for the executable to be bigger, but we don't have space for many of the inferior's symbol tables on the target system.
paul
-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf Of Daniel Jacobowitz
Sent: Thursday, April 12, 2012 4:06 PM
To: Pedro Alves
Cc: Jan Kratochvil; Tom Tromey; gdb@sourceware.org
Subject: Re: Will therefore GDB utilize C++ or not?
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". 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.
How did I end up being the curmudgeon? I'm confused.
--
Thanks,
Daniel