<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">To elaborate a bit more on the issue that is detailed in <a href="https://reviews.llvm.org/rL260308:" class="">https://reviews.llvm.org/rL260308:</a><div class=""><br class=""></div><div class="">There are many clang AST contexts that are used in LLDB:</div><div class="">- one for each lldb_private::Module that contains type definitions as we know them in the module and its symbol vendor</div><div class="">- one for each expression</div><div class="">- one for results of expressions in the lldb_private::Target</div><div class=""><br class=""></div><div class="">As we run expressions we end up copying classes around between the Module ASTs and the expression and Target ASTs. If a class has templated functions, they will only be in the DWARF is a specialization was created and used. If you have a class that looks like:</div><div class=""><br class=""></div><div class=""><div class="">class A {</div><div class=""> A();</div><div class=""> <span style="font-family: "Segoe UI", "Segoe UI Emoji", "Segoe UI Symbol", Lato, "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 13px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255);" class=""><template T> void Foo(T t);</span></div><div class="">};<br class=""></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">And then you have main.cpp that has a "double" and "int" specialization, the class definition in DWARF looks like:</div><div class=""><br class=""></div><div class=""><div class=""><div class="">class A {</div><div class=""> A();</div><div class=""> <span style="font-family: "Segoe UI", "Segoe UI Emoji", "Segoe UI Symbol", Lato, "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 13px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255);" class=""><int> void Foo(int t);</span></div><div class=""> <span style="font-family: "Segoe UI", "Segoe UI Emoji", "Segoe UI Symbol", Lato, "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 13px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255);" class=""><double> void Foo(double t);</span></div><div class="">};</div></div></div><div class=""><br class=""></div><div class="">In another source file, say foo.cpp, if its use of class A doesn't specialize Foo, we have a class definition in DWARF that looks like:</div><div class=""><br class=""></div><div class=""><div class="">class A {</div><div class=""> A();</div><div class="">};</div></div><div class=""><br class=""></div><div class="">With the C++ ODR rules, we can pick any of the "class A" definitions whose qualified name matches ("::A") and has the same decl file + decl line. So when parsing "class A", the DWARF parser will use the accelerator tables to find all instances of "class A", and it will pick on and use it and this will become the one true definition for "class A". This is because DWARF is only emitted for template functions when there is a specialization, that mean any definition of "class A" might or might not include any definition for "<template T> A::Foo(T t);". When we copy types between ASTs, everything is fine if the classes match (no copy needs to be made), but things go wrong if things don't match and this causes expression errors. </div><div class=""><br class=""></div><div class="">Some ways to fix this:</div><div class="">1 - anytime we need _any_ C++ class, we must dig up all definitions and check _all_ DW_TAG_subprogram DIEs within the class to check if any functions have templates and use the class with the most specializations</div><div class="">2 - have DWARF actually emit the template function info all the time as a type T, not a specialization, so we always have the full definition</div><div class=""><div class="">3 - have some accelerator table that explicitly points us to all specializations of class methods given a class name</div></div><div class=""><br class=""></div><div class="">Solution #1 would cause us to dig through all definitions of all C++ classes all the time when parsing DWARF to check if definitions of the classes had template methods. And we would need to find the class that has the most template methods. This would cause us to parse much more of the debug info all of the time and cause increased memory consumption and performance regressions.</div><div class=""><br class=""></div><div class="">Solution #2: not sure if DWARF even supports generic template definitions where the template isn't specialized. And, how would we be able to tell DWARF that emits only specialized templates vs one that has generic definitions...</div><div class=""><br class=""></div><div class="">Solution #3 will require compiler changes.</div><div class=""><br class=""></div><div class="">So this is another vote to support the ability for a given class to be able to locate all of its functions, kind of like we need for Objective C where the class definition doesn't contain all of methods, so we have the .apple_objc section that provides this mapping for us. We would need something similar for C++.</div><div class=""><br class=""></div><div class="">So maybe a possible solution is some sort of section that can specify all of the DIEs related to a class that are not contained in the class hierarchy itself. This would work for Objective C and for C++.</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class=""><br class=""></div><div class="">Greg</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jun 15, 2018, at 3:34 AM, Pavel Labath <<a href="mailto:labath@google.com" class="">labath@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I wasn't using type units (those don't work at all right now).<br class=""><br class="">I've done a bit of digging, and i found this patch<br class=""><<a href="https://reviews.llvm.org/rL260308" class="">https://reviews.llvm.org/rL260308</a>> which explicitly disables template<br class="">member function parsing (though it seems it didn't really work before<br class="">either). The patch contains a quite long explanation of why is this<br class="">not working. I can't say I understand all of it (this is getting a bit<br class="">out of my league), but the core of the issue seems to be that when we<br class="">start to mix classes from two CU which have different sets of<br class="">instantiations in a single expression, things quickly go south because<br class="">the recycled clang ASTs from the two dwarf versions do not match.<br class=""><br class="">For better or worse, it seems gdb is having similar issues as well, as<br class="">I couldn't get it to grok my member template expressions either..<br class=""><br class="">On Thu, 14 Jun 2018 at 19:47, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">oh, awesome.<br class=""><br class="">Were you using type units? (I imagine that'd make the situation worse - since the way clang emits DWARF for a type with a member function template implicit specialization is to emit the type unit without any mention of this, and to emit the implicit specialization declaration into the stub type in the CU (that references the type unit)) Without type units I'd be pretty surprised if you couldn't call the implicit specialization at least from the CU in which it was instantiated.<br class=""><br class="">On Thu, Jun 14, 2018 at 11:41 AM Pavel Labath <<a href="mailto:labath@google.com" class="">labath@google.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">On Thu, 14 Jun 2018 at 19:29, Pavel Labath <<a href="mailto:labath@google.com" class="">labath@google.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">On Thu, 14 Jun 2018 at 19:26, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class=""><br class="">On Thu, Jun 14, 2018 at 11:24 AM Pavel Labath <<a href="mailto:labath@google.com" class="">labath@google.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">On Thu, 14 Jun 2018 at 17:58, Greg Clayton <<a href="mailto:clayborg@gmail.com" class="">clayborg@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class=""><br class="">On Jun 14, 2018, at 9:36 AM, Adrian Prantl <<a href="mailto:aprantl@apple.com" class="">aprantl@apple.com</a>> wrote:<br class=""><br class=""><br class=""><br class="">On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""><br class="">Thank you all. I am going to try to reply to all comments in a single email.<br class=""><br class="">Regarding the .apple_objc idea, I am afraid the situation is not as<br class="">simple as just flipping a switch.<br class=""><br class=""><br class="">Jonas is currently working on adding the support for DWARF5-style Objective-C accelerator tables to LLVM/LLDB/dsymutil. Based on the assumption that DWARF 4 and earlier are unaffected by any of this, I don't think it's necessary to spend any effort of making the transition smooth. I'm fine with having Objective-C on DWARF 5 broken on trunk for two weeks until Jonas is done adding Objective-C support to the DWARF 5 implementation.<br class=""></blockquote><br class="">Ideally, I would like to enable the accelerator tables (possibly with<br class="">a different version number or something) on DWARF 4 too (on non-apple<br class="">targets only). The reason for this is that their absence if causing<br class="">large slowdowns when debugging on non-apple platforms, and I wouldn't<br class="">want to wait for dwarf 5 for that to go away (I mean no disrespect to<br class="">Paul and DWARF 5 effort in general, but even if all of DWARF 5 in llvm<br class="">was done tomorrow, there would still be lldb, which hasn't even begun<br class="">to look at this version).<br class=""><br class="">That said, if you are working on the Objective C support right now,<br class="">then I am happy to wait two weeks or so that we have a full<br class="">implementation from the get-go.<br class=""><br class=""><blockquote type="cite" class="">But, other options may be possible as well. What's not clear to me is<br class="">whether these tables couldn't be replaced by extra information in the<br class="">.debug_info section. It seems to me that these tables are trying to<br class="">work around the issue that there is no straight way to go from a<br class="">DW_TAG_structure type DIE describing an ObjC class to it's methods. If<br class="">these methods (their forward declarations) were be present as children<br class="">of the type DIE (as they are for c++ classes), then these tables may<br class="">not be necessary. But maybe (probably) that has already been<br class="">considered and deemed infeasible for some reason. In any case this<br class="">seemed like a thing best left for people who actually work on ObjC<br class="">support to figure out.<br class=""><br class=""><br class="">That's really a question for Greg or Jim — I don't know why the current representation has the Objective-C methods outside of the structs. One reason might be that an interface's implementation can define more methods than are visible in its public interface in the header file, but we already seem to be aware of this and mark the implementation with DW_AT_APPLE_objc_complete_type. I also am not sure that this is the *only* reason for the objc accelerator table. But I'd like to learn.<br class=""></blockquote><br class="">My observation was based on studying lldb code. The only place where<br class="">the objc table is used is in the AppleDWARFIndex::GetObjCMethods<br class="">function, which is called from<br class="">SymbolFileDWARF::GetObjCMethodDIEOffsets, whose only caller is<br class="">DWARFASTParserClang::CompleteTypeFromDWARF, which seems to have a<br class="">class DIE as an argument. However, if not all declarations of a<br class="">class/interface have access to the full list of methods then this<br class="">might be a problem for the approach I suggested.<br class=""></blockquote><br class=""><br class="">Maybe, but the same is actually true for C++ classes too (see my comments in another reply about implicit specializations of class member templates (and there are a couple of other examples)) - so might be worth considering how those are handled/could be improved, and maybe in fixing those we could improve/normalize the ObjC representation and avoid the need for ObjC tables... maybe.<br class=""><br class=""></blockquote><br class="">That's a good point! I need to check out how we handle that right now.<br class=""></blockquote><br class="">Apparently we handle that very poorly. :/ I wasn't even able to call<br class="">the instantiation which was present in the CU I was stopped in. I<br class="">didn't even get to the part about trying an instantiation from a<br class="">different CU.<br class=""></blockquote></blockquote></div></div></blockquote></div><br class=""></div></body></html>