This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Will therefore GDB utilize C++ or not?
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, gdb at sourceware dot org
- Date: Mon, 21 May 2012 16:55:47 +0100
- Subject: Re: Will therefore GDB utilize C++ or not?
- References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F832D5B.9030308@redhat.com> <87ehqhfenc.fsf@fleche.redhat.com>
On 05/18/2012 08:55 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
>
> Pedro> This is important, because we want gdbserver to be usable in #1,
> Pedro> resource constrained scenarios where the C++ dependency would be
> Pedro> unacceptable.
>
> I wonder whether you would reconsider this given the size measurements I
> did.
Thanks. I appreciate them. I didn't expect the code size to grow significantly,
as we had already seem similar comparisons done for gcc in the course of
the various C vs C++ discussions over there with similar results.
However, I'll note that such comparisons assume an unchanged C-style codebase,
and ignore the size increase you get when you actually start using C++
features, such as, throwing exceptions, or using iostream. In my quick
experiment adding a cout << "foo" (-static-libstdc++ -flto -Os + strip) more
than triples the binary size.
> In particular, C++ is something like 3% space overhead today, and that
> gdbserver is already ~300K. I think that size growth is quite
> acceptable.
>
> Pedro> We don't want there to need to be other gdbserver-like programs
> Pedro> specialized for such environments, and gdbserver to be usable
> Pedro> only on bigger machines. We want gdbserver to run everywhere.
>
> The recent gdb-patches thread from Jonathan Larmour indicates that we
> already lost this one. He was concerned about the use of 2183 bytes.
That was for eCos, running on tiny embedded micro-controllers though.
I'm talking about things such as uclinux based routers vs big iron
GNU/Linux mainframes -- having only one codebase to maintain that
has to know ptrace intricasy, for example.
--
Pedro Alves