[lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

[David Blaikie via lldb-dev]

On Thu, Jun 14, 2018 at 11:24 AM Pavel Labath <labath at google.com> wrote:

> On Thu, 14 Jun 2018 at 17:58, Greg Clayton <clayborg at gmail.com> wrote:
> >
> >
> >
> > On Jun 14, 2018, at 9:36 AM, Adrian Prantl <aprantl at apple.com> wrote:
> >
> >
> >
> > On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev <
> llvm-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180614/cf4daaa6/attachment-0001.html>