<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">-- adrian</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 2, 2017, at 1:44 PM, Nico Weber <<a href="mailto:thakis@chromium.org" class="">thakis@chromium.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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:<div class=""><br class=""></div><div class=""><div class="">Index: lib/CodeGen/CGDebugInfo.cpp</div><div class="">===================================================================</div><div class="">--- lib/CodeGen/CGDebugInfo.cpp<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>(revision 309585)</div><div class="">+++ lib/CodeGen/CGDebugInfo.cpp<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>(working copy)</div><div class="">@@ -2861,12 +2861,8 @@</div><div class=""> Flags |= llvm::DINode::FlagPrototyped;</div><div class=""> }</div><div class=""> // No need to replicate the linkage name if it isn't different from the</div><div class="">- // subprogram name, no need to have it at all unless coverage is enabled or</div><div class="">- // debug is set to more than just line tables or extra debug info is needed.</div><div class="">- if (LinkageName == Name || (!CGM.getCodeGenOpts().EmitGcovArcs &&</div><div class="">- !CGM.getCodeGenOpts().EmitGcovNotes &&</div><div class="">- !CGM.getCodeGenOpts().DebugInfoForProfiling &&</div><div class="">- DebugKind <= codegenoptions::DebugLineTablesOnly))</div><div class="">+ // subprogram name.</div><div class="">+ if (LinkageName == Name)</div><div class=""> LinkageName = StringRef();</div></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Jul 31, 2017 at 5:12 PM, Eric Christopher <span dir="ltr" class=""><<a href="mailto:echristo@gmail.com" target="_blank" class="">echristo@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><span class=""><div dir="ltr" class="">On Mon, Jul 31, 2017 at 10:30 AM David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jul 31, 2017 at 10:19 AM Nico Weber <<a href="mailto:thakis@chromium.org" target="_blank" class="">thakis@chromium.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 29, 2015 at 4:03 PM, Adrian Prantl <span dir="ltr" class=""><<a href="mailto:aprantl@apple.com" target="_blank" class="">aprantl@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class="m_-4265792129872045252m_1924920045927647317m_-4674907118823140343gmail-"><blockquote type="cite" class=""><div class="">On Apr 29, 2015, at 12:25 PM, Nico Weber <<a href="mailto:thakis@chromium.org" target="_blank" class="">thakis@chromium.org</a>> wrote:</div><br class="m_-4265792129872045252m_1924920045927647317m_-4674907118823140343gmail-m_-9000920310424982279Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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?</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class="">We're currently using fdebug-info-for-<wbr class="">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.</div><div class=""><br class=""></div><div class="">Opinions?</div></div></div></div></blockquote></div></div><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class="">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.<br class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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.</div><div class=""><br class=""></div><div class="">-eric</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">- Dave<br class=""> </div></div></div><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class="m_-4265792129872045252m_1924920045927647317m_-4674907118823140343gmail-"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">(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. </div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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. </div><span class="m_-4265792129872045252m_1924920045927647317m_-4674907118823140343gmail-"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">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.)</div></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div></span><span class="m_-4265792129872045252m_1924920045927647317m_-4674907118823140343gmail-HOEnZb"><font color="#888888" class=""><div class="">-- adrian</div></font></span><span class="m_-4265792129872045252m_1924920045927647317m_-4674907118823140343gmail-"><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Nico</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">1: <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120423/056674.html" target="_blank" class="">http://lists.cs.uiuc.edu/<wbr class="">pipermail/cfe-commits/Week-of-<wbr class="">Mon-20120423/056674.html</a></div></div>
</div></blockquote></span></div><br class=""></div></blockquote></div><br class=""></div></div>
</blockquote></div></div></span>
______________________________<wbr class="">_________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div></div>
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>