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

[Nico Weber via cfe-dev]

I'm happy to collect data if someone can tell me how to get the compiler to
always emit DW_AT_linkage_name. My non-working attempt was this:

Index: lib/CodeGen/CGDebugInfo.cpp
===================================================================
--- lib/CodeGen/CGDebugInfo.cpp (revision 309585)
+++ lib/CodeGen/CGDebugInfo.cpp (working copy)
@@ -2861,12 +2861,8 @@
     Flags |= llvm::DINode::FlagPrototyped;
   }
   // No need to replicate the linkage name if it isn't different from the
-  // subprogram name, no need to have it at all unless coverage is enabled
or
-  // debug is set to more than just line tables or extra debug info is
needed.
-  if (LinkageName == Name || (!CGM.getCodeGenOpts().EmitGcovArcs &&
-                              !CGM.getCodeGenOpts().EmitGcovNotes &&
-                              !CGM.getCodeGenOpts().DebugInfoForProfiling
&&
-                              DebugKind <=
codegenoptions::DebugLineTablesOnly))
+  // subprogram name.
+  if (LinkageName == Name)
     LinkageName = StringRef();


On Mon, Jul 31, 2017 at 5:12 PM, Eric Christopher <echristo at gmail.com>
wrote:

>
>
> 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/20170802/4a9eaebe/attachment.html>