[Lldb-commits] [PATCH] D96549: Support dereferencing a DWARF scalar stack value

[Adrian Prantl via Phabricator via lldb-commits]

aprantl created this revision.
aprantl added reviewers: vsk, JDevlieghere, jasonmolenda.
Herald added a subscriber: lxfind.
aprantl requested review of this revision.

Swift async functions receive function arguments inside a heap-allocated data structure, similar to how ObjC block captures or C++ coroutine arguments are implement. In DWARF they are described relative to an entry value that produces a pointer into that heap object. At typical location looks like

`DW_OP_entry_value [ DW_OP_reg14 ] DW_OP_deref DW_OP_plus_uconst 32 DW_OP_deref`

This allows the unwinder (which has special ABI knowledge to restore the contents of r14) to push the base address onto the stack thus allowing the deref/offset operations to continue. The result of the entry value is a scalar, because DW_OP_reg14 is a register location — as it should be since we want to restore the pointer value contained in r14 at the beginning of the function and not the historical memory contents it was pointing to. The entry value should restore the address, which is still valid, not the contents at function entry.

To make this work, we need to allow LLDB to dereference Scalar stack results like load addresses, which is what this patch does. Unfortunately it is difficult to test this in isolation, since the DWARFExpression unit test doesn't have a process. Are there any situations where we shouldn't allow Scalars to be dereferences? Could they ever hold a File- or Hostaddress? I don't think so.


https://reviews.llvm.org/D96549

Files:
  lldb/source/Expression/DWARFExpression.cpp


Index: lldb/source/Expression/DWARFExpression.cpp
===================================================================
--- lldb/source/Expression/DWARFExpression.cpp
+++ lldb/source/Expression/DWARFExpression.cpp
@@ -1067,6 +1067,7 @@
         stack.back().SetValueType(Value::ValueType::LoadAddress);
         // Fall through to load address code below...
       } LLVM_FALLTHROUGH;
+      case Value::ValueType::Scalar:
       case Value::ValueType::LoadAddress:
         if (exe_ctx) {
           if (process) {
@@ -1099,7 +1100,6 @@
         }
         break;
 
-      case Value::ValueType::Scalar:
       case Value::ValueType::Invalid:
         if (error_ptr)
           error_ptr->SetErrorString("Invalid value type for DW_OP_deref.\n");
@@ -1170,6 +1170,7 @@
         stack.back().GetScalar() = ptr;
         stack.back().ClearContext();
       } break;
+      case Value::ValueType::Scalar:
       case Value::ValueType::LoadAddress:
         if (exe_ctx) {
           if (process) {
@@ -1221,7 +1222,6 @@
         }
         break;
 
-      case Value::ValueType::Scalar:
       case Value::ValueType::FileAddress:
       case Value::ValueType::Invalid:
         if (error_ptr)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D96549.323138.patch
Type: text/x-patch
Size: 1188 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20210211/b070fc7b/attachment.bin>