Re: C++ draft

[Gary Benson <gbenson@redhat.com>]

Yao Qi wrote:
> Do we plan to move gdbserver to C++?  I think no, because some
> baremental boards have too few memory to hold a C++ application.
> So we are in a state that both C and C++ co-exist in GDB for
> some time. I don't think C and C++ co-existance is a problem,
> or, your plan is> about "make good use of C++ to replace some
> bad and error-prone stuffs in GDB, and keep the rest of GDB as
> it is".  Is it right?

As I understand it, I don't know that there's any reason C++ has to
use more memory than C.  Granted there are things like the STL that
generate vastly more code under the hood than you might expect, but
I don't think anybody is talking about using STL here.

I've spent the past few years working on HotSpot, which is written
using a similar subsection of C++ to what Tom is proposing (with the
exception that HotSpot does not use C++ exceptions).  My experience
has been that the overheads of C++ are as minimal as the can be.  A
data structure in a virtualized class, for example, is larger than
that same data structure in a struct by only a single pointer.  In
cases where GDB is doing what C++ would anyway--for example, replacing
pointers to functions with C++ virtual functions--then we're doing
essentially the same thing, only with better readability and error-
detection.

A concrete example, hello world:

  #include <stdio.h>
  
  int
  main (int argc, char *argv[])
  {
    puts ("Hello world");
    return 0;
  }

Save it as hello.c and compile with gcc, then save it as hello.cc
and compile with g++.  The code for the main function is _exactly_
the same:

  0000000000400514 <main>:
    400514:	55                   	push   %rbp
    400515:	48 89 e5             	mov    %rsp,%rbp
    400518:	48 83 ec 10          	sub    $0x10,%rsp
    40051c:	89 7d fc             	mov    %edi,-0x4(%rbp)
    40051f:	48 89 75 f0          	mov    %rsi,-0x10(%rbp)
    400523:	bf 38 06 40 00       	mov    $0x400638,%edi
    400528:	e8 e3 fe ff ff       	callq  400410 <puts@plt>
    40052d:	b8 00 00 00 00       	mov    $0x0,%eax
    400532:	c9                   	leaveq 
    400533:	c3                   	retq   
    400534:	90                   	nop
    400535:	90                   	nop
    400536:	90                   	nop
    400537:	90                   	nop
    400538:	90                   	nop
    400539:	90                   	nop
    40053a:	90                   	nop
    40053b:	90                   	nop
    40053c:	90                   	nop
    40053d:	90                   	nop
    40053e:	90                   	nop
    40053f:	90                   	nop

The resulting executable is slightly larger (6562 bytes from 6433).
I'm not sure where this comes from or how it would scale from this
trivial example to a project the size of GDB, but the beauty of
Tom's plan is that the first step is to get the basic C code to
compile with a C++ compiler.  Once that's done we can build the
same codebase with the different compilers and see where we're at.

Cheers,
Gary
    
-- 
http://gbenson.net/