Executable file size

[Geoff]

What is the best way to strip out all debug and optimise for smallest
size? I have a C++ process that when compiled with -gdwarf-2 is 2.5Mb
long, and 1.5 Mb when no -g options is used. With Watcom the wstrip
utility could remove all the debug crap. Is there an equivalent with
gcc? If not, I'm open to recommendations as to what might be a suitable
list of compile/link options. In fact, I'd appreciate it as I have been
unable to do any better than the 1.5M above, even with -O.

The process is linking to static Dinkum libraries.

Thanks,

Geoff Roberts

[Chris McKillop]

Using "strip" is the smallest on-disk size you can get. You can check for the
"real" size by using the size utility (which isn't dependant on the
size reported by ls). The fact is that "modern" C++ (with everything being
templates) is not suited to small code. That is why we have the Dinkum
ecpp libs (embedded C++) and the pre-ISO GNU C++ libs.

Take this classic example...

#include <iostream>
int main( void ) { std::cout << "Hello World!" << std::endl; }

....compiled with "QCC -static"...

text data bss dec hex filename
233044 91304 3768 328116 501b4 hello_cpp

....compiled with "QCC -static -Vgcc_ntox86_ecpp"...

text data bss dec hex filename
85800 19980 1892 107672 1a498 hello_ecpp

....compiled with "QCC -static -Vgcc_ntox86_gpp"...

text data bss dec hex filename
112703 23468 1540 137711 219ef hello_gpp

Doing some tests by only static linking the C++ lib and not the C lib results
in some much better numbers for the ecpp and gnu libs (about 50K less).
Why are you linking statically? Just to get an estimate of the overhead?
Don't forget that with shared libs the text area is shared between processes
and so you only take that charge once (the whole point of using shared libs).

chris



Geoff <geoff@rtts.com.au> wrote:

What is the best way to strip out all debug and optimise for smallest
size? I have a C++ process that when compiled with -gdwarf-2 is 2.5Mb
long, and 1.5 Mb when no -g options is used. With Watcom the wstrip
utility could remove all the debug crap. Is there an equivalent with
gcc? If not, I'm open to recommendations as to what might be a suitable
list of compile/link options. In fact, I'd appreciate it as I have been
unable to do any better than the 1.5M above, even with -O.

The process is linking to static Dinkum libraries.

Thanks,

Geoff Roberts

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

[Geoff]

Chris McKillop wrote:

Using "strip" is the smallest on-disk size you can get. You can check for the
"real" size by using the size utility (which isn't dependant on the
size reported by ls).

strip reduced it to 179K. A vast improvement. size produced pretty much
the same information.

The fact is that "modern" C++ (with everything being
templates) is not suited to small code.

Aint that the truth?

That is why we have the Dinkum
ecpp libs (embedded C++) and the pre-ISO GNU C++ libs.

Take this classic example...

#include <iostream
int main( void ) { std::cout << "Hello World!" << std::endl; }

...compiled with "QCC -static"...

text data bss dec hex filename
233044 91304 3768 328116 501b4 hello_cpp

...compiled with "QCC -static -Vgcc_ntox86_ecpp"...

text data bss dec hex filename
85800 19980 1892 107672 1a498 hello_ecpp

...compiled with "QCC -static -Vgcc_ntox86_gpp"...

text data bss dec hex filename
112703 23468 1540 137711 219ef hello_gpp

Hmm.. Too many years with QNX4 and Watcom have spoilt me. My
expectations need to be adjusted downwards...

Doing some tests by only static linking the C++ lib and not the C lib results
in some much better numbers for the ecpp and gnu libs (about 50K less).
Why are you linking statically? Just to get an estimate of the overhead?
Don't forget that with shared libs the text area is shared between processes
and so you only take that charge once (the whole point of using shared libs).

I guess I am statically linking because that's what I'm used to doing,
and also because there will/should be only one instance of this
particular process. Given the size of this executable, and my abhorrence
of the idea of a driver being so large (the QNX4 version being only 40K)
I will investigate/experiment with the dynamic libraries. I'm still
pretty new to QNX6 and have a lot of QNX4 baggage to shed...

What sort of embedded systems are out there that have enough memory
resources to accomodate programs written in C++ and come out at 85K to
100K anyway???

Thanks again for your response.

Regards,

Geoff.

chris

Geoff <geoff@rtts.com.au> wrote:
What is the best way to strip out all debug and optimise for smallest
size? I have a C++ process that when compiled with -gdwarf-2 is 2.5Mb
long, and 1.5 Mb when no -g options is used. With Watcom the wstrip
utility could remove all the debug crap. Is there an equivalent with
gcc? If not, I'm open to recommendations as to what might be a suitable
list of compile/link options. In fact, I'd appreciate it as I have been
unable to do any better than the 1.5M above, even with -O.

The process is linking to static Dinkum libraries.

Thanks,

Geoff Roberts

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

--

Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA

Phone: 61-2-6291 3833
Fax: 61-2-6291 3838
Mobile: 0413 634 667
Email: geoff@rtts.com.au

[Chris McKillop]

strip reduced it to 179K. A vast improvement. size produced pretty much
the same information.

size will report the same info regardless of if you have run strip. That
is why it is a good source of information. It will also report runtime
sizes (bss) that are not included in the size of the binary.

Hmm.. Too many years with QNX4 and Watcom have spoilt me. My
expectations need to be adjusted downwards...

The thing is that Watcom's C++ support is very pre-ISO C++. If you
brought in a modern C++ lib there wouldn't be much different in size between
Watcom and gcc. I did the port of the open-source STL system to Watcom
on QNX4 years ago and man did the binaries get HUGE. Nearly all of the
size is inside of the library.

I guess I am statically linking because that's what I'm used to doing,
and also because there will/should be only one instance of this
particular process. Given the size of this executable, and my abhorrence
of the idea of a driver being so large (the QNX4 version being only 40K)
I will investigate/experiment with the dynamic libraries. I'm still
pretty new to QNX6 and have a lot of QNX4 baggage to shed...

Well, if you have more then one process using the C library (which I assure
you will be the case) and more then a few using the C++ library then you
can amoratize the cost of the library between each process.

What sort of embedded systems are out there that have enough memory
resources to accomodate programs written in C++ and come out at 85K to
100K anyway???

Well, I have a cheap iPaq with 32M of flash and 64M of RAM. But really,
if you use the ecpp lib and don't link statically my hello example
is about 8K. The ecpp lib itself is only 110K. So you have 5 apps using
it and the cost in flash goes from about 290K (static ecpp) to about
170K (dynamic ecpp).

chris


--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/