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

On Thu, 14 Jun 2018 at 19:26, David Blaikie <dblaikie at gmail.com>
wrote:
>
>
>
> 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.
>
That's a good point! I need to check out how we handle that right now.

On Thu, 14 Jun 2018 at 19:29, Pavel Labath <labath at google.com>
wrote:
>
> On Thu, 14 Jun 2018 at 19:26, David Blaikie <dblaikie at gmail.com>
wrote:
> >
> >
> >
> > 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.
> >
>
> 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.

oh, awesome.

Were you using type units? (I imagine that'd make the situation worse -
since the way clang emits DWARF for a type with a member function template
implicit specialization is to emit the type unit without any mention of
this, and to emit the implicit specialization declaration into the stub
type in the CU (that references the type unit)) Without type units I'd be
pretty surprised if you couldn't call the implicit specialization at least
from the CU in which it was instantiated.

On Thu, Jun 14, 2018 at 11:41 AM Pavel Labath <labath at google.com>
wrote:
> On Thu, 14 Jun 2018 at 19:29, Pavel Labath <labath at google.com>
wrote:
> >
> > On Thu, 14 Jun 2018 at 19:26, David Blaikie <dblaikie at
gmail.com> wrote:
> > >
> > >
> > >
> > > 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.
> > >
> >
> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180614/b3e25e2a/attachment.html>