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: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>, Paul_Koning at Dell dot com
- Cc: Tom Tromey <tromey at redhat dot com>, gdb at sourceware dot org
- Date: Sat, 26 May 2012 17:50:05 +0200
- Subject: Re: Will therefore GDB utilize C++ or not?
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