----- Original Message ----- > From: "David Blaikie" <[email protected]> > To: "Hal Finkel" <[email protected]> > Cc: "Eric Christopher" <[email protected]>, "llvm cfe" > <[email protected]>, > [email protected] > Sent: Monday, October 20, 2014 3:38:39 PM > Subject: Re: [PATCH] Treat -g1 as -gline-tables-only > > On Mon, Oct 20, 2014 at 1:19 PM, Hal Finkel < [email protected] > > wrote: > > ----- Original Message ----- > > From: "David Blaikie" < [email protected] > > > To: [email protected] > > Cc: "Hal Finkel" < [email protected] >, "Eric Christopher" < > > [email protected] >, "llvm cfe" < [email protected] > > > Sent: Sunday, October 19, 2014 8:35:13 PM > > Subject: Re: [PATCH] Treat -g1 as -gline-tables-only > > > > On Sun, Oct 19, 2014 at 4:06 PM, [email protected] < [email protected] > > > > > wrote: > > > > > > Hi echristo, dblaikie, > > > > To follow-up on this thread on cfe-dev: > > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-October/039649.html > > > > -g1 on gcc (and also IBM's xlc) are documented to be very similar > > to > > -gline-tables-only. Our -gline-tables-only might still be more > > verbose than -g1 on other compilers, but currently we treat -g1 as > > -g, and so we're producing much more debug info at -g1 than > > everybody else. Treating -g1 as -gline-tables-only brings us much > > closer to what everyone else is doing. > > > > > > A follow-up: which user(s) did you have who hit problems with -g1? > > Do > > you know what /they/ want when they specify -g1? It'd be useful to > > at least have some actual user of -g1 with a documented use case so > > we know if we're meeting their needs, etc. > > Okay, this is how the issue came up... > > At our supercomputing facility, we have three compilers: IBM's xlc, > gcc and clang (all customized for the BG/Q). The facility is > responsible for analyzing all job failures, both for our own > purposes, and to help our users diagnose and fix problems with their > code (when their code is at fault). When running tens of thousands > of processes in parallel, it is not feasible to generate full core > files for every crash from every process (that could be hundreds of > TB of data per crash), and so our kernel generates "light weight" > core files. For the most part, these core files contain only enough > information to reconstruct the stack backtrace, but not enough for > interactive debugging. Nevertheless, as you might imagine, the > backtraces themselves are very useful (compared to nothing), and are > much more useful with line-table information (especially for C++ > code). > > > Do you happen to know if your backtracing/symbolication uses inlining > information to improve the quality?
It uses whatever advanced technology is made available by addr2line -C -e <filename> <addr> ;) > > If so, it doesn't look like XLC will help you there, and neither will > GCC, but Clang will. > > Beyond that, for basic, non-inlining backtraces, -g1 in xlc and gcc > (and as you've patched here in Clang) will all provide the basic > line table good for symbolication. > > Arguably we could have -g1 do something more like xlc to save on > space more if non-inlined symbolication is what users of this > feature need - so if you find the debug info is too big even with > this new -g1 you're proposing, we can chat about what to do there. > (note that the debug info with Clang's -gmlt (this new -g1) is > substantially bigger in optimized binaries (with lots of inlining) > so if you're assessing the build impact of this feature, be sure to > test it on whatever build modes you care about, not just -O0) Certainly will do. Thanks again, Hal > > > One proposal we've been evaluating is automatically adding -g1 to all > compiles on the system, so that we can always get line-table > information for use with these light-weight core files. In order to > add this to every compile, there needs to be only a small effect on > compile/link times (the smaller the better -- and the line table > information is really all we need). The fact that clang treats -g1 > like -g (instead of generating much less debugging info like gcc/xlc > do) was discovered in the process of evaluating this proposal. > > > > I could obviously just "fix" this locally, but it seemed like it > might be generally desirable behavior to better match gcc/xlc in > this case (thus the thread on cfe-dev, etc.) > > > Nah, seems fine as a notion. > > Please commit > > - David > > > > Thanks again, > Hal > > > > > > > > > > > http://reviews.llvm.org/D5862 > > > > Files: > > lib/Driver/Tools.cpp > > test/Driver/debug-options.c > > > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
