[PATCH] Treat -g1 as -gline-tables-only

[David Blaikie]

On Mon, Oct 20, 2014 at 1:19 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "David Blaikie" <dblaikie at gmail.com>
> > To: reviews+D5862+public+e7b928154d4d08d9 at reviews.llvm.org
> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "Eric Christopher" <
> echristo at gmail.com>, "llvm cfe" <cfe-commits at cs.uiuc.edu>
> > 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, hfinkel at anl.gov < hfinkel at anl.gov >
> > 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?

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)


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141020/5126d17f/attachment.html>