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

Adrian Prantl via cfe-dev cfe-dev at lists.llvm.org
Wed Aug 2 13:48:44 PDT 2017


There's a bunch of custom logic in lib/CodeGen/AsmPrinter/DwarfDebug.cpp to gate the emission of linkage names, including a hidden option called -dwarf-linkage-names that you may need to enable.

-- adrian

> On Aug 2, 2017, at 1:44 PM, Nico Weber <thakis at chromium.org> wrote:
> 
> 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 <mailto: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 <mailto:cfe-dev at lists.llvm.org>> wrote:
> On Mon, Jul 31, 2017 at 10:19 AM Nico Weber <thakis at chromium.org <mailto:thakis at chromium.org>> wrote:
> On Wed, Apr 29, 2015 at 4:03 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
> 
>> On Apr 29, 2015, at 12:25 PM, Nico Weber <thakis at chromium.org <mailto: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 <http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120423/056674.html>
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <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/f2449bb3/attachment.html>


More information about the cfe-dev mailing list