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.
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
