Reduce binary size and compile time with split DWARF

Video

Building for debug

This follows on from my video Build for Debug which looked at how to build your program for the best debugging experience with GDB. Check out that post to understand the difference between the -g and -O flags, what <optimized out> really means, the different DWARF formats and more.

Building programs to be debugged inside GDB can result in high binary size and increased compile times. In this post and screencast above, I cover how to build your program for debugging, while reducing binary size and compile time by using the split DWARF flag.

UDB Time Travel Debugger
Step backwards in time to view registers and memory – find and fix bugs in minutes
Learn more »

Build times and binary size

I omitted to mention that when using -g3, as well as producing larger binaries, it will take longer for the compile step as well. So, if longer build times are a problem for you, that’s something to consider.

I should also point out that the size impact can be significant. Even with -g (which will default to level 2), 60% – 80% of your binary size will be the debug information. With -g3, this can as much as double.

Even with incremental builds, the linker still needs to read all of the debug information in order to do things like remove duplications, for example.

Using split-dwarf to reduce binary size

One thing that you can do to ameliorate the increased file size and compile time is the split DWARF approach.

For example, when using -g3 on an example program optimized.c:

gcc -g3 -gsplit-dwarf -O3 optimized.c

If you then list the resulting contents of the directory you’ll see a few extra files:

You can see that the compiler has made optimized.dwo which is where all my DWARF information has gone. So when I come to link the different objects together, if I’ve got an incremental build, the linker doesn’t need to worry about them.

It also means I can store them separately and easily ship my binary.

While you can get a similar effect without the split DWARF hassle by doing:

gcc -g3 -O3 optimized.c
cp a.out a.out.debuggable
strip a.out

… which achieves the same thing with the two steps.

The advantage of split DWARF is that if your compile times are a problem, you’re doing incremental builds and your link times are significant then that can be a big win.

And there you go! Hopefully that bolstered your deeper understanding of how you build your program for debugging with GDB.