[llvm-dev] [lldb-dev] Adding DWARF5 accelerator table support to llvm
Pavel Labath via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 14 11:23:47 PDT 2018
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.
More information about the llvm-dev