On Thu, 14 Jun 2018 at 19:29, Pavel Labath <lab...@google.com> wrote: > > On Thu, 14 Jun 2018 at 19:26, David Blaikie <dblai...@gmail.com> wrote: > > > > > > > > On Thu, Jun 14, 2018 at 11:24 AM Pavel Labath <lab...@google.com> wrote: > >> > >> On Thu, 14 Jun 2018 at 17:58, Greg Clayton <clayb...@gmail.com> wrote: > >> > > >> > > >> > > >> > On Jun 14, 2018, at 9:36 AM, Adrian Prantl <apra...@apple.com> wrote: > >> > > >> > > >> > > >> > On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev > >> > <llvm-...@lists.llvm.org> wrote: > >> > > >> > Thank you all. I am going to try to reply to all comments in a single > >> > email. > >> > > >> > Regarding the .apple_objc idea, I am afraid the situation is not as > >> > simple as just flipping a switch. > >> > > >> > > >> > 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. > >> > >> Ideally, I would like to enable the accelerator tables (possibly with > >> a different version number or something) on DWARF 4 too (on non-apple > >> targets only). The reason for this is that their absence if causing > >> large slowdowns when debugging on non-apple platforms, and I wouldn't > >> want to wait for dwarf 5 for that to go away (I mean no disrespect to > >> Paul and DWARF 5 effort in general, but even if all of DWARF 5 in llvm > >> was done tomorrow, there would still be lldb, which hasn't even begun > >> to look at this version). > >> > >> That said, if you are working on the Objective C support right now, > >> then I am happy to wait two weeks or so that we have a full > >> implementation from the get-go. > >> > >> > But, other options may be possible as well. What's not clear to me is > >> > whether these tables couldn't be replaced by extra information in the > >> > .debug_info section. It seems to me that these tables are trying to > >> > work around the issue that there is no straight way to go from a > >> > DW_TAG_structure type DIE describing an ObjC class to it's methods. If > >> > these methods (their forward declarations) were be present as children > >> > of the type DIE (as they are for c++ classes), then these tables may > >> > not be necessary. But maybe (probably) that has already been > >> > considered and deemed infeasible for some reason. In any case this > >> > seemed like a thing best left for people who actually work on ObjC > >> > support to figure out. > >> > > >> > > >> > 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. > >> > >> My observation was based on studying lldb code. The only place where > >> the objc table is used is in the AppleDWARFIndex::GetObjCMethods > >> function, which is called from > >> SymbolFileDWARF::GetObjCMethodDIEOffsets, whose only caller is > >> DWARFASTParserClang::CompleteTypeFromDWARF, which seems to have a > >> class DIE as an argument. However, if not all declarations of a > >> class/interface have access to the full list of methods then this > >> might be a problem for the approach I suggested. > > > > > > 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. > > > > That's a good point! I need to check out how we handle that right now.
Apparently we handle that very poorly. :/ I wasn't even able to call the instantiation which was present in the CU I was stopped in. I didn't even get to the part about trying an instantiation from a different CU. _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
