[cfe-dev] rfc: Adding a mode to -gline-tables-only to include parameter names, namespaces
David Blaikie via cfe-dev
cfe-dev at lists.llvm.org
Thu Aug 3 12:57:45 PDT 2017
I think you'd need at least two changes - one in the frontend to add
linkage names and then the backend to use them.
Clang change:
diff --git lib/CodeGen/CGDebugInfo.cpp lib/CodeGen/CGDebugInfo.cpp
index c9aa04815f..f392a24e09 100644
--- lib/CodeGen/CGDebugInfo.cpp
+++ lib/CodeGen/CGDebugInfo.cpp
@@ -2867,7 +2867,7 @@ void CGDebugInfo::collectFunctionDeclProps(GlobalDecl
GD, llvm::DIFile *Unit,
!CGM.getCodeGenOpts().EmitGcovNotes &&
!CGM.getCodeGenOpts().DebugInfoForProfiling
&&
DebugKind <=
codegenoptions::DebugLineTablesOnly))
- LinkageName = StringRef();
+ ; // LinkageName = StringRef();
if (DebugKind >= codegenoptions::LimitedDebugInfo) {
if (const NamespaceDecl *NSDecl =
LLVM change:
diff --git lib/CodeGen/AsmPrinter/DwarfUnit.cpp
lib/CodeGen/AsmPrinter/DwarfUnit.cpp
index 784a1d512c1..c9e4e2ecdac 100644
--- lib/CodeGen/AsmPrinter/DwarfUnit.cpp
+++ lib/CodeGen/AsmPrinter/DwarfUnit.cpp
@@ -1194,7 +1194,9 @@ void DwarfUnit::applySubprogramAttributes(const
DISubprogram *SP, DIE &SPDie,
return;
// Constructors and operators for anonymous aggregates do not have names.
- if (!SP->getName().empty())
+ if (SkipSPAttributes && !SP->getLinkageName().empty())
+ addLinkageName(SPDie, SP->getLinkageName());
+ else if (!SP->getName().empty())
addString(SPDie, dwarf::DW_AT_name, SP->getName());
if (!SkipSPSourceLocation)
Obviously this is just a hack to test - and I might've missed other
necessary changes, but at least a simple test case seems to do what I'd
want:
0x0000000b: DW_TAG_compile_unit [1] *
...
0x0000002a: DW_TAG_subprogram [2]
DW_AT_linkage_name [DW_FORM_strp] (
.debug_str[0x0000006d] = "_Z2f2v")
0x0000002f: DW_TAG_subprogram [3] *
...
DW_AT_linkage_name [DW_FORM_strp] (
.debug_str[0x00000074] = "_Z2f3v")
0x00000040: DW_TAG_inlined_subroutine [4]
DW_AT_abstract_origin [DW_FORM_ref4] (cu + 0x002a =>
{0x0000002a} "_Z2f2v")
...
(built from:
void f1();
__attribute__((always_inline)) void f2() {
f1();
}
void f3() {
f2();
}
)
Might break non-gmlt (though not in any way that's readily apparent to me),
might break backwards compatible (taking existing frontend gmlt-like IR and
building it with this /should/ do the right thing, falling back to the
DW_AT_name in the absence of DW_AT_linkage_name, but untested, etc), etc.
On Wed, Aug 2, 2017 at 3:03 PM Nico Weber via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> 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-Mon-20120423/056674.html
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>>
>>
>> _______________________________________________
> 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/20170803/0375ae9c/attachment.html>
More information about the cfe-dev
mailing list