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 <[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. > - 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 <[email protected]> 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 <[email protected]> >> wrote: >> >> On Tue, Oct 15, 2013 at 10:13 AM, David Blaikie <[email protected]> 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 >> > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
