<div dir="ltr">(+llvmdev)<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 14, 2013 at 11:02 AM, 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">Hi David,<br>
<br>
I just bisected a debug info problem we were experiencing down to your legendary commit:<br>
  Revert "Revert "Revert "Revert "DebugInfo: Omit debug info for dynamic classes in TUs that do not have the vtable for that class"”""<br>
<br>
For the following testcase, we don’t emit any debug info whatsoever for the base class A (and only a forward decl for B, but that’s not relevant to my particular problem).<br></blockquote><div><br></div><div>The "we only emit a forward declaration of B" is sort of relevant to this issue, because without a definition of "B" we have no reason to even emit any reference to "A" at all.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> class A<br>
> {<br>
>   virtual bool f() = 0; // This line is the culprit.<br>
>   int lost;<br>
> };<br>
> class B : public A<br>
> {<br>
>   B *g();<br>
> };<br>
> B *B::g() {}<br>
><br>
<br>
My question is: given the commit message — is this intended behavior (based on the assumption that a full definition of A will be in a different module *) or would you consider this a bug, too?<br></blockquote><div><br></div>
<div>This is intended behavior.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">*) This assumption does actually not hold for our problem, but I will spare the gory details for now.<br>
</blockquote><div><br></div><div>It might not hold because you haven't built every part of your program with debug info - yes, that is a known limitation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If it is intended behavior we can try to fix it only in the -fno-limit-debug-info path.<br></blockquote><div><br></div><div>Please refer to the previous thread where Manman brought up a similar concern and Eric, Manman, and myself discussed it - it might be worth picking up from that conversation rather than restarting from scratch.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Personally I believe it better not be intended (we still do emit debug info if the virtual function is commented out), </blockquote><div><br></div><div>That we do emit debug info if the virtual function is commented out doesn't indicate that this is a bug.<br>
<br>The basic premise for the optimization is that if the type is used, its vtable must be emitted /somewhere/ so we only emit the debug info for the type where we emit the vtable information for the type. GCC already implements this optimization, so even if you compile half your code with Clang and half with GCC (or, say, use a GCC-built library such as the standard library) this would still work. It won't work if you compile half your program without debug info.<br>
<br>So that's the premise. This has a hard justification when we're dealing with a concrete type - in C++ all non-pure virtual functions must be defined somewhere in the program. Any program that doesn't meet this requirement has undefined behavior.<br>
<br>But this isn't true of pure virtual functions such as your example. So while it's not a C++ undefined behavior issue, it's still a practical one. Once the program actually has a use of these abstract base classes, their vtables will be emitted and so will the debug info. Until then you have no use of the type and thus no need for the debug info for it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">but I’d like to understand the reasoning behind that change better before I pass judgment ;-)<br>
<br>
And — any intuition about what might be going wrong here?<br>
<br>
thanks!<br>
<span class="HOEnZb"><font color="#888888">  adrian<br>
<br>
</font></span></blockquote></div><br></div></div>