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

dblaikie at gmail.com dblaikie at gmail.com
Tue Dec 24 11:57:14 PST 2013


>
> In an attempt to wrap up this discussion:
> - this optimization greatly reduces debug info size.
> - but there are scenarios where it is useful for users to disable this
> optimization, and not just on Darwin (e.g., when linking against C++
> libraries that come without debug info)
>
> I hereby propose to go with David’s suggestion above to add an independent
> -femit-class-debug-always option to clang that controls this behavior. I’m
> also volunteering to implement it.
>

1) Eric mentioned some concerns that this flag does something else in GCC -
implementing subtly different semantics for the same flag might not be ideal

2) a broader flag that expresses the "assume I'm only building this
translation unit with debug info" might be a more useful feature - this
would encompass -flimit-debug-info as well (sort of bringing us full circle
to your original proposal) but potentially renaming it to be more
descriptive/actionable for users, and future proof for when we find other
reasons to omit debug info because we know it'll be elsewhere. Though I'm
still not 100% sure of bundling these two things together. It might be the
right thing, but I'm just not sure (mostly I'm not sure if the current
-flimit-debug-info behavior is perfectly correct/sane - we'd need to check
the GDB 7.5 failures that  occur when this flag is enabled, just to ensure
that there aren't any fundamental bugs in the flag that mean even
full-debug-builds would want to disable that optimization without disabling
the vtable opt)




>
> David, it seems as if adding the condition to CreateType() in
> CGDebugInfo.cpp:1473 would do the trick, is that correct?
>

I haven't looked yet, but probably...


>
> cheers,
>   adrian
>
> *runs for cover :-p*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131224/ecb01745/attachment.html>


More information about the cfe-commits mailing list