<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="">[reviving an old thread, sorry. Still catching up]<div class=""> <br class=""><div><blockquote type="cite" class=""><div class="">On Apr 29, 2015, at 1:03 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" class="">aprantl@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 29, 2015, at 12:25 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="">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><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></div></blockquote><div><br class=""></div><div>For the sake of backtraces, we could emit only forward declarations of type parameters. This would allow a debugger to show you if a pointer/reference is null, which is a pretty important piece of information when debugging crashes. In this case I think that the location information would be much bigger than the type info. Hard to even give an estimate of what this represents though…</div><div><br class=""></div><div>Fred</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div 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><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><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><div class="">-- adrian</div><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" class="">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120423/056674.html</a></div></div>
</div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></body></html>