On Wed, Oct 22, 2014 at 4:09 PM, Dominic Hamon <[email protected]> wrote:
> 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. > I want to note here, -g1 *has no impact* on backtraces. At least glog backtraces will be exactly the same (And from what I can tell that is the only backtrace system we use). Most people will be unhappy if they try running gdb on a -g1 binary, in that no local variables will be inspectable. You can get line numbers and external variables, but that is it. '-g1' is primarily useful if you are running code analysis tools / helpers (AddressSanitizer, ThreadSanitizer, etc). > 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.* >
