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!

_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to