gdbWatchPoint

Reduce binary size and compile time with split DWARF

Written by Dr Greg Law | Last updated 8th Nov 2019

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.

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:

split-dwarf-1

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.

Get tutorials straight to your inbox
Become a GDB Power User. Get Greg's debugging tips directly in your inbox every 2 weeks.
  • Catch intermittent bugs in the act
    Can't reproduce a non-deterministic bug? This on-demand webinar illustrates how to obtain a 100% reproducible test case.
    Watch the webinar
  • Concurrency Defects Resolution
    New techniques to help quickly find and resolve defects in multithreaded and multiprocess applications
    Download the technical paper

A dedicated resource to learn about debugging in GDB by industry leader in debugging and founder of Undo

Meet Greg