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
Executable file size
Re: Executable file size
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:
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/
"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/
Re: Executable file size
Chris McKillop wrote:
the same information.
expectations need to be adjusted downwards...
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.
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
strip reduced it to 179K. A vast improvement. size produced pretty muchUsing "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 same information.
Aint that the truth?The fact is that "modern" C++ (with everything being
templates) is not suited to small code.
Hmm.. Too many years with QNX4 and Watcom have spoilt me. MyThat 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
expectations need to be adjusted downwards...
I guess I am statically linking because that's what I'm used to doing,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).
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
Re: Executable file size
size will report the same info regardless of if you have run strip. Thatstrip reduced it to 179K. A vast improvement. size produced pretty much
the same information.
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.
The thing is that Watcom's C++ support is very pre-ISO C++. If youHmm.. Too many years with QNX4 and Watcom have spoilt me. My
expectations need to be adjusted downwards...
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.
Well, if you have more then one process using the C library (which I assureI 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...
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.
Well, I have a cheap iPaq with 32M of flash and 64M of RAM. But really,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???
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/