If the address of the isa_pointer is returned as an error don't ask if it is a tagged pointer (#213163) - #216226
If the address of the isa_pointer is returned as an error don't ask if it is a tagged pointer (#213163)#216226jimingham wants to merge 1 commit into
Conversation
…f it is a tagged pointer (llvm#213163) The answer isn't right and the wrong type might stick and cause downstream failures. Note, the correct solution to this is to distinguish between "couldn't get the address" and "got a real value of LLDB_INVALID_ADDRESS" but piping an optional all the way down and then through all the uses is an intrusive change which I don't have time for right now. That only risk is that this really IS a tagged pointer with the value LLDB_INVALID_ADDRESS, so this seems an acceptable workaround. I ran across this when debugging the ObjC test failures in the ObjC testuite after 8b9cce3. This patch clears up all those testsuite failures, which should stand as a test for this patch when I resubmit that change. (cherry picked from commit 8fbdc8c)
|
@llvm/pr-subscribers-lldb Author: jimingham ChangesThe answer isn't right and the wrong type might stick and cause downstream failures. Note, the correct solution to this is to distinguish between "couldn't get the address" and "got a real value of LLDB_INVALID_ADDRESS" but piping an optional all the way down and then through all the uses is an intrusive change which I don't have time for right now. That only risk is that this really IS a tagged pointer with the value LLDB_INVALID_ADDRESS, so this seems an acceptable workaround. I ran across this when debugging the ObjC test failures in the ObjC testuite after 8b9cce3. This patch clears up all those testsuite failures, which should stand as a test for this patch when I resubmit that change. (cherry picked from commit 8fbdc8c) Full diff: https://github.com/llvm/llvm-project/pull/216226.diff 1 Files Affected:
diff --git a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
index f1f71f7d7a451..ead9c28ed7058 100644
--- a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
+++ b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
@@ -1646,6 +1646,8 @@ AppleObjCRuntimeV2::GetClassDescriptorImpl(ValueObject &valobj,
if (!valobj.GetCompilerType().IsValid())
return objc_class_sp;
addr_t isa_pointer = valobj.GetPointerValue().address;
+ if (isa_pointer == LLDB_INVALID_ADDRESS)
+ return objc_class_sp;
// tagged pointer
if (IsTaggedPointer(isa_pointer))
|
3 participants
The answer isn't right and the wrong type might stick and cause downstream failures.
Note, the correct solution to this is to distinguish between "couldn't get the address" and "got a real value of LLDB_INVALID_ADDRESS" but piping an optional all the way down and then through all the uses is an intrusive change which I don't have time for right now. That only risk is that this really IS a tagged pointer with the value LLDB_INVALID_ADDRESS, so this seems an acceptable workaround.
I ran across this when debugging the ObjC test failures in the ObjC testuite after 8b9cce3. This patch clears up all those testsuite failures, which should stand as a test for this patch when I resubmit that change.
(cherry picked from commit 8fbdc8c)