[lldb-dev] Stumped on the missing FindExternalLexicalDecls call

Raphael “Teemperor” Isemann via lldb-dev lldb-dev at lists.llvm.org
Mon Dec 2 04:52:51 PST 2019


Sorry for the late reply. Can you share a reproducer for this with upstream LLDB? Otherwise it would also help if you could share a backtrace for when LLDB calls the correct FindExternalLexicalDecls (that way we know if this was coming from just Clang’s normal parsing process or if there is some LLDB specific logic that called that).

In general I am more worried about the fact that we get asked to complete the decl but then not actually complete it. The FindExternalLexicalDecls call may have just hidden that bug.

> On 30. Sep 2019, at 01:44, Nat! via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> 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-called FindExternalLexicalDecls 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!
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev



More information about the lldb-dev mailing list