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

[David Blaikie via cfe-dev]

On Mon, Jul 31, 2017 at 10:19 AM Nico Weber <thakis at chromium.org> wrote:

> 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?
>

Would be great to have a prototype & numbers to back up/quantify the
"pretty cheap size-wise" (& good to look at object size as well as final
executable size). & Alexey's no longer working on this stuff - so probably
add kcc or eugenis maybe? That was the original motivation for -gmlt
(symbolized stacks in asan) so they're probably more sensitive to the size
costs.

- Dave


>
>
>>
>>
>> (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/e4f0fabd/attachment.html>