Thanks for the thorough breakdown. I think we should have -O0 -g1 for a default as people building will be expecting good backtraces and to be able to run gdb without a recompile. Packaged builds should enable the release setting (-O2 -g0) so that end users get the fastest/smallest builds.
On Wed, Oct 22, 2014 at 4:02 PM, Cody Maloney <[email protected]> wrote: > I want to make our standard build flags match what other projects tend to > supply. In submitting a patch for this ( > https://reviews.apache.org/r/26426/), Ben Mahler asked for some numbers > as to what effect the different combinations of flags have. > > Attached in testing_methodology.txt is the steps, build host config (AWS > c3.2xlarge running Ubuntu 14.04 64 bit, fresh install), and full results. > With each configuration I collected both the file size, as well as time to > build everything in mesos (But not actually run the testcases). The > attached diff was applied to remove the always appending '-O2 -g2' to > CXXFLAGS when --disable-optimize isn't specified. > > *My Suggestions:* > Current default: -O2 -g2 (NOTE: -g2 is undocumented by GCC) > Suggested new default: > -O0 (my preference) or -O0 -g1 for developers > -O2 for release > > I think -O0 should be the general default, which is overwritten whenever > CXXFLAGS is specified at any level (So that distribution packaging works > correctly). This gives us fast, small developer builds. And makes packaging > builds work correctly. Hand constructing packages I can add a '--release' > or '--mode=release' flag to configure so they get the right flags (If you > package natively for common distros CXXFLAGS and the like will be > automatically set to that distribution's packaging guidelines). > > *What about backtraces? Coredumps? Will they be harder to read without a > '-g' flag?* > *NO. *Nothing inside of mesos will have a worse experience now. Only if > you attach external programs which actually use dwarf debug information > (GDB, AddressSanitizer, ThreadSanitizer, etc), will enabling debug > information (-g{1,3}) change their output significantly. For those cases, > we can add a '--debug' flag. which will cause the debug info to be emitted > (Or you can manually specify CXXFLAGS to provide the debug info. Everything > internal (Such as the glog backtraces on fatal messages), simply looks up > the function name and demangles it. The callsite line / file is passed by > macro and as a result always there. > > More thorough information / explanation: > https://reviews.apache.org/r/26426/#comment_rc96919-56878 > > *Useful References:* > GCC Debug levels (Look at '-glevel'): > https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options > > Why debug info gets big (and bigger), it's effect on comple time: > https://gcc.gnu.org/wiki/DebugFission > -- Dominic Hamon | @mrdo | Twitter *There are no bad ideas; only good ideas that go horribly wrong.*
