This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]