r274246 - [codeview] Emit qualified display names if -gline-tables-only is on

David Blaikie via cfe-commits cfe-commits at lists.llvm.org
Mon Jul 11 10:35:25 PDT 2016


On Fri, Jul 8, 2016 at 1:04 PM, Nico Weber <thakis at chromium.org> wrote:

> On Fri, Jul 8, 2016 at 3:57 PM, David Blaikie via cfe-commits <
> cfe-commits at lists.llvm.org> wrote:
>
>>
>>
>> On Thu, Jul 7, 2016 at 4:10 PM, Reid Kleckner <rnk at google.com> wrote:
>>
>>> On Thu, Jul 7, 2016 at 3:45 PM, David Blaikie <dblaikie at gmail.com>
>>> wrote:
>>>
>>>> Yeah - is this necessary for CodeView? (does something break, or do you
>>>> just get simple names where you'd prefer full mangled or qualified names)
>>>>
>>>> It was chosen pretty deliberately to do it this way (use unqualified
>>>> names) for gmlt to keep size down. Have you got numbers for the size delta
>>>> for CodeView with this change? I'd really prefer to make the same choice
>>>> for both - it'd seem a bit arbitrary to choose our size optimization based
>>>> on differences in the kind of workloads we happen to have on these two
>>>> platforms.
>>>>
>>>
>>> It's problematic for CodeView because there is no equivalent field like
>>> DW_AT_linkage_name in any of the symbol records. There is only the display
>>> name, which includes scope qualifiers.
>>>
>>> I'm suggesting we reverse our decision for DWARF because our space
>>> saving optimization breaks standard stack dumpers on Linux (gdb and
>>> addr2line),
>>>
>>
>> What breakage are you referring to here?
>>
>> If we're talking about printing out the simple name - that comes up even
>> in llvm-symbolizer if a function is inlined. So I think that's an
>> intentional tradeoff that would apply to CV as well.
>>
>>
>>> and that seems like a Bad Thing. Instead we've told users to user
>>> llvm-symbolizer, which is OK, but kind of crappy.
>>>
>>
>> I imagine that depends on how much it costs us - we've been pretty
>> careful about binary size growth/minimization/etc for a while now
>>
>
> Does this add much size?
>

I believe so, but don't have specific numbers. Alexey made this choice when
it was originally implemented & I believe had the data back then.


> This only makes strings longer and doesn't force emission of types, right?
>

Right


> (From what I understand, types are what makes -fline-tables-only output
> much smaller.)
>

That's the first step, yes, though even gmlt data is in the order of 10s of
% (actually much worse in an optimized build - I think I measure it still
at 200% or somesuch, that was motivating Cary's work on 2 level line
tables), and most of that is strings, so making bigger (much bigger)
strings can have a significant impact.


> Sorry about the uninformed question :-) If that's roughly correct though,
> maybe it'd be good to get an idea how much bigger debug info would get with
> qualified names
>

For sure - that's the basic question: If you're going to change this,
please measure it & make sure the change isn't going to have a drastically
adverse effect on the size of the output.


> -- we can't use -fline-tables-only 'cause they make stacks look very bad,
>

Also I'm curious why your use case/tolerance for "badness" here is
different from what we've been using at Google for ASan, etc, for several
years now. Do you have different requirements/needs here? Then maybe we
need to figure out names for those needs & enshrine them in flags.


> and if qualified names in debug info would give us decent stacks while
> still being smaller,
>

Smaller than full debug info, you mean? Or smaller than something else?


> that'd be cool. (See also thread "rfc: Adding a mode to -gline-tables-only
> to include parameter names, namespaces" from a while ago.)
>
>
>> , so it may be worth the tradeoff to say that llvm-symbolizer produces a
>> better experience on this extra minimized data.
>>
>>
>>> For CodeView, because the linkage name isn't present anywhere, we can't
>>> actually do any better with llvm-symbolizer, and we need the fully scoped
>>> name.
>>>
>>
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160711/ae200c50/attachment-0001.html>


More information about the cfe-commits mailing list