[lldb-dev] Stumped on the missing FindExternalLexicalDecls call
Nat! via lldb-dev
lldb-dev at lists.llvm.org
Sun Sep 29 16:44:46 PDT 2019
After a long wild goose chase, that didn't get me nowhere I am looking
for some help.
Basically what's not working for me anymore in 9.0.0 is the "expression"
printer `p` (not `po`).
Technically that is a JIT compiled Objective-C category method, where
the resulting binary code gets extracted from and executed in the
executable.
When I enabled `log enable lldb expr` on 8.0.0 I see the following on `p
*self`:
```
mulle-lldb Frame has language of type objective-c
mulle-lldb Using x86_64--linux as the target triple
mulle-lldb Using SIMD alignment: 128
mulle-lldb Target datalayout string:
'e-m:e-i64:64-f80:128-n8:16:32:64-S128'
mulle-lldb Target ABI: ''
mulle-lldb Target vector alignment: 0
mulle-lldb ClangExpressionDeclMap::FindExternalVisibleDecls[7] for
'$__lldb_objc_class' in a 'TranslationUnit'
mulle-lldb CEDM::FEVD[7] Searching the root namespace
mulle-lldb FEVD[7] Adding type for $__lldb_objc_class: Foo
mulle-lldb [ClangASTImporter] Imported
(ObjCInterfaceDecl*)0x14e76c0, named Foo (from (Decl*)0x7fda7801b558),
metadata 0xffffffff0000002a
mulle-lldb [ClangASTImporter] Decl has no origin information
in (ASTContext*)0x7fda78009bf0
mulle-lldb [ClangASTImporter] To is an ObjCInterfaceDecl -
attributes Lexical Visible HasDefinition
mulle-lldb ClangASTSource::FindExternalVisibleDecls[7] on
(ASTContext*)0x13e5610 for '$__lldb_objc_class' in a 'TranslationUnit'
mulle-lldb CAS::FEVD[7] Searching the root namespace
mulle-lldb ClangExpressionDeclMap::FindExternalVisibleDecls[8] for
'$__lldb_arg' in a 'TranslationUnit'
mulle-lldb CEDM::FEVD[8] Searching the root namespace
mulle-lldb ClangASTSource::FindExternalVisibleDecls[8] on
(ASTContext*)0x13e5610 for '$__lldb_arg' in a 'TranslationUnit'
mulle-lldb CAS::FEVD[8] Searching the root namespace
mulle-lldb FindExternalLexicalDecls[6] on (ASTContext*)0x13e5610
in 'Foo' (ObjCInterfaceDecl*)0x14e76c0
mulle-lldb FELD[6] Original decl (ASTContext*)0x7fda78009bf0
(Decl*)0x7fda7801b558:
mulle-lldb @interface Foo
mulle-lldb @end
mulle-lldb FELD[6] Adding [to ObjCInterfaceDecl Foo] lexical
ObjCMethodDecl + (void)main
mulle-lldb [ClangASTImporter] Imported
(ObjCMethodDecl*)0x14e7dd8, named main (from (Decl*)0x7fda7801b670),
metadata 0xffffffff00000033
mulle-lldb [ClangASTImporter] Decl has no origin information
in (ASTContext*)0x7fda78009bf0
mulle-lldb Last statement is an lvalue with type: Class
mulle-lldb Found function +[Foo($__lldb_category) $__lldb_expr:]
for $__lldb_expr
mulle-lldb PrepareForExecution - Current expression language is
objective-c
```
Here is some stipulation: `[ClangASTImporter] Imported
(ObjCInterfaceDecl*)0x14e76c0, named Foo (from (Decl*)0x7fda7801b558),
metadata 0xffffffff0000002a` is the ObjcInterfaceDecl as derived from
DWARF but not yet filled in with the complete instance variable
information. The FindExternalLexicalDecls then completes the declaration
from DWARF info.
This is what happens in 9.0.0:
```
mulle-lldb Frame has language of type objective-c
mulle-lldb Using x86_64-unknown-linux-gnu as the target triple
mulle-lldb Using SIMD alignment: 128
mulle-lldb Target datalayout string:
'e-m:e-i64:64-f80:128-n8:16:32:64-S128'
mulle-lldb Target ABI: ''
mulle-lldb Target vector alignment: 0
mulle-lldb ClangExpressionDeclMap::FindExternalVisibleDecls[5] for
'$__lldb_objc_class' in a 'TranslationUnit'
mulle-lldb CEDM::FEVD[5] Searching the root namespace
mulle-lldb FEVD[5] Adding type for $__lldb_objc_class: Foo
mulle-lldb [ClangASTImporter] Imported
(ObjCInterfaceDecl*)0xfe58b0, named Foo (from (Decl*)0x7f6f40047038),
metadata 0x7fffffff00001672
mulle-lldb [ClangASTImporter] Decl has no origin information
in (ASTContext*)0x7f6f40005590
mulle-lldb [ClangASTImporter] To is an ObjCInterfaceDecl -
attributes Lexical Visible
mulle-lldb ClangASTSource::FindExternalVisibleDecls[4] on
(ASTContext*)0x1051e20 for '$__lldb_objc_class' in a 'TranslationUnit'
mulle-lldb CAS::FEVD[4] Searching the root namespace
mulle-lldb [CompleteObjCInterfaceDecl] on
(ASTContext*)0x1051e20 Completing an ObjCInterfaceDecl named Foo
mulle-lldb [COID] Before:
mulle-lldb [COID] @class Foo;
mulle-lldb [COID] After:
mulle-lldb [COID] @class Foo;
mulle-lldb ClangExpressionDeclMap::FindExternalVisibleDecls[6] for
'$__lldb_arg' in a 'TranslationUnit'
mulle-lldb CEDM::FEVD[6] Searching the root namespace
mulle-lldb ClangASTSource::FindExternalVisibleDecls[5] on
(ASTContext*)0x1051e20 for '$__lldb_arg' in a 'TranslationUnit'
mulle-lldb CAS::FEVD[5] Searching the root namespace
mulle-lldb [CompleteObjCInterfaceDecl] on
(ASTContext*)0x1051e20 Completing an ObjCInterfaceDecl named Foo
mulle-lldb [COID] Before:
mulle-lldb [COID] @class Foo;
mulle-lldb [COID] After:
mulle-lldb [COID] @class Foo;
mulle-lldb Last statement is an lvalue with type: Class
mulle-lldb [ClangASTImporter] Forgetting destination
(ASTContext*)0x1051e20
mulle-lldb [ClangASTImporter] Forgetting source->dest
(ASTContext*)0x1051e20->(ASTContext*)0x7f6f4005ed50
error: cannot define category for undefined class 'Foo'
forward declaration of class here
error: cannot find interface declaration for 'Foo'
forward declaration of class here
```
As you can see the "incomplete import" step for `Foo` succeeds but the
`FindExternalLexicalDecls` just doesn't happen any more, and I'd like to
know, why this might be the case. And how I can possibly remedy this.
My lldb is a slightly modified version of the llvm lldb, with an added
ObjCRuntime Plugin and some small changes in the way DWARF information
is convered to method declarations. But the
not-calledFindExternalLexicalDecls is also reproducable with an
unadulterated lldb. The Objective-C variant in question is a v1
compatible variant of Objective-C. The Plugin itself does not create any
Decls.
Ciao
Nat!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190930/61a2eee1/attachment.html>
More information about the lldb-dev
mailing list