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

[Greg Clayton]

With LLDB we run into more complex issues where if we get conflicting types we might not be able to use a type in an expression because clang will get very unhappy if the definition for a type doesn't match another. This can happen if we have expressions where variables from two different AST's get combined into an expression AST. The type import will succeed if the two types match and fail otherwise.

Debugging in the kernel is broken by this fix because as Adrian said, in kernel kext debugging, the kexts link against external classes from IOKit. It started crashing LLDB because clang asserted when LLDB tried to call setBases() on a CXXRecordDecl with a forward declaration only to a base class. 

When debugging one of these classes, the debug info won't show any base class ivars or methods which will cause any type info to be incomplete for a bunch of tools. dtrace with its CTF which is used on kernel and user debugging can be affected when the types are incomplete.

Greg

On Dec 16, 2013, at 2:44 PM, Adrian Prantl <aprantl at apple.com> 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.
> - 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.
> - Kernel extensions tend to inherit from base classes that are defined in a system framework (I/O Kit works this way for example).
> - For LLDB it is not always possible to tell where a type came from and vtable symbols can get stripped from the symbol table. 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.
> 
> -- adrian
> 
> On Dec 14, 2013, at 1:34 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
>> +Adrian so he can read the backstory/previous thread on this same topic
>> 
>> Adrian - best to start from here so we've all got the previous context to continue this conversation if it needs to be continued.
>> 
>> 
>> On Tue, Oct 15, 2013 at 11:25 AM, Chandler Carruth <chandlerc at google.com> wrote:
>> 
>> On Tue, Oct 15, 2013 at 10:13 AM, David Blaikie <dblaikie at gmail.com> wrote:
>> I think it is reasonable to add a similar flag for clang:
>> 1> gcc has a flag to turn this off, I would imagine there are debuggers out there that don't support this kind of extra searching for types.
>> 2> The possibility that the actual use where we would emit the class def could get stripped
>> 
>> What do you think?
>> 
>> Personally I'm OK implementing the exact spelling of GCC's flag purely for compatibility. Whether or not it's a great idea to disable it seems somewhat less important.
>> 
>> If we wanted to justify it - yes, you're right, you could have a program where only some translation units are built with debug info (for whatever reason) in which case this optimization (and the core -flimit-debug-info optimization) would not be sound.
>> 
>> I would still suggest, as Eric was driving at, that if you /do/ have performance problems due to this change, you investigate those issues rather than simply disabling the optimization. It's a rather valuable size improvement you probably don't want to disable.
>> 
>> Manman, I really don't like the direction this is going.
>> 
>> There are essentially three ways this should proceed:
>> 
>> 1) You have a real problem with this behavior, and can provide a clear, and easily understood explanation for what behavior you need. Without this, it doesn't make sense for the open source project to try to fuzzily match some unstated set of expectations for the debug info produced.
>> 
>> 2) You don't have a real problem, but are worried somewhere someone may run into this issue. While this level of concern is admirable, I think the only way we can proceed is to assume that in the absence of concrete user reports of a problem, the problem doesn't exist. Otherwise, even if a problem does manifest, it will be different from our assumptions and we will have planned poorly.
>> 
>> 3) You have a real problem with this behavior, but cannot (for many legitimate reasons perhaps) discuss exactly what the situation is or why that problem exists, or what precise behavior is needed. In this case, I think the only reasonable approach is for you to maintain an internal patch where all the maintainers of that patch at least have the context to understand why it exists and what it is trying to accomplish.
>> 
>> 
>> Does that make sense? Let's not go down the path of more flags and more varied behavior unless we have #1.
>> 
>> -Chandler
>> 
>