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