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

[Eric Christopher via cfe-dev]

On Mon, Jul 31, 2017 at 10:30 AM David Blaikie via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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.
>
>
IIRC mostly it's a lot of strings in the output. That said, I agree that it
would be very useful and we should probably contemplate it as just "part of
the expense of C++ and stack traces" here. Be good to get numbers first so
we know what we're getting ourselves into though.

-eric


> - 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
>>>
>>>
>>>
>> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170731/f6a9e4f9/attachment.html>