>From the standard point of view it does appear that this trick is legal btw:
"A debugging information entry that represents a non-defining or otherwise incomplete declaration of a program entity has a DW_AT_declaration attribute, which is a flag..." so this is merely being labeled as an incomplete type and is valid dwarf. I'm not a fan of it necessarily, but a 20% win per object file is huge. I'd honestly prefer that struct types worked more like namespaces, but that's a rather serious change to the standard. -eric On Mon Dec 16 2013 at 4:44:25 PM, Adrian Prantl <[email protected]> wrote: > > On Dec 16, 2013, at 14:55, David Blaikie <[email protected]> wrote: > > > > > > > > > On Mon, Dec 16, 2013 at 2:44 PM, Adrian Prantl <[email protected]> > wrote: > > Hi Chandler and David, > > > > unfortunately it looks more like case 1. This optimization breaks > several assumptions that tools in our software stack depend on. > > > > It's a fairly substantial debug info size savings that seems worth > investigating whether you can keep it enabled at least in > > this sentence is cut off in the middle :-) > But extrapolating from that: For (LTO) builds we still have type uniquing > which gets us the same kind of improvement and more. > > > > > - For example, it breaks dtrace, which on Darwin relies on being able to > pull the (complete) CTF info (compact C type format) out of the DWARF in > the .dSYM for a given module. > > > > I take it you're already using -fno-limit-debug-info for these > scenarios, then? (are you using -flimit-debug-info at all?) > > Currently I believe that -flimit-debug-info is the default on Darwin. I > don’t know what you mean by “these scenarios”; “we" can’t anticipate what > programs users may want to probe using dtrace. > > > > - Kernel extensions tend to inherit from base classes that are defined > in a system framework (I/O Kit works this way for example). > > > > And the library where the base class is defined isn't built with debug > info as a matter of course? Is that solvable at all? > > Of course — by not performing this optimization, the type info for the > base class ends up in the user’s .o file, as it always used to. This is > just one example to make the "user code that inherits from base classes > defined in 3rd-party C++ library” scenario I mentioned yesterday more real. > > > > - For LLDB it is not always possible to tell where a type came from and > vtable symbols can get stripped from the symbol table. > > > > I don't understand the relevance of vtable stripping to this issue - > could you explain it to me? (are you suggesting that the vtable symbol > lookup could/would be used to locate the right object file/dsym to load the > full definition of the type? I'm only vaguely familiar with such an idea > and didn't realize you could get from the symbol back to the object file > and thus to the dsym). > > > > If it can’t layout the type, the expression evaluator doesn’t work. > > > > We do need to have the option to turn this optimization off; preferably > we would make off the default for Darwin. Other platforms that use LLDB as > their primary debugger may want to do the same thing. > > > > Is there no way to fix LLDB so it actually loads in the other dsyms and > finds the full definition of the type? It would seem unfortunate to have > such a bloated debug info format (not only for this optimization, but for > the existing -flimit-debug-info optimizations and anything else we might > think of in the future where we can ensure that some debug info is already > availabel in another file). > > I think Greg commented on the LLDB side of things already. > > -- adrian > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
