r188739 - Revert "Revert "Revert "Revert "DebugInfo: Omit debug info for dynamic classes in TUs that do not have the vtable for that class""""

[David Blaikie]

On Wed, Dec 18, 2013 at 1:06 PM, Greg Clayton <gclayton at apple.com> wrote:

>
> On Dec 18, 2013, at 11:34 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
> >
> >
> >
> > On Tue, Dec 17, 2013 at 6:04 PM, Greg Clayton <gclayton at apple.com>
> wrote:
> >
> > On Dec 17, 2013, at 5:38 PM, David Blaikie <dblaikie at gmail.com> wrote:
> >
> > >
> > >
> > >
> > > On Tue, Dec 17, 2013 at 5:34 PM, Greg Clayton <gclayton at apple.com>
> wrote:
> > > >
> > > > >
> > > > > b) -flimit-debug-info is worth, at a guess, somewhere between 1
> and 5%. This vtable optimization is worth closer to 20%. That's /serious/
> bloat to consider accepting.
> > > >
> > > > I don't consider bloat being something that helps us to completely
> define a type that is going to be use when debugging so we can show the
> entire type and its member variables to the user.
> > > >
> > > > How do you know which types are going to be needed by the user? What
> about types that are only declared but not defined in this translation
> unit? ("struct foo; foo *f;")
> > >
> > > I will say again what I have said before: if I need to re-create a
> type form DWARF, then I want all the information I need. In order to
> re-create an opaque "struct foo" for a pointer or reference, a declaration
> is fine. If I need to recreate a class, I want all of the base class info.
> > >
> > > And if someone dereferences that pointer in a debugger expression?
> >
> > Then I have no problems because I was able to create a pointer type that
> clang can deal with. You won't see any data inside of it, but it is a legal
> AST type.
> >
> > Sorry - no, I mean what happens when the user writes an expression in
> the debugger that dereferences that pointer and you need the definition of
> the type?
> >
> > What I'm asking is something as simple as:
> >
> > // client.cpp
> > struct foo;
> > void lib_call(foo *f);
> > void client_code(foo *f) {
> >   lib_call(f);
> > }
> >
> > // library.cpp
> > struct foo {
> >   int i;
> > };
> > void lib_call(foo *f) {
> >   f->i = 3;
> > }
> >
> > Say - and the user is debugging the client, the DWARF compile_unit for
> client.cpp contains only a declaration of 'foo', and the user issues the
> debugger command "p f->i". What do you do? You have to go & find the
> definition in some other compile unit, possibly in another object file or
> even in another shared library, etc.
>
> Yes we do have to go look for another type.


OK


> But this doesn't cause us to have to find this type in order for the type
> to exist in the clang AST from which it comes.


I don't really understand this statement - could you explain it otherwise?


> So yes, this is being dealt with by the debugger, but we still currently
> like to be able to correctly represent the types that are defined within an
> AST by having all of the information we need.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131218/ea2b5934/attachment.html>