search for: symbolfiledwarf

...peFromDWARF(DWARFDIE const&, lldb_private::Type*, lldb_private::CompilerType&) (this=0x8c4520, die=..., type=0xc40a50, clang_type=...) at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2036 #2 0x00007f103d04c5e8 in SymbolFileDWARF::CompleteType(lldb_private::CompilerType&) (this=<optimized out>, compiler_type=...) at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1635 #3 0x00007f103ceff9da in lldb_private::ClangASTContext::CompleteTagDecl(void...

...PPLE_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.

...;, > lldb_private::Type*, lldb_private::CompilerType&) (this=0x8c4520, die=..., > type=0xc40a50, clang_type=...) > at > /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2036 > #2 0x00007f103d04c5e8 in > SymbolFileDWARF::CompleteType(lldb_private::CompilerType&) (this=<optimized > out>, compiler_type=...) > at > /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1635 > #3 0x00007f103ceff9da in > lldb_private::ClangASTCont...

...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 f...

...::Type*, lldb_private::CompilerType&) (this=0x8c4520, die=..., >> type=0xc40a50, clang_type=...) >> at >> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2036 >> #2 0x00007f103d04c5e8 in >> SymbolFileDWARF::CompleteType(lldb_private::CompilerType&) (this=<optimized >> out>, compiler_type=...) >> at >> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1635 >> #3 0x00007f103ceff9da in >> lldb_p...

...rator 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...

...e::CompilerType&) (this=0x8c4520, die=..., >>> type=0xc40a50, clang_type=...) >>> at >>> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2036 >>> #2 0x00007f103d04c5e8 in >>> SymbolFileDWARF::CompleteType(lldb_private::CompilerType&) (this=<optimized >>> out>, compiler_type=...) >>> at >>> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1635 >>> #3 0x00007f103ceff9da in...

FYI, this turned out to be an error of omission in LLDB in SymbolFileDWARF, because the case of a non-defining external (i.e. a static member variable) wasn't being handled with a variable lookup to dig up the location. I'll put a patch together for lldb-commits, - Ashok From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Beh...

So, when performing expression evaluation, lldb trips over an assert in clang/lib/AST/RecordLayoutBuilder because ExternalFieldOffsets doesn't contain a FieldDecl that updateExternalFieldOffset expected. I found that the assert occurs when both static and non-static member variables are present. For instance, with the following, the lldb command 'expr my_test.length()' does not

...o 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...

> 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