On Fri, Feb 27, 2015 at 9:31 AM, Greg Clayton <clayb...@gmail.com> wrote:
> 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:
>
>
> class A : public B
> {
> };
>
> Where the compiler says "no one used 'B' so I am going to emit a forward
> declaration for 'B'.
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))
> 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.
>
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"?
> The idea was that someone will certainly declare 'B' somewhere in your
> current source base.
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.
> 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),
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).
> 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.
>
> Greg Clayton
>
> > On Feb 26, 2015, at 4:35 PM, Ed Maste <ema...@freebsd.org> wrote:
> >
> > On 26 February 2015 at 17:28, Adrian Prantl <apra...@apple.com> wrote:
> >>
> >> The -fstandalone-debug option turns off these optimizations.
> This is useful when working with 3rd-party libraries that don't come with
> >> debug information. This is the default on Darwin. Note that
> Clang will never emit type information for types that are not referenced at
> >> all by the program.
> >
> > Note that this is also the default on FreeBSD. This might be an
> > important point when comparing test results on FreeBSD and Linux since
> > they otherwise share a lot of attributes.
> >
> > -Ed
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
