Is there any reason why not to strip symbols from executable?

Question

A couple of years ago I asked a question how to reduce size of executables. Using MinGW compiler, stripping symbols (-s option) helped to reduce 50%+ of the size.

Answer 1

There is no good reason to strip symbols. By stripping symbols, for instance, you will eliminate a possibility to gather process stack - an extremely usuful feature.

EDIT. Several people here seem to be confused about the difference between debug symbols and 'general' symbols. The first are only produced when -g (or similar) option is given to the compiler, and are usually used only in debug builds (though can be used with optimized builds as well). The regular symbols are things such as function names, and are produced by compilers so that object files could be linked, or .so files loaded. There are several extremely useful non-invasive tools which can be used on non-debug running executables which depend on symbols being non-stripped.

Answer 2

I can't imagine them affecting the execution speed in any noticeable way though, in theory, you could have a tiny amount of cache misses in the process image.

You want to keep symbols in the file when you're debugging it, so that you can see which function you're in, check the values of variables and so forth.

But symbols make the file bigger: potentially, a lot bigger. So, you do not want symbols in a binary that you put on a small embedded device. (I'm talking about a real embedded device, not some 21st century Raspberry Pi with 9,000GB of storage space!)

I generally strip all release builds and don't strip any debug builds. This makes core dumps from customers slightly less useful, but you can always keep a copy of the unstripped release build and debug your core against that.

I did hear about one firm that had a policy of never stripping symbols even in release builds, so they could load a core directly into the debugger. This seems like a bit of an abstraction leak to me but, whatever. Their call.

Of course, if you really want, you can analyse the assembly yourself without them. But that's crazy...

Answer 3

MinGW is an acronym for "Minimalist GNU for Windows"; as such, the compiler suite is GCC ... the GNU Compiler Collection. Naturally, this compiler suite will tend to comply with the GNU Coding Standards, which demand that every build shall be a "debug build" ... i.e. it shall include both debugging symbols, and those required for linking. (This is logical, since a "debug build" is orders of magnitude more useful to the application developer, than is a so-called "release build"). Furthermore, a build system which discriminates between "debug build" and "release build" modes is more complex -- possibly significantly more so -- than one which concerns itself with only a "debug build".

In the GNU build model, there is no need for a "release build" anyway. A "release" is not created at build time; it is created at installation time -- usually as a "staged" installation, from which a release package is created. The GNU tool-chain includes both a strip command, and an install command, which can strip a "debug build" on the fly, when creating a staged installation for packaging as a release, (or in place, if you wish), so there really is no need to clutter the build system with "release build" specifics; just create a "debug build" up -front, then strip it after the event, so converting this to an effective "release build", when you require it.

Since your MinGW tool-chain is fundamentally a GNU tool-chain, it fully supports this GNU build model.