Fantastic, just one question: Still a bit confused about -g1. From the GCC page, it seems to say that -g1 provides line number tables, is that not the case for the backtraces from glog? Does -g1 have any impact on line numbers within a core dump?
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options > *Level 1 produces minimal information, enough for making backtraces in > parts of the program that you don't plan to debug. This includes > descriptions of functions and external variables, and line number tables, > but no information about local variables.* On Thu, Oct 23, 2014 at 1:47 PM, Cody Maloney <[email protected]> wrote: > 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.* > > >
