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'. 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.
The idea was that someone will certainly declare 'B' somewhere in your current
source base. 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), 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
