<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 16, 2013 at 4:42 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Dec 16, 2013, at 14:55, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
<br>
><br>
><br>
><br>
> On Mon, Dec 16, 2013 at 2:44 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
> Hi Chandler and David,<br>
><br>
> unfortunately it looks more like case 1. This optimization breaks several assumptions that tools in our software stack depend on.<br>
><br>
> It's a fairly substantial debug info size savings that seems worth investigating whether you can keep it enabled at least in<br>
<br>
</div>this sentence is cut off in the middle :-)<br>
But extrapolating from that: For (LTO) builds we still have type uniquing which gets us the same kind of improvement and more.<br></blockquote><div><br></div><div>Sure - in the final linked debug info, but you'll still suffer a disk/build-time penalty for all that & that only applies to LTO.<br>
<br>I was trying to say "keep it enabled at least in some cases" - ie: look at the cases where you're having trouble with this optimization and see if a more targetted approach to addressing those particular use cases can be employed.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> - For example, it breaks dtrace, which on Darwin relies on being able to pull the (complete) CTF info (compact C type format) out of the DWARF in the .dSYM for a given module.<br>
><br>
> I take it you're already using -fno-limit-debug-info for these scenarios, then? (are you using -flimit-debug-info at all?)<br>
<br>
</div>Currently I believe that -flimit-debug-info is the default on Darwin. I don’t know what you mean by “these scenarios”; “we" can’t anticipate what programs users may want to probe using dtrace.<br></blockquote>
<div><br></div><div>Can dtrace be improved to read the rest of the debug info/can you ship debug info for the libraries in question?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">><br>
> - Kernel extensions tend to inherit from base classes that are defined in a system framework (I/O Kit works this way for example).<br>
><br>
> And the library where the base class is defined isn't built with debug info as a matter of course? Is that solvable at all?<br>
<br>
</div>Of course — by not performing this optimization, the type info for the base class ends up in the user’s .o file, as it always used to. This is just one example to make the "user code that inherits from base classes defined in 3rd-party C++ library” scenario I mentioned yesterday more real.<br>
</blockquote><div><br></div><div>I meant is it possible to solve the problem of "this library is built without debug info" - in my experience libraries generally offer a dbg variant of the library for this purpose. Is this a possible solution to your problem? Or are you unable to ship the libraries in question with appropriate debug info & must rely on the user's builds to contain sufficient info?<br>
<br>(notice that I first discovered this GCC optimization looking at basic_ifstream - the stream base is polymorphic and has an out-of-line vtable - this optimization allows code using C++ streams to avoid emitting /tons/ of stream related debug info and rely on it being present in the debug build of the standard library)</div>
</div></div></div>