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