[cfe-dev] rfc: Adding a mode to -gline-tables-only to include parameter names, namespaces

Alexey Samsonov vonosmas at gmail.com
Wed Apr 29 13:57:41 PDT 2015


On Wed, Apr 29, 2015 at 12:25 PM, Nico Weber <thakis at chromium.org> wrote:

> Hi,
>
> the motivation for -gline-tables-only was to make debug info much smaller,
> but still include enough to get usable stack frames [1]. We recently tried
> using it in Chromium and discovered that the stack frames aren't all that
> usable: Function parameters disappear, as do function namespaces.
>
> Are there any concerns about adding a mode to -gline-tables-only (or a
> second flag -gline-tables-full, or similar) that includes function
> parameter info and namespace info but still omits most debug info?
>
> (Background: We rely on dsym files to let our crash server symbolize crash
> dumps we get from the wild. dsymutil uses debug info, but it apparently
> crashes if debug info is > 4GB. We hit that recently. So we started using
> -gline-tables-only, but now all our stacks are close to unusable, even
> though the motivation for gline-tables-only was to still have usable
> stacks. We can't easily use symbol names as they get stripped very early in
> our pipeline, and changing that is apparently involved.)
>

I agree that if you don't see fully qualified function names and parameter
types for non-inlined functions, understanding stack traces is hard...
(from my experience, they are especially useful for template functions).
However, -gline-tables-only are kind of designed with assumption that you
*have* the symbol table (I think this was also the case for early GCC -gmlt
proposal), which is not the case in your pipeline.

"Changing that is apparently involved" - what do you mean by this?

I think we need to collect the data: the binary size increase after adding
full linkage names and parameter types for SPEC and for Chromium. If it's
significantly larger than current -gline-tables-only, but way too less than
full debug info (which I believe would be the case), than introducing one
more flag makes sense to me.


>
> Thanks,
> Nico
>
>
> 1:
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120423/056674.html
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>


-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150429/f5ff8356/attachment.html>


More information about the cfe-dev mailing list