>
> >
> > 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.
>
> Also to be able to call functions on the base class is helpful too for people
> evaluating expressions. So I do realize you guys consider this bloat, but
> this information to us is important for the debug info to be useful.
>
> My suggestion is that if you cannot rely on other parts of the project to be
> built with debug info then you are going to have some /very/ expensive
> intermediate debug info. This is simply a warning - I can't stop you from
> making that choice, but it seems to go against a lot of efforts you, us, and
> everyone have been making to improve the quality (including the size) of
> debug info.
Type uniquing would work for reducing debug info in the final output, but your
goals seem to be to reduce the .o file sizes. We really don't mind the .o file
sizes.
>
> & I'm still rather confused as to how this could be the correct general
> approach because there will always be cases where one translation unit only
> has access to a declaration of a type ("struct foo; foo *f;") - you must be
> able to go looking for the definition of that type for many use cases.
I refer to my comment above: I need to make types Clang AST types from DWARF
that clang will be happy with any not assert() and kill our debugger (lldb or
Xcode) when it becomes unhappy because info is missing from the current file.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
