[llvm][DebugInfo][test] Add LLVM tests for Objective-C property debug-info #165373
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
|
@llvm/pr-subscribers-debuginfo Author: Michael Buch (Michael137) ChangesThe IR->DWARF pipeline was not properly tested before. This patch adds a test to generate DWARF for various This caught a couple of bugs:
These will be fixed in follow-up patches. Full diff: https://github.com/llvm/llvm-project/pull/165373.diff 1 Files Affected:
diff --git a/llvm/test/DebugInfo/Generic/objc-property.ll b/llvm/test/DebugInfo/Generic/objc-property.ll
new file mode 100644
index 0000000000000..f8ccf141b07c3
--- /dev/null
+++ b/llvm/test/DebugInfo/Generic/objc-property.ll
@@ -0,0 +1,83 @@
+; RUN: llc -filetype=obj -o - %s | llvm-dwarfdump --debug-info - | FileCheck %s
+
+; CHECK: DW_TAG_structure_type
+; CHECK: DW_AT_name ("Foo")
+;
+; CHECK: DW_TAG_APPLE_property
+; CHECK: DW_AT_APPLE_property_name ("autoSynthProp")
+; CHECK: DW_AT_APPLE_property_attribute
+; CHECK-SAME: DW_APPLE_PROPERTY_assign, DW_APPLE_PROPERTY_readwrite,
+; CHECK-SAME: DW_APPLE_PROPERTY_atomic, DW_APPLE_PROPERTY_unsafe_unretained
+;
+; CHECK: DW_TAG_APPLE_property
+; CHECK: DW_AT_APPLE_property_name ("synthProp")
+; CHECK: DW_AT_APPLE_property_attribute
+; CHECK-SAME: DW_APPLE_PROPERTY_assign, DW_APPLE_PROPERTY_readwrite,
+; CHECK-SAME: DW_APPLE_PROPERTY_atomic, DW_APPLE_PROPERTY_unsafe_unretained
+;
+; FIXME: this should have a DW_AT_APPLE_property_getter tag
+; CHECK: DW_TAG_APPLE_property
+; CHECK: DW_AT_APPLE_property_name ("customGetterProp")
+; CHECK: DW_AT_APPLE_property_setter ("customGetter")
+; CHECK: DW_AT_APPLE_property_attribute
+; CHECK-SAME: DW_APPLE_PROPERTY_getter, DW_APPLE_PROPERTY_assign, DW_APPLE_PROPERTY_readwrite,
+; CHECK-SAME: DW_APPLE_PROPERTY_atomic, DW_APPLE_PROPERTY_unsafe_unretained
+;
+; CHECK: DW_TAG_APPLE_property
+; CHECK: DW_AT_APPLE_property_name ("customSetterProp")
+; CHECK: DW_AT_APPLE_property_setter ("customSetter:")
+; CHECK: DW_AT_APPLE_property_attribute
+; CHECK-SAME: DW_APPLE_PROPERTY_assign, DW_APPLE_PROPERTY_readwrite,
+; CHECK-SAME: DW_APPLE_PROPERTY_setter, DW_APPLE_PROPERTY_atomic, DW_APPLE_PROPERTY_unsafe_unretained
+;
+; CHECK: DW_TAG_APPLE_property
+; CHECK: DW_AT_APPLE_property_name ("customAccessorsProp")
+; CHECK: DW_AT_APPLE_property_getter ("customGetter")
+; CHECK: DW_AT_APPLE_property_setter ("customSetter:")
+; CHECK: DW_AT_APPLE_property_attribute
+; CHECK-SAME: DW_APPLE_PROPERTY_getter, DW_APPLE_PROPERTY_assign, DW_APPLE_PROPERTY_readwrite,
+; CHECK-SAME: DW_APPLE_PROPERTY_setter, DW_APPLE_PROPERTY_atomic, DW_APPLE_PROPERTY_unsafe_unretained
+;
+; FIXME: missing link between DW_TAG_member and the associated DW_TAG_APPLE_property
+; CHECK-NOT: DW_APPLE_property
+; CHECK: DW_TAG_member
+; CHECK: DW_TAG_member
+; CHECK: DW_TAG_member
+; CHECK: DW_TAG_member
+
+!llvm.module.flags = !{!7, !8}
+!llvm.dbg.cu = !{!13}
+
+!7 = !{i32 7, !"Dwarf Version", i32 5}
+!8 = !{i32 2, !"Debug Info Version", i32 3}
+!13 = distinct !DICompileUnit(language: DW_LANG_ObjC, file: !14, producer: "hand written", isOptimized: false, runtimeVersion: 2, emissionKind: FullDebug, retainedTypes: !15, splitDebugInlining: false, debugInfoForProfiling: true, nameTableKind: Apple)
+!14 = !DIFile(filename: "main.m", directory: "/tmp")
+!15 = !{!16}
+!16 = !DICompositeType(tag: DW_TAG_structure_type, name: "Foo", scope: !14, file: !14, line: 1, size: 128, flags: DIFlagObjcClassComplete, elements: !17, runtimeLang: DW_LANG_ObjC)
+!17 = !{!18, !20, !21, !22, !23, !24, !25, !26, !27, !28, !35, !38, !39, !40, !41, !42, !43}
+!18 = !DIObjCProperty(name: "autoSynthProp", file: !14, line: 5, attributes: 2316, type: !19)
+!19 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!20 = !DIObjCProperty(name: "synthProp", file: !14, line: 6, attributes: 2316, type: !19)
+!21 = !DIObjCProperty(name: "customGetterProp", file: !14, line: 7, getter: "customGetter", attributes: 2318, type: !19)
+!22 = !DIObjCProperty(name: "customSetterProp", file: !14, line: 8, setter: "customSetter:", attributes: 2444, type: !19)
+!23 = !DIObjCProperty(name: "customAccessorsProp", file: !14, line: 9, setter: "customSetter:", getter: "customGetter", attributes: 2446, type: !19)
+!24 = !DIDerivedType(tag: DW_TAG_member, name: "someBackingIvar", scope: !14, file: !14, line: 2, baseType: !19, size: 32, flags: DIFlagProtected, extraData: !20)
+!25 = !DIDerivedType(tag: DW_TAG_member, name: "_autoSynthProp", scope: !14, file: !14, line: 5, baseType: !19, size: 32, flags: DIFlagPrivate, extraData: !18)
+!26 = !DIDerivedType(tag: DW_TAG_member, name: "_customGetterProp", scope: !14, file: !14, line: 7, baseType: !19, size: 32, flags: DIFlagPrivate, extraData: !21)
+!27 = !DIDerivedType(tag: DW_TAG_member, name: "_customSetterProp", scope: !14, file: !14, line: 8, baseType: !19, size: 32, flags: DIFlagPrivate, extraData: !22)
+!28 = !DISubprogram(name: "-[Foo customGetter]", scope: !16, file: !14, line: 19, type: !29, scopeLine: 19, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit)
+!29 = !DISubroutineType(types: !30)
+!30 = !{!19, !31, !32}
+!31 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !16, size: 64, flags: DIFlagArtificial | DIFlagObjectPointer)
+!32 = !DIDerivedType(tag: DW_TAG_typedef, name: "SEL", file: !14, baseType: !33, flags: DIFlagArtificial)
+!33 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !34, size: 64)
+!34 = !DICompositeType(tag: DW_TAG_structure_type, name: "objc_selector", file: !14, flags: DIFlagFwdDecl)
+!35 = !DISubprogram(name: "-[Foo customSetter:]", scope: !16, file: !14, line: 23, type: !36, scopeLine: 23, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit)
+!36 = !DISubroutineType(types: !37)
+!37 = !{null, !31, !32, !19}
+!38 = !DISubprogram(name: "-[Foo synthProp]", scope: !16, file: !14, line: 17, type: !29, scopeLine: 17, flags: DIFlagArtificial | DIFlagPrototyped, spFlags: DISPFlagLocalToUnit)
+!39 = !DISubprogram(name: "-[Foo setSynthProp:]", scope: !16, file: !14, line: 17, type: !36, scopeLine: 17, flags: DIFlagArtificial | DIFlagPrototyped, spFlags: DISPFlagLocalToUnit)
+!40 = !DISubprogram(name: "-[Foo autoSynthProp]", scope: !16, file: !14, line: 5, type: !29, scopeLine: 5, flags: DIFlagArtificial | DIFlagPrototyped, spFlags: DISPFlagLocalToUnit)
+!41 = !DISubprogram(name: "-[Foo setAutoSynthProp:]", scope: !16, file: !14, line: 5, type: !36, scopeLine: 5, flags: DIFlagArtificial | DIFlagPrototyped, spFlags: DISPFlagLocalToUnit)
+!42 = !DISubprogram(name: "-[Foo setCustomGetterProp:]", scope: !16, file: !14, line: 7, type: !36, scopeLine: 7, flags: DIFlagArtificial | DIFlagPrototyped, spFlags: DISPFlagLocalToUnit)
+!43 = !DISubprogram(name: "-[Foo customSetterProp]", scope: !16, file: !14, line: 8, type: !29, scopeLine: 8, flags: DIFlagArtificial | DIFlagPrototyped, spFlags: DISPFlagLocalToUnit)
|
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 28, 2025
…DIObjCProperty constructor Depends on llvm#165373 This caused the `DW_AT_APPLE_property_(setter|getter)` to be inverted when compiling from LLVM IR.
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 28, 2025
…DIObjCProperty constructor Depends on llvm#165373 This caused the `DW_AT_APPLE_property_(setter|getter)` to be inverted when compiling from LLVM IR.
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 28, 2025
…AG_APPLE_property Depends on: * llvm#165373 * llvm#165401 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite.
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 28, 2025
…AG_APPLE_property Depends on: * llvm#165373 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite.
Michael137
force-pushed
the
llvm/objc-property-tests
branch
2 times, most recently
from
eb25ae8 to
dcdf5d6
Compare
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 28, 2025
…DIObjCProperty constructor Depends on llvm#165373 This caused the `DW_AT_APPLE_property_(setter|getter)` to be inverted when compiling from LLVM IR.
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 28, 2025
…AG_APPLE_property Depends on: * llvm#165373 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite.
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 28, 2025
…DIObjCProperty constructor Depends on llvm#165373 This caused the `DW_AT_APPLE_property_(setter|getter)` to be inverted when compiling from LLVM IR. (cherry picked from commit 62797e1)
…-info The IR->DWARF pipeline was not properly tested before. This patch adds a test to generate DWARF for various `DIObjCProperty` constructions. This caught a couple of bugs: 1. The `DW_AT_APPLE_property_getter` and `DW_AT_APPLE_property_setter` properties were emitted the wrong way around. 2. The `DW_TAG_member` ivars were not linking back to the property that they back. These will be fixed in follow-up patches.
Michael137
force-pushed
the
llvm/objc-property-tests
branch
from
8c2dcfa to
96705dd
Compare
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 28, 2025
…AG_APPLE_property Depends on: * llvm#165373 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite. (cherry picked from commit 945371b)
OCHyams
approved these changes
Oct 29, 2025
Contributor
OCHyams
left a comment
OCHyams
left a comment
There was a problem hiding this comment.
Not familiar with Objc but having looked at the whole stack it makes sense and the test LGTM
Member
Author
Thanks for the review! |
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 29, 2025
…DIObjCProperty constructor Depends on llvm#165373 This caused the `DW_AT_APPLE_property_(setter|getter)` to be inverted when compiling from LLVM IR.
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 29, 2025
…AG_APPLE_property Depends on: * llvm#165373 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite.
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 29, 2025
…AG_APPLE_property Depends on: * llvm#165373 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite.
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 29, 2025
…DIObjCProperty constructor Depends on llvm#165373 This caused the `DW_AT_APPLE_property_(setter|getter)` to be inverted when compiling from LLVM IR.
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Oct 29, 2025
…r to DIObjCProperty constructor (#165401) Depends on: * llvm/llvm-project#165373 This caused the `DW_AT_APPLE_property_(setter|getter)` to be inverted when compiling from LLVM IR.
aokblast
pushed a commit
to aokblast/llvm-project
that referenced
this pull request
Oct 30, 2025
…-info (llvm#165373) The IR->DWARF pipeline was not properly tested before. This patch adds a test to generate DWARF for various `DIObjCProperty` constructions. This caught a couple of bugs: 1. The `DW_AT_APPLE_property_getter` and `DW_AT_APPLE_property_setter` properties were emitted the wrong way around. 2. The `DW_TAG_member` ivars were not linking back to the property that they back. These will be fixed in follow-up patches.
aokblast
pushed a commit
to aokblast/llvm-project
that referenced
this pull request
Oct 30, 2025
…Property constructor (llvm#165401) Depends on: * llvm#165373 This caused the `DW_AT_APPLE_property_(setter|getter)` to be inverted when compiling from LLVM IR.
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 31, 2025
…AG_APPLE_property Depends on: * llvm#165373 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite.
Michael137
added a commit
to Michael137/llvm-project
that referenced
this pull request
Oct 31, 2025
…AG_APPLE_property Depends on: * llvm#165373 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite.
Michael137
added a commit
that referenced
this pull request
Oct 31, 2025
…AG_APPLE_property (#165409) Depends on: * #165373 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite.
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Oct 31, 2025
… their DW_TAG_APPLE_property (#165409) Depends on: * llvm/llvm-project#165373 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite.
DEBADRIBASAK
pushed a commit
to DEBADRIBASAK/llvm-project
that referenced
this pull request
Nov 3, 2025
…-info (llvm#165373) The IR->DWARF pipeline was not properly tested before. This patch adds a test to generate DWARF for various `DIObjCProperty` constructions. This caught a couple of bugs: 1. The `DW_AT_APPLE_property_getter` and `DW_AT_APPLE_property_setter` properties were emitted the wrong way around. 2. The `DW_TAG_member` ivars were not linking back to the property that they back. These will be fixed in follow-up patches.
DEBADRIBASAK
pushed a commit
to DEBADRIBASAK/llvm-project
that referenced
this pull request
Nov 3, 2025
…Property constructor (llvm#165401) Depends on: * llvm#165373 This caused the `DW_AT_APPLE_property_(setter|getter)` to be inverted when compiling from LLVM IR.
DEBADRIBASAK
pushed a commit
to DEBADRIBASAK/llvm-project
that referenced
this pull request
Nov 3, 2025
…AG_APPLE_property (llvm#165409) Depends on: * llvm#165373 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite.
Michael137
added a commit
to swiftlang/llvm-project
that referenced
this pull request
Nov 4, 2025
…-info (llvm#165373) The IR->DWARF pipeline was not properly tested before. This patch adds a test to generate DWARF for various `DIObjCProperty` constructions. This caught a couple of bugs: 1. The `DW_AT_APPLE_property_getter` and `DW_AT_APPLE_property_setter` properties were emitted the wrong way around. 2. The `DW_TAG_member` ivars were not linking back to the property that they back. These will be fixed in follow-up patches. (cherry picked from commit 7fb6fae)
Michael137
added a commit
to swiftlang/llvm-project
that referenced
this pull request
Nov 4, 2025
…Property constructor (llvm#165401) Depends on: * llvm#165373 This caused the `DW_AT_APPLE_property_(setter|getter)` to be inverted when compiling from LLVM IR. (cherry picked from commit dda95d9)
Michael137
added a commit
to swiftlang/llvm-project
that referenced
this pull request
Nov 5, 2025
…-info (llvm#165373) The IR->DWARF pipeline was not properly tested before. This patch adds a test to generate DWARF for various `DIObjCProperty` constructions. This caught a couple of bugs: 1. The `DW_AT_APPLE_property_getter` and `DW_AT_APPLE_property_setter` properties were emitted the wrong way around. 2. The `DW_TAG_member` ivars were not linking back to the property that they back. These will be fixed in follow-up patches. (cherry picked from commit 7fb6fae)
Michael137
added a commit
to swiftlang/llvm-project
that referenced
this pull request
Nov 5, 2025
…Property constructor (llvm#165401) Depends on: * llvm#165373 This caused the `DW_AT_APPLE_property_(setter|getter)` to be inverted when compiling from LLVM IR. (cherry picked from commit dda95d9)
Michael137
added a commit
to swiftlang/llvm-project
that referenced
this pull request
Nov 5, 2025
…AG_APPLE_property (llvm#165409) Depends on: * llvm#165373 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite. (cherry picked from commit 10fbbb6)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The IR->DWARF pipeline was not properly tested before. This patch adds a test to generate DWARF for various
DIObjCPropertyconstructions.This caught a couple of bugs:
DW_AT_APPLE_property_getterandDW_AT_APPLE_property_setterproperties were emitted the wrong way around.DW_TAG_memberivars were not linking back to the property that they back.These will be fixed in follow-up patches.