<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 16, 2013 at 8:20 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 5:10 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
<br>
> ><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>
> 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>

><br>
> 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>
</div>Is that even relevant to the problem? </blockquote><div><br></div><div>Because the fact that this change caused a problem is a symptom, not necessarily the underlying issue. Fixing/removing this change isn't necessarily going to solve a broad class of problems your users will hit again if you don't address the underlying problem.<br>
<br>If you're working with -flimit-debug-info by default you'll have other problems (if you have an opaque pointer type, or otherwise handle it without dereferencing it, Clang will emit a declaration and not a definition - prior to my improvements to -flimit-debug-info this would even fire in many more cases causing pointer uses to emit declarations and not definitions (try T *x = new T() with 3.4) - these are issues your users should already be being impacted by) due to the same root cause. </div>
<div><br></div><div>Many ways we have already and will continue to improve debug info size rely on the presence of debug info for the whole program/libraries. Yes, these include changes made by/for Apple dating back years. This isn't a new or surprising thing.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Before we had this change, the above scenario was possible, and users could debug the base class from the 3rd-party library. Now they can't. We should give them an option to make this work again.<br>

<div class="im">><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)<br>

<br>
</div>Sure, if you can control the compiler flags for the entire software stack (and all your library vendors give you debug symbols) and your entire toolchain supports "distributed" DWARF, this works very well.</blockquote>
<div><br>This isn't new... it's common for code in one TU to have a declaration of a type and another TU to have the definition (heck, if it wasn't possible - we wouldn't have declarations in DWARF, we'd just have definitions).<br>
<br>I understand that your kernel situation is special and might not be built to handle these common/practical issues - and should really be fixed but that such fixing is entirely up to your timeline & even if it's a priority it won't be something that can be addressed quickly.<br>
<br>I'm not opposed to a flag here, though understanding the right semantics and use-cases for that flag seems important (& understanding what the costs are too - but again, it's your platform, I can advise you but ultimately I can't stop you choosing whatever you want as the defaults for your platform).<br>
<br>- David </div></div></div></div>