[cfe-dev] rfc: Adding a mode to -gline-tables-only to include parameter names, namespaces
Nico Weber via cfe-dev
cfe-dev at lists.llvm.org
Wed Aug 2 15:03:31 PDT 2017
On Wed, Aug 2, 2017 at 4:48 PM, Adrian Prantl <aprantl at apple.com> wrote:
> 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.
>
Thanks. I changed that flag to default to on (in addition to my clang-side
change) but that didn't seem to make a difference:
Index: lib/CodeGen/AsmPrinter/DwarfDebug.cpp
===================================================================
--- lib/CodeGen/AsmPrinter/DwarfDebug.cpp (revision 309585)
+++ lib/CodeGen/AsmPrinter/DwarfDebug.cpp (working copy)
@@ -115,7 +115,7 @@
clEnumValN(AllLinkageNames, "All", "All"),
clEnumValN(AbstractLinkageNames,
"Abstract",
"Abstract subprograms")),
- cl::init(DefaultLinkageNames));
+ cl::init(AllLinkageNames));
static const char *const DWARFGroupName = "dwarf";
static const char *const DWARFGroupDescription = "DWARF Emission";
>
> -- 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>
> 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-Mo
>>>>> n-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/c1a87850/attachment.html>
More information about the cfe-dev
mailing list