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?


Tom> I think this relies on the idea that the C++ runtime dependency is
Tom> unavoidably very heavy.  And, in earlier discussions on the Archer list,
Tom> I agreed with this idea without giving it too much thought.

Tom> But, that seems to me to be an empirical question.  We could measure the
Tom> impact.

Today I built gdbserver a number of different ways.
In particular, I applied a few hacks, disabled all warnings, and used
-fpermissive, so that I could build it with g++ as well.

I'm appending my script, I can send the various hacks too if anybody
needs them.  They were trivial though.

Here's the results.  I did all builds on an x86-64 F16 box.  For g++ I
used -static-libstdc++; though it shouldn't pull in very much right now.
I used a trunk gcc from today, since F16 doesn't apparently package
libstdc++.a, but earlier runs with the system compiler were roughly
similar.  I threw in -fexceptions since I was curious what would happen.

    344064 g++ -O2
    331776 gcc -fexceptions -O2
    331776 gcc -O2
    311296 g++ -flto -O2
    303104 g++ -Os
    303104 gcc -flto -fexceptions -O2
    303104 gcc -flto -O2
    290816 gcc -fexceptions -Os
    290816 gcc -Os
    278528 g++ -flto -Os
    270336 gcc -flto -fexceptions -Os
    270336 gcc -flto -Os

First, clearly, if you care about size you should be using -flto -Os.
This is a clear win.  Our default of -O2 is much worse.

Second, g++ induces very little bloat on the current code base.
It is about 3%.

Now, I realize this is not necessarily indicative of the ultimate size
increase.  "Zero-cost" exceptions do in fact have a cost in the size of
the executable.  I failed to easily build an SJLJ compiler, so I didn't
try to do any measurements of this.

This process did discover a bad "return 1" in the middle of
ax.c:gdb_eval_agent_expr.  I think  it should return
expr_eval_unrecognized_opcode.

Tom

#!/bin/sh

for comp in gcc g++; do
    if test $comp = gcc; then
	cc=$comp
	compflags=
    else
	cc='g++ -fpermissive'
	compflags='LDFLAGS=-static-libstdc++'
    fi
    for base in '' -flto; do
	for exc in '' -fexceptions; do
	    if test $comp = g++ && test x$exc = x-fexceptions; then
		continue
	    fi
	    for opts in -O2 -Os; do
		echo ================================================================
		flags=$(echo $base $exc $opts)
		echo ===== $flags
		echo
		make clean-local
		make CC="$cc" CFLAGS="$flags" WARN_CFLAGS= WERROR_CFLAGS= $compflags gdbserver
		f2=$(echo $comp $flags | sed -e 's/ /_/g')
		cp gdbserver gdbserver-$f2
	    done
	done
    done
done


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