search for: dwarfastparserclang

Displaying 9 results from an estimated 9 matches for "dwarfastparserclang".

2016 Mar 26
2
DW_TAG_member extends beyond the bounds error on Linux
...quot;, size_ = 73415312, capacity_ = 140536494141696) } } } (folly::EventBase *) eb = 0x00007fd133cfb888 (apache::thrift::concurrency::ThreadManager *) tm = 0x00007fd133cfb570 I suspect each one may be different root cause. I was able to capture one callstack of a small repro: Breakpoint 1, DWARFASTParserClang::ParseChildMembers (this=0x8c4520, sc=..., parent_die=..., class_clang_type=..., class_language=lldb::eLanguageTypeUnknown, base_classes=..., member_accessibilities=..., member_function_dies=..., delayed_properties=..., default_accessibility=@0x7ffdf3888cac: lldb::eAccessPublic, is_a_class=...
2016 Mar 27
0
DW_TAG_member extends beyond the bounds error on Linux
...1696) > } > } > } > (folly::EventBase *) eb = 0x00007fd133cfb888 > (apache::thrift::concurrency::ThreadManager *) tm = 0x00007fd133cfb570 > > I suspect each one may be different root cause. I was able to capture one > callstack of a small repro: > > Breakpoint 1, DWARFASTParserClang::ParseChildMembers (this=0x8c4520, > sc=..., parent_die=..., class_clang_type=..., > class_language=lldb::eLanguageTypeUnknown, > base_classes=..., member_accessibilities=..., > member_function_dies=..., delayed_properties=..., > default_accessibility=@0x7ffdf3888cac: lldb::e...
2016 Mar 27
1
DW_TAG_member extends beyond the bounds error on Linux
...t; } >> (folly::EventBase *) eb = 0x00007fd133cfb888 >> (apache::thrift::concurrency::ThreadManager *) tm = 0x00007fd133cfb570 >> >> I suspect each one may be different root cause. I was able to capture one >> callstack of a small repro: >> >> Breakpoint 1, DWARFASTParserClang::ParseChildMembers (this=0x8c4520, >> sc=..., parent_die=..., class_clang_type=..., >> class_language=lldb::eLanguageTypeUnknown, >> base_classes=..., member_accessibilities=..., >> member_function_dies=..., delayed_properties=..., >> default_accessibility=@0x7...
2016 Mar 27
0
DW_TAG_member extends beyond the bounds error on Linux
...entBase *) eb = 0x00007fd133cfb888 >>> (apache::thrift::concurrency::ThreadManager *) tm = 0x00007fd133cfb570 >>> >>> I suspect each one may be different root cause. I was able to capture >>> one callstack of a small repro: >>> >>> Breakpoint 1, DWARFASTParserClang::ParseChildMembers (this=0x8c4520, >>> sc=..., parent_die=..., class_clang_type=..., >>> class_language=lldb::eLanguageTypeUnknown, >>> base_classes=..., member_accessibilities=..., >>> member_function_dies=..., delayed_properties=..., >>> defaul...
2018 Jun 14
2
[lldb-dev] Adding DWARF5 accelerator table support to llvm
...nly* 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.
2018 Jun 14
2
[lldb-dev] Adding DWARF5 accelerator table support to llvm
...;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...
2018 Jun 14
2
[lldb-dev] Adding DWARF5 accelerator table support to llvm
...bservation 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. > > > &g...
2018 Jun 15
2
[lldb-dev] Adding DWARF5 accelerator table support to llvm
...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....
2018 Jun 14
3
[lldb-dev] Adding DWARF5 accelerator table support to llvm
> 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