On Fri, Jul 8, 2016 at 1:04 PM, Nico Weber <tha...@chromium.org> wrote:
> On Fri, Jul 8, 2016 at 3:57 PM, David Blaikie via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> >> >> On Thu, Jul 7, 2016 at 4:10 PM, Reid Kleckner <r...@google.com> wrote: >> >>> On Thu, Jul 7, 2016 at 3:45 PM, David Blaikie <dblai...@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@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> >> >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits