What Is "Strip" (Gcc Application) Used For

What is strip (GCC application) used for?

From the (Mac OS X, but others are similar) man page:

strip removes or modifies the symbol table attached to the output of
the assembler and link editor. This is useful to save space after a
program has been debugged and to limit dynamically bound symbols.

Note the bit about "after a program has been debugged" because debugging a stripped executable is very hard, indeed. The "limit dynamically bound symbols" is a rarer use: it lets you make some of the functions in an external library inaccessible by taking away the index entries that tell where the actual code is located. This is also explained in the man page.

As cheap and plentiful as disk is in most situation you simply wouldn't bother with this anymore. But you might want it for space constrained situation like embeded devices, rescue disks, etc.

What is the difference between gcc -s and a strip command?

gcc being a compiler/linker, its -s option is something done while linking. It's also not configurable - it has a set of information which it removes, no more no less.

strip is something which can be run on an object file which is already compiled. It also has a variety of command-line options which you can use to configure which information will be removed. For example, -g strips only the debug information which gcc -g adds.

Note that strip is not a bash command, though you may be running it from a bash shell. It is a command totally separate from bash, part of the GNU binary utilities suite.

gcc -g vs not -g and strip vs not strip, performance and memory usage?

The ELF loader loads segments, not sections; the mapping from sections to segments is determined by the linker script used for building the executable.

The default linker script does not map debug sections to any segment, so this is omitted.

Symbol information comes in two flavours: static symbols are processed out-of-band and never stored as section data; dynamic symbol tables are generated by the linker and added to a special segment that is loaded along with the executable, as it needs to be accessible to the dynamic linker. The strip command only removes the static symbols, which are never referenced in a segment anyway.

So, you can use full debug information through the entire process, and this will not affect the size of the executable image in RAM, as it is not loaded. This also means that the information is not included in core dumps, so this does not give you any benefit here either.

The objcopy utility has a special option to copy only the debug information, so you can generate a second ELF file containing this information and use stripped binaries; when analyzing the core dump, you can then load both files into the debugger:

objcopy --only-keep-debug myprogram myprogram.debug
strip myprogram

gcc vs. clang: symbol stripping

You can use a strip utility from binutils.

Actually, a llvm-ld has this options http://llvm.org/cmds/llvm-ld.html

-strip-all, -s Strip all debug and symbol information from the executable
to make it smaller.

-strip-debug, -S Strip all debug information from the executable to
make it smaller.

opt have something too:

-strip-debug
This option causes opt to strip debug information from the module before applying other
optimizations. It is essentially the same as -strip but it ensures that stripping of debug
information is done first.

Strip Executable (Windows)

strip is part of GNU's binutils.

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

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...

gcc -O2 is smaller then gcc -O2 -g followed by strip --strip-all

The difference is from the debug code.

For an 1.7 MB executable you are probably using a library or two. Usually they have something like:

#ifdef _DEBUG
    // some debug code
#endif

Also common practice for big projects, so some of it may be your code as well.

strip removes only the symbols. The debug code stays.

Best way to strip off symbols

With Visual C++ (and other Microsoft compilers) on Windows, symbols aren't part of the binaries. Instead, they are stored in separate files called "Program Database" files (.pdb files). Just don't provide the .pdb files.

With the GNU toolchain you would use strip to remove symbols from the binaries.

---

Related Topics