[lldb][test] Add test-coverage for DW_AT_APPLE_objc_complete_type parsing

[Michael137]

When given a DIE for an Objective-C interface (which doesn't have a DW_AT_APPLE_objc_complete_type), the DWARFASTParserClang will try to find the DIE which corresponds to the implementation to complete the interface DIE. The code is here:

llvm-project/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Lines 1718 to 1738 in d2e7ee7

	if ((attrs.class_language == eLanguageTypeObjC ||
	attrs.class_language == eLanguageTypeObjC_plus_plus) &&
	!attrs.is_complete_objc_class &&
	die.Supports_DW_AT_APPLE_objc_complete_type()) {
	// We have a valid eSymbolTypeObjCClass class symbol whose name
	// matches the current objective C class that we are trying to find
	// and this DIE isn't the complete definition (we checked
	// is_complete_objc_class above and know it is false), so the real
	// definition is in here somewhere
	TypeSP type_sp =
	dwarf->FindCompleteObjCDefinitionTypeForDIE(die, attrs.name, true);
	if (!type_sp) {
	SymbolFileDWARFDebugMap *debug_map_symfile = dwarf->GetDebugMapSymfile();
	if (debug_map_symfile) {
	// We weren't able to find a full declaration in this DWARF,
	// see if we have a declaration anywhere else...
	type_sp = debug_map_symfile->FindCompleteObjCDefinitionTypeForDIE(
	die, attrs.name, true);
	}
	}

However, this was currently not exercised in our test-suite (removing the code above didn't fail any LLDB test).

This patch adds a test which exercises this codepath (it will fail if we don't fetch the implementation DIE in the DWARFASTParserClang).

Something that's not currently clear to me is why frame var *f succeeds even without the DW_AT_APPLE_objc_complete_type infrastructure. If it's using the ObjC runtime, we should make expr do the same, in which case we can remove this code from DWARFASTParserClang.

[llvmbot]

@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)

Changes

When given a DIE for an Objective-C interface (which doesn't have a DW_AT_APPLE_objc_complete_type), the DWARFASTParserClang will try to find the DIE which corresponds to the implementation to complete the interface DIE. The code is here:

llvm-project/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Lines 1718 to 1738 in d2e7ee7

	if ((attrs.class_language == eLanguageTypeObjC ||
	attrs.class_language == eLanguageTypeObjC_plus_plus) &&
	!attrs.is_complete_objc_class &&
	die.Supports_DW_AT_APPLE_objc_complete_type()) {
	// We have a valid eSymbolTypeObjCClass class symbol whose name
	// matches the current objective C class that we are trying to find
	// and this DIE isn't the complete definition (we checked
	// is_complete_objc_class above and know it is false), so the real
	// definition is in here somewhere
	TypeSP type_sp =
	dwarf->FindCompleteObjCDefinitionTypeForDIE(die, attrs.name, true);
	if (!type_sp) {
	SymbolFileDWARFDebugMap *debug_map_symfile = dwarf->GetDebugMapSymfile();
	if (debug_map_symfile) {
	// We weren't able to find a full declaration in this DWARF,
	// see if we have a declaration anywhere else...
	type_sp = debug_map_symfile->FindCompleteObjCDefinitionTypeForDIE(
	die, attrs.name, true);
	}
	}

However, this was currently not exercised in our test-suite (removing the code above didn't fail any LLDB test).

This patch adds a test which exercises this codepath (it will fail if we don't fetch the implementation DIE in the DWARFASTParserClang).

Something that's not currently clear to me is why frame var *f succeeds even without the DW_AT_APPLE_objc_complete_type infrastructure. If it's using the ObjC runtime, which should make expr do the same, in which case we can remove this code from DWARFASTParserClang.

---

Full diff: https://github.com/llvm/llvm-project/pull/120279.diff

1 Files Affected:

• (added) lldb/test/Shell/Expr/TestObjCHiddenIvars.test (+63)

diff --git a/lldb/test/Shell/Expr/TestObjCHiddenIvars.test b/lldb/test/Shell/Expr/TestObjCHiddenIvars.test
new file mode 100644
index 00000000000000..724a17fb7e2b8c
--- /dev/null
+++ b/lldb/test/Shell/Expr/TestObjCHiddenIvars.test
@@ -0,0 +1,63 @@
+# Tests that LLDB correctly finds the implementation
+# DIE (with a `DW_AT_APPLE_objc_complete_type`)
+# given an interface DIE (without said attribute).
+#
+# RUN: split-file %s %t
+# RUN: %clangxx_host %t/lib.m  -c -g -o %t/lib.o
+# RUN: %clangxx_host %t/main.m -c -g -o %t/main.o
+# RUN: %clangxx_host %t/main.o %t/lib.o -o %t/a.out -framework Foundation
+#
+# RUN: %lldb %t/a.out \
+# RUN:       -o "breakpoint set -p 'return' -X main" \
+# RUN:       -o run \
+# RUN:       -o "expression *f" \
+# RUN:       -o exit | FileCheck %s
+
+# CHECK:      (lldb) expression *f
+# CHECK:      (Foo) ${{[0-9]+}} = {
+# CHECK:         y = 2 
+# CHECK-NEXT:    i = 1 
+
+#--- main.m
+#import <Foundation/Foundation.h>
+#import "lib.h"
+
+extern Foo * func();
+
+int main() {
+    Foo * f = func();
+    return 0;
+}
+
+#--- lib.m
+#import <Foundation/Foundation.h>
+#import "lib.h"
+
+@implementation Foo {
+int i;
+}
+
+- (id)init {
+  self->i = 1;
+  self->y = 2;
+
+  return self;
+}
+@end
+
+Foo * func() {
+  return [[Foo alloc] init];
+}
+
+#--- lib.h
+#ifndef LIB_H_IN
+#define LIB_H_IN
+
+#import <Foundation/Foundation.h>
+
+@interface Foo : NSObject {
+int y;
+}
+@end
+
+#endif  // _H_IN

[Michael137]

TestHiddenIvars.py looks like it intended to test the same codepath, but it passes cleanly with and without the calls to FindCompleteObjCDefinitionTypeForDIE

[labath]

Something that's not currently clear to me is why frame var *f succeeds even without the DW_AT_APPLE_objc_complete_type infrastructure. If it's using the ObjC runtime, which should make expr do the same, in which case we can remove this code from DWARFASTParserClang.

I don't know, but I'm all for deleting code :D

[labath]

I think this needs a REQUIRES: system-darwin.

For science, I also tried to make a version of this test which could run on other systems, but all I managed is to hit an (lldb)assert:

$ cat a.m 
__attribute__((objc_root_class)) @interface  Foo  {
int y;
}
@end

#ifdef DEF
@implementation Foo {
    int i;
}

- (id)init {
  self->i = 1;
  self->y = 2;

  return self;
}
@end
#endif

Foo *foo;
$ clang -c a.m -g -DDEF --target=aarch64-apple-macosx
$ lldb a.o -o "target variable foo[0]"
(lldb) target create "a.o"
Current executable set to '/tmp/a.o' (arm64).
(lldb) target variable foo[0]
warning: trying to determine the size of type @interface Foo{
    int y;
    int i;
}
@end
without a valid ExecutionContext. this is not reliable. please file a bug against LLDB.
backtrace:
 #0 0x00007f117b0ab29e llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) llvm/lib/Support/Unix/Signals.inc:723:22
 #1 0x00007f117af11e90 lldb_private::TypeSystemClang::GetObjCBitSize(clang::QualType, lldb_private::ExecutionContextScope*) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4780:17

[Michael137]

Thanks for trying! Yea I'll probably add the Darwin requirement then