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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Mon, 21 May 2012 17:55:47 +0200, Pedro Alves wrote:
> 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.

FSF GDB HEAD plain C build:
x86_64 -Os -flto gcc (GCC) 4.7.1 20120526 (prerelease)
        linux-vdso.so.1 =>  (0x00007fff4b093000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fb835780000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fb8353c8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb835994000)
-rwxr-xr-x 1 jkratoch jkratoch 265000 May 26 16:05 gdbserver*

After adding that cout I really get ~1.1MB bytes build.  But iostream is not
useful for gdbserver.

With the useful C++ features exploited by
  #include <vector>
  #include <unordered_map>
  #include <string>
  {
    unordered_map<string, string> foo;
    foo["bar"] = "b";
    vector<string> bar;
    try {
      throw 0;
    } catch (int e) {
      bar.push_back(string("bar"));
    }
  }
I get:
x86_64 -Os -flto gcc (GCC) 4.7.1 20120526 (prerelease)
        linux-vdso.so.1 =>  (0x00007fff084b5000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fa35d6e8000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fa35d3e4000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fa35d0e9000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa35ced4000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fa35cb1c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa35d8fc000)
-rwxr-xr-x 1 jkratoch jkratoch 285816 May 26 16:50 gdbserver*

With linking statically the additional libraries the C build has not depended
upon:
x86_64 -Os -flto gcc (GCC) 4.7.1 20120526 (prerelease)
        linux-vdso.so.1 =>  (0x00007fffee9ff000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f54fbf07000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f54fbb4f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f54fc11b000)
-rwxr-xr-x 1 jkratoch jkratoch 453728 May 26 17:22 gdbserver*

453728 vs. 265000 bytes is +71% increase.
It still seems perfectly worth to me for all the discussed C++ benefits for GDB.

(Maybe one could also look for some inadvertent libraries parts brought in.)


On Tue, 22 May 2012 20:03:41 +0200, Paul_Koning@Dell.com wrote:
> > On Mon, 21 May 2012 19:36:57 +0200, Paul_Koning@Dell.com wrote:
> > > I'm working on a system where the boot device has about a megabyte free
> > > space, on a good day.
> It's a NetBSD/MIPS64 derivative embedded system.  No other secondary storage
> for code.

I have used gcc42.fsffrance.org producing:
  gdbserver: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped

FSF GDB HEAD plain C build:
mips32 -Os gcc (RAYS 4.3.0-4.rays0) 4.3.1 20080501 (prerelease)
	libdl.so.2 => /lib/libdl.so.2 (0x2aaec000)
	libc.so.6 => /lib/libc.so.6 (0x2ab00000)
	/lib/ld.so.1 (0x2aaa8000)
-rwxr-xr-x 1 jankratochvil jankratochvil 306092 2012-05-26 05:12 gdbserver*

With the <vector>/<unordered_map>/<string> C++ features I get:
	libdl.so.2 => /lib/libdl.so.2 (0x2aaec000)
	libc.so.6 => /lib/libc.so.6 (0x2ab00000)
	/lib/ld.so.1 (0x2aaa8000)
-rwxr-xr-x 1 jankratochvil jankratochvil 846668 2012-05-26 17:44 gdbserver*

The size increase is primarily due to libm.a, with libm.so I get:
	libdl.so.2 => /lib/libdl.so.2 (0x2aaec000)
	libm.so.6 => /lib/libm.so.6 (0x2ab00000)
	libc.so.6 => /lib/libc.so.6 (0x2ab98000)
	/lib/ld.so.1 (0x2aaa8000)
-rwxr-xr-x 1 jankratochvil jankratochvil 462188 2012-05-26 17:41 gdbserver*

I believe we can get mips under 500KB as libm should not be needed anywhere.


For 64-bit mips64:
When I used CFLAGS="-Os -mips64 -mabi=64" there producing:
  gdbserver: ELF 64-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped
I did not have static 64-bit libstdc++ available on gcc42.fsffrance.org.  I had
some issues building mips64 toolchain and I did not spend too much time on it.
64-bit libstdc++.so would work but it would not provide the size benchmark
numbers here.  64-bit FSF GDB HEAD gdbserver was 289496 bytes (instead of
32-bit 306092) so 64-bit mips build size numbers should not be in disadvantage.



Thanks,
Jan