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

David Blaikie via cfe-commits cfe-commits at lists.llvm.org
Fri Jul 8 12:57:15 PDT 2016


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, 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160708/ec1900f7/attachment.html>


More information about the cfe-commits mailing list