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

[Nico Weber via cfe-dev]

On Wed, Apr 29, 2015 at 4:03 PM, Adrian Prantl <aprantl at apple.com> wrote:

>
> On 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?
>
>
> I’m not convinced that the resulting debug info will dramatically smaller
> than the full debug info. The largest bit of the debug info is the type
> information if we are going to emit function parameters that will probably
> pull in the majority of the types in the program.
>

Reviving this a few years later: Just letting clang emit DW_AT_linkage_name
in -g1 would give us qualified stacks, and wouldn't require serializing any
debug info for types from what I understand. gcc does
emit DW_AT_linkage_name in -g1.

We're currently using fdebug-info-for-profiling + -g1 on Android which does
give us DW_AT_linkage_name but also a bunch of other stuff, and we had to
know about the flag. If -g1 just emitted DW_AT_linkage_name by default,
that'd be pretty useful while also being pretty cheap size-wise.

Opinions?


>
>
> (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.
>
>
> The problem here is that neither llvm nor dsymutil understand the 64-bit
> DWARF format. Note that the llvm-dsymutil that is being developed will be
> able to do ODR-based type uniquing for C++, which should also provide
> enough savings to make this go well under the 4GB mark.
>
> 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.)
>
>
>
> -- adrian
>
>
> Thanks,
> Nico
>
>
> 1: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-
> Mon-20120423/056674.html
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170731/5e707766/attachment.html>