*High-level* The information to print file name, line number of both callsite and definition start is all there. 'glog' doesn't use it though. 'glog' looks up the function name by searching the static and dynamic linking symbol tables in the binary. That is always there unless the binary has been stripped. The behavior could be changed setting a symbolize callback (InstallSymbolizeCallback), but we don't do that.
*Details* glog walks the stack frames getting the program counter (PC) at each, finds what file on the filesystem that came from, looks in the static or dynamic symbol table of that file to find the function name, then demangles that function name using the C++ demangling rules. It doesn't look at the debug info in any of those steps, and doesn't print out line numbers. With -g1 it is possible to print out line numbers of all the call site in addition to the line number of the function declaration. The backtraces we print don't do that. I don't know of any commonly used backtrace library which does. Some tools like LLVM/Clang's 'llvm-symbolize' can/do. Current backtraces: @ 0x7f042c579d8d google::LogMessage::Fail() @ 0x7f042c57dd77 google::LogMessage::SendToLog() @ 0x7f042c57c674 google::LogMessage::Flush() @ 0x7f042c57c8a6 google::LogMessageFatal::~LogMessageFatal() @ 0x7f042c21db8a mesos::internal::slave::Slave::reregistered() @ 0x7f042c276c1d ProtobufProcess<>::handler1<>() @ 0x7f042c24560a std::tr1::_Function_handler<>::_M_invoke() @ 0x7f042c27702b ProtobufProcess<>::visit() @ 0x7f042c46baf4 process::ProcessManager::resume() @ 0x7f042c46c54f process::schedule() @ 0x7f042bbd983d start_thread @ 0x7f042a5bbf8d clone You can use llvm-symbolize to translate those address to file names + line numbers if you have a '-g1' binary. On Thu, Oct 23, 2014 at 5:38 PM, Benjamin Mahler <[email protected]> wrote: > 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.* > > > > > >
