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>
>>>> 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
>>> 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
>> 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?
> (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
>> cfe-commits mailing list
>> cfe-commits at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits