[lldb-dev] [cfe-dev] clang CL breaks LLDB std::string printing

[David Blaikie]

On Fri, Feb 27, 2015 at 9:31 AM, Greg Clayton <clayborg at 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 <emaste at freebsd.org> wrote:
> >
> > On 26 February 2015 at 17:28, Adrian Prantl <aprantl at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150227/4536c7b6/attachment.html>