<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 27, 2015 at 9:31 AM, Greg Clayton <span dir="ltr"><<a href="mailto:clayborg@gmail.com" target="_blank">clayborg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I recommend telling the compiler to not do this using (set -no-fstandalone-debug in OTHER_CFLAGS) if you want to debug with LLDB. If you don't you can DWARF for the following code:<br>
<br>
<br>
class A : public B<br>
{<br>
};<br>
<br>
Where the compiler says "no one used 'B' so I am going to emit a forward declaration for 'B'.</blockquote><div><br>That's not quite the logic used here. Certainly if you use A then you've used B. B may be emitted as a declaration if we know that some other CU will contain the definition (eg: using the vtable optimization - if B has virtual functions, we'll only emit the definition of B where the vtable goes (if B has a key function, this means the debug info definition of B goes in exactly one place: where the definition of the key function appears))<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Then LLDB tries to make class 'A' in a clang AST context and then we try to parse 'B' so we can have 'A' inherit from it and clang of course would assert and kill LLDB (if we actually try to give clang a class 'B' that is a forward declaration as a base class) so LLDB has to lie to keep clang from asserting and just say that 'B' class that contains nothing.<br></blockquote><div><br>Shouldn't it go & find B in another file? The same way you would find the definition of foo if one file contained "struct foo; foo *f;" and the user executed the command "p f->bar"?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The idea was that someone will certainly declare 'B' somewhere in your current source base.</blockquote><div><br>It's more robust than that - the vtable optimization, assuming you compile your whole program with debug info, is guaranteed by the C++ standard (odr use of the class means you have a definition of all the virtual members /somewhere/ in your program). GCC has been doing this optimization for a while now, Clang was doing similar optimizations ("struct foo { }; foo *f;" - we'd only emit the declaration of 'foo' since it was never dereferenced) for a while too - I believe Eric implemented the first versions of that on a suggestion from Chris Lattner, FWIW.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This mostly holds true, but if you have a header file from a shared library that has a C++ class that people might inherit from (like we do in Darwin Kernel Extensions), </blockquote><div><br>If you don't have debug info for that shared library (hence the suggestion to install debug info for the standard library - there are packages for it). Granted I imagine it'll take some finagling to change the Darwin Kernel Extensions build system to build a partial debug info package (presumably you don't want to ship all the debug info for the implementation of that library - for size and privacy reasons).<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">we end up with a class we use for debugging that isn't allowed to see any ivars from "B", nor call any functions declared inside 'B' or any of its subclasses (because we told clang 'B' has no contents when creating the type in the clang AST. So we default to -no-fstandalone-debug for all of Darwin to avoid this.<br>
<span class="HOEnZb"><font color="#888888"><br>
Greg Clayton<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Feb 26, 2015, at 4:35 PM, Ed Maste <<a href="mailto:emaste@freebsd.org">emaste@freebsd.org</a>> wrote:<br>
><br>
> On 26 February 2015 at 17:28, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
>><br>
>>           The -fstandalone-debug option turns off these optimizations.  This is useful when working with 3rd-party libraries that don't come with<br>
>>           debug information.  This is the default on Darwin.  Note that Clang will never emit type information for types that are not referenced at<br>
>>           all by the program.<br>
><br>
> Note that this is also the default on FreeBSD. This might be an<br>
> important point when comparing test results on FreeBSD and Linux since<br>
> they otherwise share a lot of attributes.<br>
><br>
> -Ed<br>
<br>
</div></div></blockquote></div><br></div></div>