[Lldb-commits] [PATCH] D136578: [LLDB] [LoongArch] Add minimal LoongArch support

2022-11-25 Thread David Spickett via Phabricator via lldb-commits 
DavidSpickett added a comment.

Nice, glad to see that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136578/new/

https://reviews.llvm.org/D136578

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

[Lldb-commits] [lldb] 3427cb5 - [lldb] Prevent an infinite loop while reading memory regions

2022-11-25 Thread Pavel Labath via lldb-commits 

Author: Pavel Labath
Date: 2022-11-25T11:55:41+01:00
New Revision: 3427cb5b3a55a454e5750f6318ced8a5d7c1442d

URL: 
https://github.com/llvm/llvm-project/commit/3427cb5b3a55a454e5750f6318ced8a5d7c1442d
DIFF: 
https://github.com/llvm/llvm-project/commit/3427cb5b3a55a454e5750f6318ced8a5d7c1442d.diff

LOG: [lldb] Prevent an infinite loop  while reading memory regions

A malformed qMemoryRegionInfo response can easily trigger an infinite
loop if regions end (base + size) wraps the address space. A
particularly interesting is the case where base+size=0, which a stub
could use to say that the rest of the memory space is unmapped, even
though lldb expects 0xff... in this case.

One could argue which behavior is more correct (technically, the
current behavior does not say anything about the last byte), but unless
we stop using 0xff... to mean "invalid address", that discussion is very
academic. This patch truncates address ranges which wraps the address
space, which handles the zero case as well as other kinds of malformed
packets.

Added: 

lldb/test/API/functionalities/gdb_remote_client/TestGdbClientMemoryRegions.py

Modified: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
index f03fd4231c74a..347c47b078f45 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
@@ -1527,8 +1527,14 @@ Status GDBRemoteCommunicationClient::GetMemoryRegionInfo(
   if (!value.getAsInteger(16, addr_value))
 region_info.GetRange().SetRangeBase(addr_value);
 } else if (name.equals("size")) {
-  if (!value.getAsInteger(16, addr_value))
+  if (!value.getAsInteger(16, addr_value)) {
 region_info.GetRange().SetByteSize(addr_value);
+if (region_info.GetRange().GetRangeEnd() <
+region_info.GetRange().GetRangeBase()) {
+  // Range size overflowed, truncate it.
+  region_info.GetRange().SetRangeEnd(LLDB_INVALID_ADDRESS);
+}
+  }
 } else if (name.equals("permissions") &&
region_info.GetRange().IsValid()) {
   saw_permissions = true;

diff  --git 
a/lldb/test/API/functionalities/gdb_remote_client/TestGdbClientMemoryRegions.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestGdbClientMemoryRegions.py
new file mode 100644
index 0..c6ad39bcdc72f
--- /dev/null
+++ 
b/lldb/test/API/functionalities/gdb_remote_client/TestGdbClientMemoryRegions.py
@@ -0,0 +1,44 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+from lldbsuite.test.gdbclientutils import *
+from lldbsuite.test.lldbgdbclient import GDBRemoteTestBase
+
+
+class TestGdbClientMemoryRegions(GDBRemoteTestBase):
+
+def test(self):
+"""
+Test handling of overflowing memory regions. In particular, make sure
+they don't trigger an infinite loop.
+"""
+class MyResponder(MockGDBServerResponder):
+
+def qHostInfo(self):
+return "ptrsize:8;endian:little;"
+
+def qMemoryRegionInfo(self, addr):
+if addr == 0:
+return "start:0;size:8000;permissions:rw;"
+if addr == 0x8000:
+return 
"start:8000;size:8000;permissions:r;"
+
+self.runCmd("log enable gdb-remote packets")
+self.runCmd("log enable lldb temp")
+self.server.responder = MyResponder()
+target = self.dbg.CreateTarget('')
+process = self.connect(target)
+
+regions = process.GetMemoryRegions()
+self.assertEqual(regions.GetSize(), 2)
+
+region = lldb.SBMemoryRegionInfo()
+self.assertTrue(regions.GetMemoryRegionAtIndex(0, region))
+self.assertEqual(region.GetRegionBase(), 0)
+self.assertEqual(region.GetRegionEnd(), 0x8000)
+self.assertTrue(region.IsWritable())
+
+self.assertTrue(regions.GetMemoryRegionAtIndex(1, region))
+self.assertEqual(region.GetRegionBase(), 0x8000)
+self.assertEqual(region.GetRegionEnd(), 0x)
+self.assertFalse(region.IsWritable())



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

[Lldb-commits] [lldb] c699a81 - [lldb/test] Remove the module cache directory in module-ownership.mm

2022-11-25 Thread Pavel Labath via lldb-commits 

Author: Pavel Labath
Date: 2022-11-25T11:55:42+01:00
New Revision: c699a81bc98804650fdd4a85de085e257e074878

URL: 
https://github.com/llvm/llvm-project/commit/c699a81bc98804650fdd4a85de085e257e074878
DIFF: 
https://github.com/llvm/llvm-project/commit/c699a81bc98804650fdd4a85de085e257e074878.diff

LOG: [lldb/test] Remove the module cache directory in module-ownership.mm

The stale cache directory can cause compilation to fail when ast
serialization changes.

Added: 


Modified: 
lldb/test/Shell/SymbolFile/DWARF/x86/module-ownership.mm

Removed: 




diff  --git a/lldb/test/Shell/SymbolFile/DWARF/x86/module-ownership.mm 
b/lldb/test/Shell/SymbolFile/DWARF/x86/module-ownership.mm
index 311fd34d40e83..a8dd6cf1d901a 100644
--- a/lldb/test/Shell/SymbolFile/DWARF/x86/module-ownership.mm
+++ b/lldb/test/Shell/SymbolFile/DWARF/x86/module-ownership.mm
@@ -1,3 +1,4 @@
+// RUN: rm -rf %t.cache
 // RUN: %clang --target=x86_64-apple-macosx -g -gmodules -Wno-objc-root-class \
 // RUN:-fmodules -fmodules-cache-path=%t.cache \
 // RUN:-c -o %t.o %s -I%S/Inputs



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

[Lldb-commits] [lldb] b32931c - [lldb][nfc] Deindent ProcessGDBRemote::SetThreadStopInfo by two levels

2022-11-25 Thread Pavel Labath via lldb-commits 

Author: Pavel Labath
Date: 2022-11-25T13:51:13+01:00
New Revision: b32931c5b32eb0d2cf37d688b34f8548c9674c19

URL: 
https://github.com/llvm/llvm-project/commit/b32931c5b32eb0d2cf37d688b34f8548c9674c19
DIFF: 
https://github.com/llvm/llvm-project/commit/b32931c5b32eb0d2cf37d688b34f8548c9674c19.diff

LOG: [lldb][nfc] Deindent ProcessGDBRemote::SetThreadStopInfo by two levels

Added: 


Modified: 
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index ba180cc821e2..83b496b3b978 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -1607,289 +1607,276 @@ ThreadSP ProcessGDBRemote::SetThreadStopInfo(
// queue_serial are valid
 LazyBool associated_with_dispatch_queue, addr_t dispatch_queue_t,
 std::string &queue_name, QueueKind queue_kind, uint64_t queue_serial) {
-  ThreadSP thread_sp;
-  if (tid != LLDB_INVALID_THREAD_ID) {
-// Scope for "locker" below
-{
-  // m_thread_list_real does have its own mutex, but we need to hold onto
-  // the mutex between the call to m_thread_list_real.FindThreadByID(...)
-  // and the m_thread_list_real.AddThread(...) so it doesn't change on us
-  std::lock_guard guard(
-  m_thread_list_real.GetMutex());
-  thread_sp = m_thread_list_real.FindThreadByProtocolID(tid, false);
-
-  if (!thread_sp) {
-// Create the thread if we need to
-thread_sp = std::make_shared(*this, tid);
-m_thread_list_real.AddThread(thread_sp);
-  }
-}
-
-if (thread_sp) {
-  ThreadGDBRemote *gdb_thread =
-  static_cast(thread_sp.get());
-  RegisterContextSP gdb_reg_ctx_sp(gdb_thread->GetRegisterContext());
 
-  gdb_reg_ctx_sp->InvalidateIfNeeded(true);
-
-  auto iter = std::find(m_thread_ids.begin(), m_thread_ids.end(), tid);
-  if (iter != m_thread_ids.end()) {
-SetThreadPc(thread_sp, iter - m_thread_ids.begin());
-  }
-
-  for (const auto &pair : expedited_register_map) {
-StringExtractor reg_value_extractor(pair.second);
-WritableDataBufferSP buffer_sp(new DataBufferHeap(
-reg_value_extractor.GetStringRef().size() / 2, 0));
-reg_value_extractor.GetHexBytes(buffer_sp->GetData(), '\xcc');
-uint32_t lldb_regnum =
-gdb_reg_ctx_sp->ConvertRegisterKindToRegisterNumber(
-eRegisterKindProcessPlugin, pair.first);
-gdb_thread->PrivateSetRegisterValue(lldb_regnum, buffer_sp->GetData());
-  }
+  if (tid == LLDB_INVALID_THREAD_ID)
+return nullptr;
 
-  // AArch64 SVE specific code below calls AArch64SVEReconfigure to update
-  // SVE register sizes and offsets if value of VG register has changed
-  // since last stop.
-  const ArchSpec &arch = GetTarget().GetArchitecture();
-  if (arch.IsValid() && arch.GetTriple().isAArch64()) {
-GDBRemoteRegisterContext *reg_ctx_sp =
-static_cast(
-gdb_thread->GetRegisterContext().get());
-
-if (reg_ctx_sp)
-  reg_ctx_sp->AArch64SVEReconfigure();
-  }
+  ThreadSP thread_sp;
+  // Scope for "locker" below
+  {
+// m_thread_list_real does have its own mutex, but we need to hold onto the
+// mutex between the call to m_thread_list_real.FindThreadByID(...) and the
+// m_thread_list_real.AddThread(...) so it doesn't change on us
+std::lock_guard guard(m_thread_list_real.GetMutex());
+thread_sp = m_thread_list_real.FindThreadByProtocolID(tid, false);
+
+if (!thread_sp) {
+  // Create the thread if we need to
+  thread_sp = std::make_shared(*this, tid);
+  m_thread_list_real.AddThread(thread_sp);
+}
+  }
 
-  thread_sp->SetName(thread_name.empty() ? nullptr : thread_name.c_str());
+  ThreadGDBRemote *gdb_thread = static_cast(thread_sp.get());
+  RegisterContextSP gdb_reg_ctx_sp(gdb_thread->GetRegisterContext());
 
-  gdb_thread->SetThreadDispatchQAddr(thread_dispatch_qaddr);
-  // Check if the GDB server was able to provide the queue name, kind and
-  // serial number
-  if (queue_vars_valid)
-gdb_thread->SetQueueInfo(std::move(queue_name), queue_kind,
- queue_serial, dispatch_queue_t,
- associated_with_dispatch_queue);
-  else
-gdb_thread->ClearQueueInfo();
+  gdb_reg_ctx_sp->InvalidateIfNeeded(true);
 
-  gdb_thread->SetAssociatedWithLibdispatchQueue(
-  associated_with_dispatch_queue);
+  auto iter = std::find(m_thread_ids.begin(), m_thread_ids.end(), tid);
+  if (iter != m_thread_ids.end())
+SetThreadPc(thread_sp, iter - m_thread_ids.begin());
 
-  if (dispatch_queue_t != LLDB

[Lldb-commits] [lldb] ed34590 - [LLDB] Add LoongArch register definitions and operations

2022-11-25 Thread Weining Lu via lldb-commits 

Author: Tiezhu Yang
Date: 2022-11-25T21:19:36+08:00
New Revision: ed34590c1acb300abe51d2686148c62e8c517993

URL: 
https://github.com/llvm/llvm-project/commit/ed34590c1acb300abe51d2686148c62e8c517993
DIFF: 
https://github.com/llvm/llvm-project/commit/ed34590c1acb300abe51d2686148c62e8c517993.diff

LOG: [LLDB] Add LoongArch register definitions and operations

Use the same register layout as Linux kernel, implement the
related read and write operations.

Reviewed By: SixWeining, xen0n, DavidSpickett

Differential Revision: https://reviews.llvm.org/D138407

Added: 
lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_loongarch64.cpp
lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_loongarch64.h
lldb/source/Plugins/Process/Utility/RegisterInfos_loongarch64.h
lldb/source/Plugins/Process/Utility/lldb-loongarch-register-enums.h
lldb/source/Utility/LoongArch_DWARF_Registers.h

Modified: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.h
lldb/source/Plugins/Process/Utility/CMakeLists.txt
lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_loongarch64.cpp
lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_loongarch64.h

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
index a788248f03c1f..8d7bd35b3bdbf 100644
--- 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
+++ 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
@@ -18,6 +18,15 @@
 
 #include "Plugins/Process/Linux/NativeProcessLinux.h"
 #include "Plugins/Process/Linux/Procfs.h"
+#include "Plugins/Process/Utility/RegisterInfoPOSIX_loongarch64.h"
+#include "Plugins/Process/Utility/lldb-loongarch-register-enums.h"
+
+// NT_PRSTATUS and NT_FPREGSET definition
+#include 
+// struct iovec definition
+#include 
+
+#define REG_CONTEXT_SIZE (GetGPRSize() + GetFPRSize())
 
 using namespace lldb;
 using namespace lldb_private;
@@ -52,6 +61,9 @@ 
NativeRegisterContextLinux_loongarch64::NativeRegisterContextLinux_loongarch64(
   NativeRegisterContextLinux(native_thread) {
   ::memset(&m_fpr, 0, sizeof(m_fpr));
   ::memset(&m_gpr, 0, sizeof(m_gpr));
+
+  m_gpr_is_valid = false;
+  m_fpu_is_valid = false;
 }
 
 const RegisterInfoPOSIX_loongarch64 &
@@ -69,24 +81,258 @@ const RegisterSet 
*NativeRegisterContextLinux_loongarch64::GetRegisterSet(
   return GetRegisterInfo().GetRegisterSet(set_index);
 }
 
+uint32_t NativeRegisterContextLinux_loongarch64::GetUserRegisterCount() const {
+  uint32_t count = 0;
+  for (uint32_t set_index = 0; set_index < GetRegisterSetCount(); ++set_index)
+count += GetRegisterSet(set_index)->num_registers;
+  return count;
+}
+
 Status NativeRegisterContextLinux_loongarch64::ReadRegister(
 const RegisterInfo *reg_info, RegisterValue ®_value) {
-  return Status("Failed to read register value");
+  Status error;
+
+  if (!reg_info) {
+error.SetErrorString("reg_info NULL");
+return error;
+  }
+
+  const uint32_t reg = reg_info->kinds[lldb::eRegisterKindLLDB];
+
+  if (reg == LLDB_INVALID_REGNUM)
+return Status("no lldb regnum for %s", reg_info && reg_info->name
+   ? reg_info->name
+   : "");
+
+  uint8_t *src = nullptr;
+  uint32_t offset = LLDB_INVALID_INDEX32;
+
+  if (IsGPR(reg)) {
+error = ReadGPR();
+if (error.Fail())
+  return error;
+
+offset = reg_info->byte_offset;
+assert(offset < GetGPRSize());
+src = (uint8_t *)GetGPRBuffer() + offset;
+
+  } else if (IsFPR(reg)) {
+error = ReadFPR();
+if (error.Fail())
+  return error;
+
+offset = CalculateFprOffset(reg_info);
+assert(offset < GetFPRSize());
+src = (uint8_t *)GetFPRBuffer() + offset;
+  } else
+return Status("failed - register wasn't recognized to be a GPR or an FPR, "
+  "write strategy unknown");
+
+  reg_value.SetFromMemoryData(*reg_info, src, reg_info->byte_size,
+  eByteOrderLittle, error);
+
+  return error;
 }
 
 Status NativeRegisterContextLinux_loongarch64::WriteRegister(
 const RegisterInfo *reg_info, const RegisterValue ®_value) {
+  Status error;
+
+  if (!reg_info)
+return Status("reg_info NULL");
+
+  const uint32_t reg = reg_info->kinds[lldb::eRegisterKindLLDB];
+
+  if (reg == LLDB_INVALID_REGNUM)
+return Status("no lldb regnum for %s", reg_info->name != nullptr
+   ? reg_info->name
+   : "");
+
+  uint8_t *dst = nullptr;
+  uint32_t offset = LLDB_INVALID_INDEX32;
+
+  if (IsGPR(reg)) {
+error = ReadGPR();
+if (error.Fail())
+

[Lldb-commits] [PATCH] D138407: [LLDB] Add LoongArch register definitions and operations

2022-11-25 Thread Lu Weining via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rGed34590c1acb: [LLDB] Add LoongArch register definitions and 
operations (authored by seehearfeel, committed by SixWeining).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138407/new/

https://reviews.llvm.org/D138407

Files:
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.h
  lldb/source/Plugins/Process/Utility/CMakeLists.txt
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_loongarch64.cpp
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_loongarch64.h
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_loongarch64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_loongarch64.h
  lldb/source/Plugins/Process/Utility/RegisterInfos_loongarch64.h
  lldb/source/Plugins/Process/Utility/lldb-loongarch-register-enums.h
  lldb/source/Utility/LoongArch_DWARF_Registers.h

Index: lldb/source/Utility/LoongArch_DWARF_Registers.h
===
--- /dev/null
+++ lldb/source/Utility/LoongArch_DWARF_Registers.h
@@ -0,0 +1,178 @@
+//===-- LoongArch_DWARF_Registers.h -*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_SOURCE_UTILITY_LOONGARCH_DWARF_REGISTERS_H
+#define LLDB_SOURCE_UTILITY_LOONGARCH_DWARF_REGISTERS_H
+
+#include "lldb/lldb-private.h"
+
+namespace loongarch_dwarf {
+
+enum {
+  dwarf_gpr_r0 = 0,
+  dwarf_gpr_r1,
+  dwarf_gpr_r2,
+  dwarf_gpr_r3,
+  dwarf_gpr_r4,
+  dwarf_gpr_r5,
+  dwarf_gpr_r6,
+  dwarf_gpr_r7,
+  dwarf_gpr_r8,
+  dwarf_gpr_r9,
+  dwarf_gpr_r10,
+  dwarf_gpr_r11,
+  dwarf_gpr_r12,
+  dwarf_gpr_r13,
+  dwarf_gpr_r14,
+  dwarf_gpr_r15,
+  dwarf_gpr_r16,
+  dwarf_gpr_r17,
+  dwarf_gpr_r18,
+  dwarf_gpr_r19,
+  dwarf_gpr_r20,
+  dwarf_gpr_r21,
+  dwarf_gpr_r22,
+  dwarf_gpr_r23,
+  dwarf_gpr_r24,
+  dwarf_gpr_r25,
+  dwarf_gpr_r26,
+  dwarf_gpr_r27,
+  dwarf_gpr_r28,
+  dwarf_gpr_r29,
+  dwarf_gpr_r30,
+  dwarf_gpr_r31 = 31,
+
+  dwarf_gpr_orig_a0,
+  dwarf_gpr_pc,
+  dwarf_gpr_badv,
+
+  dwarf_gpr_reserved0 = 35,
+  dwarf_gpr_reserved1,
+  dwarf_gpr_reserved2,
+  dwarf_gpr_reserved3,
+  dwarf_gpr_reserved4,
+  dwarf_gpr_reserved5,
+  dwarf_gpr_reserved6,
+  dwarf_gpr_reserved7,
+  dwarf_gpr_reserved8,
+  dwarf_gpr_reserved9,
+
+  dwarf_fpr_f0 = 45,
+  dwarf_fpr_f1,
+  dwarf_fpr_f2,
+  dwarf_fpr_f3,
+  dwarf_fpr_f4,
+  dwarf_fpr_f5,
+  dwarf_fpr_f6,
+  dwarf_fpr_f7,
+  dwarf_fpr_f8,
+  dwarf_fpr_f9,
+  dwarf_fpr_f10,
+  dwarf_fpr_f11,
+  dwarf_fpr_f12,
+  dwarf_fpr_f13,
+  dwarf_fpr_f14,
+  dwarf_fpr_f15,
+  dwarf_fpr_f16,
+  dwarf_fpr_f17,
+  dwarf_fpr_f18,
+  dwarf_fpr_f19,
+  dwarf_fpr_f20,
+  dwarf_fpr_f21,
+  dwarf_fpr_f22,
+  dwarf_fpr_f23,
+  dwarf_fpr_f24,
+  dwarf_fpr_f25,
+  dwarf_fpr_f26,
+  dwarf_fpr_f27,
+  dwarf_fpr_f28,
+  dwarf_fpr_f29,
+  dwarf_fpr_f30,
+  dwarf_fpr_f31 = 76,
+
+  dwarf_fpr_fcc0,
+  dwarf_fpr_fcc1,
+  dwarf_fpr_fcc2,
+  dwarf_fpr_fcc3,
+  dwarf_fpr_fcc4,
+  dwarf_fpr_fcc5,
+  dwarf_fpr_fcc6,
+  dwarf_fpr_fcc7,
+  dwarf_fpr_fcsr,
+
+  // register name alias
+  dwarf_gpr_zero = dwarf_gpr_r0,
+  dwarf_gpr_ra = dwarf_gpr_r1,
+  dwarf_gpr_tp = dwarf_gpr_r2,
+  dwarf_gpr_sp = dwarf_gpr_r3,
+  dwarf_gpr_a0 = dwarf_gpr_r4,
+  dwarf_gpr_a1 = dwarf_gpr_r5,
+  dwarf_gpr_a2 = dwarf_gpr_r6,
+  dwarf_gpr_a3 = dwarf_gpr_r7,
+  dwarf_gpr_a4 = dwarf_gpr_r8,
+  dwarf_gpr_a5 = dwarf_gpr_r9,
+  dwarf_gpr_a6 = dwarf_gpr_r10,
+  dwarf_gpr_a7 = dwarf_gpr_r11,
+  dwarf_gpr_t0 = dwarf_gpr_r12,
+  dwarf_gpr_t1 = dwarf_gpr_r13,
+  dwarf_gpr_t2 = dwarf_gpr_r14,
+  dwarf_gpr_t3 = dwarf_gpr_r15,
+  dwarf_gpr_t4 = dwarf_gpr_r16,
+  dwarf_gpr_t5 = dwarf_gpr_r17,
+  dwarf_gpr_t6 = dwarf_gpr_r18,
+  dwarf_gpr_t7 = dwarf_gpr_r19,
+  dwarf_gpr_t8 = dwarf_gpr_r20,
+  dwarf_gpr_fp = dwarf_gpr_r22,
+  dwarf_gpr_s9 = dwarf_gpr_r22,
+  dwarf_gpr_s0 = dwarf_gpr_r23,
+  dwarf_gpr_s1 = dwarf_gpr_r24,
+  dwarf_gpr_s2 = dwarf_gpr_r25,
+  dwarf_gpr_s3 = dwarf_gpr_r26,
+  dwarf_gpr_s4 = dwarf_gpr_r27,
+  dwarf_gpr_s5 = dwarf_gpr_r28,
+  dwarf_gpr_s6 = dwarf_gpr_r29,
+  dwarf_gpr_s7 = dwarf_gpr_r30,
+  dwarf_gpr_s8 = dwarf_gpr_r31,
+
+  dwarf_fpr_fa0 = dwarf_fpr_f0,
+  dwarf_fpr_fa1 = dwarf_fpr_f1,
+  dwarf_fpr_fa2 = dwarf_fpr_f2,
+  dwarf_fpr_fa3 = dwarf_fpr_f3,
+  dwarf_fpr_fa4 = dwarf_fpr_f4,
+  dwarf_fpr_fa5 = dwarf_fpr_f5,
+  dwarf_fpr_fa6 = dwarf_fpr_f6,
+  dwarf_fpr_fa7 = dwarf_fpr_f7,
+  dwarf_fpr_ft0 = dwarf_fpr_f8,
+  dwarf_fpr_ft1 = dwarf_fpr_f9,
+  dwarf_fpr_ft2 = dwarf_fpr_f10,
+  dwarf_fpr_ft3 = dwarf_fpr_f11,
+  dwarf_fpr_ft4 = dwarf_fpr_f12,
+  dwarf_fpr_ft5 = dwarf_fpr_f1

[Lldb-commits] [PATCH] D138724: [lldb][Target] Flush the scratch TypeSystem when process gets deleted

2022-11-25 Thread Michael Buch via Phabricator via lldb-commits 
Michael137 created this revision.
Michael137 added reviewers: jingham, aprantl.
Herald added a project: All.
Michael137 requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

**Summary**

This patch addresses #59128, where LLDB would crash when evaluating
importing a type that has been imported before into the same target.
The proposed solution is to clear the scratch AST (and associated
persistent variables, ClangASTImporter, etc.) that were created for
the process.

Details:

1. The first time we evaluate the expression we import the decl for Foo into 
the Targets scratch AST context (lives in m_scratch_type_system_map). During 
this process we also create a ClangASTImporter that lives in the 
ClangPersistentVariables::m_ast_importer_sp. This importer has decl tracking 
structures which reference the source AST that the decl got imported from. This 
importer also gets re-used for all calls to DeportType (which we use to copy 
the final decl into the Targets scratch AST).
2. Rebuilding the executable triggers a tear-down of the Module that was 
backing the ASTContext that we originally got the Foo decl from (which lived in 
the Module::m_type_system_map). However, the Target’s scratch AST lives on.
3. Re-running the same expression will now create a new ASTImporterDelegate 
where the destination TranslationUnitDecl is the same as the one from step (1).
4. When importing the new Foo decl we first try to find it in the destination 
DeclContext, which happens to be the scratch destination TranslationUnitDecl. 
The `Foo` decl exists in this context since we copied it into the scratch AST 
in the first run. The ASTImporter then queries LLDB for the origin of that 
decl. Using the same persistent variable ClangASTImporter we claim the decl has 
an origin in the AST context that got torn down with the Module. This faulty 
origin leads to a use-after-free.

**Testing**

- Added API test


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138724

Files:
  lldb/source/Target/Target.cpp
  lldb/test/API/functionalities/rerun_and_expr/Makefile
  lldb/test/API/functionalities/rerun_and_expr/TestRerunAndExpr.py
  lldb/test/API/functionalities/rerun_and_expr/main.cpp
  lldb/test/API/functionalities/rerun_and_expr/rebuild.cpp

Index: lldb/test/API/functionalities/rerun_and_expr/rebuild.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/rerun_and_expr/rebuild.cpp
@@ -0,0 +1,12 @@
+struct Base {
+  int m_base_val = 42;
+};
+
+struct Foo : public Base {
+  int m_derived_val = 137;
+};
+
+int main() {
+  Foo foo;
+  return 0;
+}
Index: lldb/test/API/functionalities/rerun_and_expr/main.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/rerun_and_expr/main.cpp
@@ -0,0 +1,8 @@
+struct Foo {
+  int m_val = 42;
+};
+
+int main() {
+  Foo foo;
+  return 0;
+}
Index: lldb/test/API/functionalities/rerun_and_expr/TestRerunAndExpr.py
===
--- /dev/null
+++ lldb/test/API/functionalities/rerun_and_expr/TestRerunAndExpr.py
@@ -0,0 +1,71 @@
+"""
+Test that re-running a process from within the same target
+after rebuilding the executable flushes the scratch TypeSystems
+tied to that process.
+"""
+
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestRerun(TestBase):
+def test(self):
+"""
+Tests whether re-launching a process without destroying
+the owning target keeps invalid ASTContexts in the
+scratch AST's importer.
+
+We test this by:
+1. Evaluating an expression to import 'struct Foo' into
+   the scratch AST
+2. Change the definition of 'struct Foo' and rebuild the executable
+3. Re-launch the process
+4. Evaluate the same expression in (1). We expect to have only
+   the latest definition of 'struct Foo' in the scratch AST.
+"""
+self.build(dictionary={'CXX_SOURCES':'main.cpp', 'EXE':'a.out'})
+(target, _, _, bkpt) = \
+lldbutil.run_to_source_breakpoint(self, 'return', lldb.SBFileSpec('main.cpp'))
+
+target.BreakpointCreateBySourceRegex('return', lldb.SBFileSpec('rebuild.cpp', False))
+
+self.expect_expr('foo', result_type='Foo', result_children=[
+ValueCheck(name='m_val', value='42')
+])
+
+self.build(dictionary={'CXX_SOURCES':'rebuild.cpp', 'EXE':'a.out'})
+
+self.runCmd('process launch')
+
+self.expect_expr('foo', result_type='Foo', result_children=[
+ValueCheck(name='Base', children=[
+ValueCheck(name='m_base_val', value='42')
+]),
+ValueCheck(name='m_derived_val', value='137')
+])
+
+self.filecheck("target module dump ast", __file__)
+
+# The new

[Lldb-commits] [lldb] 1df47db - Revert "[lldb][NFC] Change FindDefinitionTypeForDWARFDeclContext() to take DWARFDIE"

2022-11-25 Thread Jason Molenda via lldb-commits 

Author: Jason Molenda
Date: 2022-11-25T12:13:31-08:00
New Revision: 1df47dbe131d2aed676d9d5e0441ff4b61fec018

URL: 
https://github.com/llvm/llvm-project/commit/1df47dbe131d2aed676d9d5e0441ff4b61fec018
DIFF: 
https://github.com/llvm/llvm-project/commit/1df47dbe131d2aed676d9d5e0441ff4b61fec018.diff

LOG: Revert "[lldb][NFC] Change FindDefinitionTypeForDWARFDeclContext() to take 
DWARFDIE"

The changes in https://reviews.llvm.org/D138612 cause a testsuite
failure on Darwin systems in TestCPPAccelerator.py, first flagged
by the "LLDB Incremental" CI bot.
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/
with the specific failure text appended to the phabracator.

This reverts commit c3c423b6cb2e1c00483e951ce8cc4d935e31cd14.

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.h
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 2a71705ec064f..a340f1d3d8fe6 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -753,14 +753,17 @@ TypeSP DWARFASTParserClang::ParseEnum(const SymbolContext 
&sc,
 if (type_sp)
   return type_sp;
 
-type_sp = dwarf->FindDefinitionTypeForDWARFDeclContext(die);
+DWARFDeclContext die_decl_ctx = SymbolFileDWARF::GetDWARFDeclContext(die);
+
+type_sp = dwarf->FindDefinitionTypeForDWARFDeclContext(die_decl_ctx);
 
 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->FindDefinitionTypeForDWARFDeclContext(die);
+type_sp = debug_map_symfile->FindDefinitionTypeForDWARFDeclContext(
+die_decl_ctx);
   }
 }
 
@@ -1729,16 +1732,19 @@ DWARFASTParserClang::ParseStructureLikeDIE(const 
SymbolContext &sc,
 if (type_sp)
   return type_sp;
 
+DWARFDeclContext die_decl_ctx = SymbolFileDWARF::GetDWARFDeclContext(die);
+
 // type_sp = FindDefinitionTypeForDIE (dwarf_cu, die,
 // type_name_const_str);
-type_sp = dwarf->FindDefinitionTypeForDWARFDeclContext(die);
+type_sp = dwarf->FindDefinitionTypeForDWARFDeclContext(die_decl_ctx);
 
 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->FindDefinitionTypeForDWARFDeclContext(die);
+type_sp = debug_map_symfile->FindDefinitionTypeForDWARFDeclContext(
+die_decl_ctx);
   }
 }
 

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.h
index fa776f27d5019..e46694405415b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.h
@@ -75,10 +75,15 @@ class DWARFDeclContext {
 m_qualified_name.clear();
   }
 
+  lldb::LanguageType GetLanguage() const { return m_language; }
+
+  void SetLanguage(lldb::LanguageType language) { m_language = language; }
+
 protected:
   typedef std::vector collection;
   collection m_entries;
   mutable std::string m_qualified_name;
+  lldb::LanguageType m_language = lldb::eLanguageTypeUnknown;
 };
 
 #endif // LLDB_SOURCE_PLUGINS_SYMBOLFILE_DWARF_DWARFDECLCONTEXT_H

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 0a48dc1679336..fef2a36384703 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -2946,113 +2946,119 @@ bool SymbolFileDWARF::DIEDeclContextsMatch(const 
DWARFDIE &die1,
   return true;
 }
 
-TypeSP
-SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE &die) {
+TypeSP SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(
+const DWARFDeclContext &dwarf_decl_ctx) {
   TypeSP type_sp;
 
-  const ConstString type_name(die.GetName());
-  if (type_name) {
-const dw_tag_t tag = die.Tag();
-
-Log *log = GetLog(DWARFLog::TypeCompletion | DWARFLog::L

[Lldb-commits] [PATCH] D138612: [lldb][NFC] Change FindDefinitionTypeForDWARFDeclContext() to take DWARFDIE

2022-11-25 Thread Jason Molenda via Phabricator via lldb-commits 
jasonmolenda added a comment.

Reverted for now.

  commit 1df47dbe131d2aed676d9d5e0441ff4b61fec018
  Author: Jason Molenda 
  Date:   Fri Nov 25 12:11:37 2022 -0800
  
  Revert "[lldb][NFC] Change FindDefinitionTypeForDWARFDeclContext() to 
take DWARFDIE"
  
  The changes in https://reviews.llvm.org/D138612 cause a testsuite
  failure on Darwin systems in TestCPPAccelerator.py, first flagged
  by the "LLDB Incremental" CI bot.
  https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/
  with the specific failure text appended to the phabracator.
  
  This reverts commit c3c423b6cb2e1c00483e951ce8cc4d935e31cd14.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138612/new/

https://reviews.llvm.org/D138612

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

[Lldb-commits] [lldb] f6d4e68 - Revert "[LLDB] Do not dereference promise pointer in `coroutine_handle` pretty printer"

2022-11-25 Thread Jason Molenda via lldb-commits 

Author: Jason Molenda
Date: 2022-11-25T12:22:58-08:00
New Revision: f6d4e687172ab14728c569a0c1d3eb1c76021250

URL: 
https://github.com/llvm/llvm-project/commit/f6d4e687172ab14728c569a0c1d3eb1c76021250
DIFF: 
https://github.com/llvm/llvm-project/commit/f6d4e687172ab14728c569a0c1d3eb1c76021250.diff

LOG: Revert "[LLDB] Do not dereference promise pointer in `coroutine_handle` 
pretty printer"

This reverts commit cd3091a88f7c55c90d9b5fff372ce1cdfc71948d.

This change crashes on macOS systems in
formatters::StdlibCoroutineHandleSyntheticFrontEnd when
it fails to create the `ValueObjectSP promise` and calls
a method on it.  The failure causes a segfault while running
TestCoroutineHandle.py on the "LLDB Incremental" CI bot,
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/

This change originally landed via https://reviews.llvm.org/D132815

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
lldb/source/Plugins/Language/CPlusPlus/Coroutines.h

lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index f579a0160b2b7..63bad9d0241de 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -246,7 +246,7 @@ def which(program):
 
 class ValueCheck:
 def __init__(self, name=None, value=None, type=None, summary=None,
- children=None, dereference=None):
+ children=None):
 """
 :param name: The name that the SBValue should have. None if the summary
  should not be checked.
@@ -261,15 +261,12 @@ def __init__(self, name=None, value=None, type=None, 
summary=None,
  The order of checks is the order of the checks in the
  list. The number of checks has to match the number of
  children.
-:param dereference: A ValueCheck for the SBValue returned by the
-`Dereference` function.
 """
 self.expect_name = name
 self.expect_value = value
 self.expect_type = type
 self.expect_summary = summary
 self.children = children
-self.dereference = dereference
 
 def check_value(self, test_base, val, error_msg=None):
 """
@@ -311,9 +308,6 @@ def check_value(self, test_base, val, error_msg=None):
 if self.children is not None:
 self.check_value_children(test_base, val, error_msg)
 
-if self.dereference is not None:
-self.dereference.check_value(test_base, val.Dereference(), 
error_msg)
-
 def check_value_children(self, test_base, val, error_msg=None):
 """
 Checks that the children of a SBValue match a certain structure and

diff  --git a/lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
index 7e1302c7eb785..aa6a6ef7e56ae 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
@@ -17,36 +17,35 @@ using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::formatters;
 
-static lldb::addr_t GetCoroFramePtrFromHandle(ValueObjectSP valobj_sp) {
+static ValueObjectSP GetCoroFramePtrFromHandle(ValueObject &valobj) {
+  ValueObjectSP valobj_sp(valobj.GetNonSyntheticValue());
   if (!valobj_sp)
-return LLDB_INVALID_ADDRESS;
+return nullptr;
 
   // We expect a single pointer in the `coroutine_handle` class.
   // We don't care about its name.
   if (valobj_sp->GetNumChildren() != 1)
-return LLDB_INVALID_ADDRESS;
+return nullptr;
   ValueObjectSP ptr_sp(valobj_sp->GetChildAtIndex(0, true));
   if (!ptr_sp)
-return LLDB_INVALID_ADDRESS;
+return nullptr;
   if (!ptr_sp->GetCompilerType().IsPointerType())
-return LLDB_INVALID_ADDRESS;
-
-  AddressType addr_type;
-  lldb::addr_t frame_ptr_addr = ptr_sp->GetPointerValue(&addr_type);
-  if (!frame_ptr_addr || frame_ptr_addr == LLDB_INVALID_ADDRESS)
-return LLDB_INVALID_ADDRESS;
-  lldbassert(addr_type == AddressType::eAddressTypeLoad);
-  if (addr_type != AddressType::eAddressTypeLoad)
-return LLDB_INVALID_ADDRESS;
+return nullptr;
 
-  return frame_ptr_addr;
+  return ptr_sp;
 }
 
-static Function *ExtractFunction(lldb::TargetSP target_sp,
- lldb::addr_t frame_ptr_addr, int offset) {
-  lldb::ProcessSP process_sp = target_sp->GetProcessSP();
+static Function *ExtractFunction(ValueObjectSP &frame_ptr_sp, int offset) {
+  lldb::TargetSP target_sp = frame_ptr_sp->GetTargetSP();
+  lldb::ProcessSP process_sp = frame_ptr_sp->GetProcessSP();
   auto ptr_size = p

[Lldb-commits] [PATCH] D132815: [LLDB] Do not dereference promise pointer in `coroutine_handle` pretty printer

2022-11-25 Thread Jason Molenda via Phabricator via lldb-commits 
jasonmolenda added a comment.

I reverted this change for now to unblock the macOS CI bots.

  commit a410b34a66accd864b174b6330d3d353e73f54d8
  Author: Jason Molenda 
  Date:   Fri Nov 25 12:15:47 2022 -0800
  
  Revert "[LLDB] Do not dereference promise pointer in `coroutine_handle` 
pretty printer"
  
  This reverts commit cd3091a88f7c55c90d9b5fff372ce1cdfc71948d.
  
  This change crashes on macOS systems in
  formatters::StdlibCoroutineHandleSyntheticFrontEnd when
  it fails to create the `ValueObjectSP promise` and calls
  a method on it.  The failure causes a segfault while running
  TestCoroutineHandle.py on the "LLDB Incremental" CI bot,
  https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/
  
  This change originally landed via https://reviews.llvm.org/D132815

I saw in the description, " As noticed in https://reviews.llvm.org/D132624
by @labath, this can lead to an endless loop in lldb during printing
if the coroutine frame pointers form a cycle." - if we should revert further 
changes until this can be all addressed, that's fine, we'll see how the bots 
react.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132815/new/

https://reviews.llvm.org/D132815

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

[Lldb-commits] [lldb] 2b2f2f6 - Revert "[LLDB] Recognize `std::noop_coroutine()` in `std::coroutine_handle` pretty printer"

2022-11-25 Thread Jason Molenda via lldb-commits 

Author: Jason Molenda
Date: 2022-11-25T12:32:33-08:00
New Revision: 2b2f2f66141d52dc0d3082ddd12805d36872a189

URL: 
https://github.com/llvm/llvm-project/commit/2b2f2f66141d52dc0d3082ddd12805d36872a189
DIFF: 
https://github.com/llvm/llvm-project/commit/2b2f2f66141d52dc0d3082ddd12805d36872a189.diff

LOG: Revert "[LLDB] Recognize `std::noop_coroutine()` in 
`std::coroutine_handle` pretty printer"

This reverts commit 4346318f5c700f4e85f866610fb8328fc429319b.

This test case is failing on macOS, reverting until it can be
looked at more closely to unblock the macOS CI bots.

```
  File 
"/Volumes/work/llvm/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py",
 line 121, in test_libcpp
self.do_test(USE_LIBCPP)
  File 
"/Volumes/work/llvm/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py",
 line 45, in do_test
self.expect_expr("noop_hdl",
  File 
"/Volumes/work/llvm/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 2441, in expect_expr
value_check.check_value(self, eval_result, str(eval_result))
  File 
"/Volumes/work/llvm/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 306, in check_value
test_base.assertEqual(self.expect_summary, val.GetSummary(),
AssertionError: 'noop_coroutine' != 'coro frame = 0x14058'
- noop_coroutine+ coro frame = 0x14058 : (std::coroutine_handle) $1 = 
coro frame = 0x14058 {
  resume = 0x00013344 (a.out`___lldb_unnamed_symbol223)
  destroy = 0x00013344 (a.out`___lldb_unnamed_symbol223)
}
Checking SBValue: (std::coroutine_handle) $1 = coro frame = 0x14058 {
  resume = 0x00013344 (a.out`___lldb_unnamed_symbol223)
  destroy = 0x00013344 (a.out`___lldb_unnamed_symbol223)
}
```

Those lldb_unnamed_symbols are synthetic names that ObjectFileMachO
adds to the symbol table, most often seen with stripped binaries,
based off of the function start addresses for all the functions -
if a function has no symbol name, lldb adds one of these names.
This change was originally landed via https://reviews.llvm.org/D132624

Added: 


Modified: 
lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp

lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
index aa6a6ef7e56ae..bd9ff99db67b8 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
@@ -35,7 +35,7 @@ static ValueObjectSP GetCoroFramePtrFromHandle(ValueObject 
&valobj) {
   return ptr_sp;
 }
 
-static Function *ExtractFunction(ValueObjectSP &frame_ptr_sp, int offset) {
+static Function *ExtractDestroyFunction(ValueObjectSP &frame_ptr_sp) {
   lldb::TargetSP target_sp = frame_ptr_sp->GetTargetSP();
   lldb::ProcessSP process_sp = frame_ptr_sp->GetProcessSP();
   auto ptr_size = process_sp->GetAddressByteSize();
@@ -47,64 +47,24 @@ static Function *ExtractFunction(ValueObjectSP 
&frame_ptr_sp, int offset) {
   lldbassert(addr_type == AddressType::eAddressTypeLoad);
 
   Status error;
-  auto func_ptr_addr = frame_ptr_addr + offset * ptr_size;
-  lldb::addr_t func_addr =
-  process_sp->ReadPointerFromMemory(func_ptr_addr, error);
+  // The destroy pointer is the 2nd pointer inside the compiler-generated
+  // `pair`.
+  auto destroy_func_ptr_addr = frame_ptr_addr + ptr_size;
+  lldb::addr_t destroy_func_addr =
+  process_sp->ReadPointerFromMemory(destroy_func_ptr_addr, error);
   if (error.Fail())
 return nullptr;
 
-  Address func_address;
-  if (!target_sp->ResolveLoadAddress(func_addr, func_address))
+  Address destroy_func_address;
+  if (!target_sp->ResolveLoadAddress(destroy_func_addr, destroy_func_address))
 return nullptr;
 
-  return func_address.CalculateSymbolContextFunction();
-}
-
-static Function *ExtractResumeFunction(ValueObjectSP &frame_ptr_sp) {
-  return ExtractFunction(frame_ptr_sp, 0);
-}
-
-static Function *ExtractDestroyFunction(ValueObjectSP &frame_ptr_sp) {
-  return ExtractFunction(frame_ptr_sp, 1);
-}
-
-static bool IsNoopCoroFunction(Function *f) {
-  if (!f)
-return false;
-
-  // clang's `__builtin_coro_noop` gets lowered to
-  // `_NoopCoro_ResumeDestroy`. This is used by libc++
-  // on clang.
-  auto mangledName = f->GetMangled().GetMangledName();
-  if (mangledName == "__NoopCoro_ResumeDestroy")
-return true;
-
-  // libc++ uses the following name as a fallback on
-  // compilers without `__builtin_coro_noop`.
-  auto name = f->GetNameNoArguments();
-  static RegularExpression libcxxRegex(
-

[Lldb-commits] [PATCH] D132624: [LLDB] Devirtualize coroutine promise types for `std::coroutine_handle`

2022-11-25 Thread Jason Molenda via Phabricator via lldb-commits 
jasonmolenda added a comment.

I temporarily reverted this via

  commit 2b2f2f66141d52dc0d3082ddd12805d36872a189
  Author: Jason Molenda 
  Date:   Fri Nov 25 12:28:28 2022 -0800
  
  Revert "[LLDB] Recognize `std::noop_coroutine()` in 
`std::coroutine_handle` pretty printer"
  
  This reverts commit 4346318f5c700f4e85f866610fb8328fc429319b.
  
  This test case is failing on macOS, reverting until it can be
  looked at more closely to unblock the macOS CI bots.
  
File 
"/Volumes/work/llvm/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py",
 line 121, in test_libcpp
  self.do_test(USE_LIBCPP)
File 
"/Volumes/work/llvm/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py",
 line 45, in do_test
  self.expect_expr("noop_hdl",
File 
"/Volumes/work/llvm/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 2441, in expect_expr
  value_check.check_value(self, eval_result, str(eval_result))
File 
"/Volumes/work/llvm/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 306, in check_value
  test_base.assertEqual(self.expect_summary, val.GetSummary(),
  AssertionError: 'noop_coroutine' != 'coro frame = 0x14058'
  - noop_coroutine+ coro frame = 0x14058 : 
(std::coroutine_handle) $1 = coro frame = 0x14058 {
resume = 0x00013344 (a.out`___lldb_unnamed_symbol223)
destroy = 0x00013344 (a.out`___lldb_unnamed_symbol223)
  }
  Checking SBValue: (std::coroutine_handle) $1 = coro frame = 
0x14058 {
resume = 0x00013344 (a.out`___lldb_unnamed_symbol223)
destroy = 0x00013344 (a.out`___lldb_unnamed_symbol223)
  }
  
  Those lldb_unnamed_symbols are synthetic names that ObjectFileMachO
  adds to the symbol table, most often seen with stripped binaries,
  based off of the function start addresses for all the functions -
  if a function has no symbol name, lldb adds one of these names.
  This change was originally landed via https://reviews.llvm.org/D132624


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132624/new/

https://reviews.llvm.org/D132624

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

[Lldb-commits] [PATCH] D132624: [LLDB] Devirtualize coroutine promise types for `std::coroutine_handle`

2022-11-25 Thread Adrian Vogelsgesang via Phabricator via lldb-commits 
avogelsgesang added a comment.

@jasonmolenda I am a bit confused about your revert.
Did you indeed revert this change here? Afaict, you reverted 
https://reviews.llvm.org/D132735 and https://reviews.llvm.org/D132815, but left 
this commit in place. I did not actually read through your code changes, 
though, I only looked at the commit messages so far. Is my understanding of 
which commits you actually reverted correct?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132624/new/

https://reviews.llvm.org/D132624

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

[Lldb-commits] [PATCH] D138612: [lldb][NFC] Change FindDefinitionTypeForDWARFDeclContext() to take DWARFDIE

2022-11-25 Thread Jason Molenda via Phabricator via lldb-commits 
jasonmolenda added a comment.

FWIW when I was commenting on this last night, I hadn't realized that the test 
case was unmodified by the patch.   Reverting the patch until we can figure out 
the cause of the behavior change made the most sense.  The macOS incremental 
bot is green now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138612/new/

https://reviews.llvm.org/D138612

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

[Lldb-commits] [PATCH] D132624: [LLDB] Devirtualize coroutine promise types for `std::coroutine_handle`

2022-11-25 Thread Jason Molenda via Phabricator via lldb-commits 
jasonmolenda added a comment.

In D132624#3951525 , @avogelsgesang 
wrote:

> @jasonmolenda I am a bit confused about your revert.
> Did you indeed revert this change here? Afaict, you reverted 
> https://reviews.llvm.org/D132735 and https://reviews.llvm.org/D132815, but 
> left this commit in place. I did not actually read through your code changes, 
> though, I only looked at the commit messages so far. Is my understanding of 
> which commits you actually reverted correct?

Ah sigh. :(   I reverted both https://reviews.llvm.org/D132624 and 
https://reviews.llvm.org/D132735 -- failed to comment here in 
https://reviews.llvm.org/D132624 that I reverted the change, and put the 
comment about https://reviews.llvm.org/D132735 in the wrong phabracator.  I 
don't know how I got the two mixed up in so many ways ;) but they are both 
backed out right now and we have a green status on the macOS Incremental CI bot 
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/

The mixup I can see, but I don't know how I failed to comment in this one about 
it being reverted.  I must not have hit a Submit button, apologies.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132624/new/

https://reviews.llvm.org/D132624

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

Re: [Lldb-commits] green dragon testsuite crash on TestCoroutineHandle.py from coroutines formatter changes, temporarily revert?

2022-11-25 Thread Jason Molenda via lldb-commits 
Hi Adrian, thanks for digging in.  I am not sure about the policies of the 
builders, I think we had failing test cases for a bunch of days & it may have 
already been red when your change went in, so it wasn't detected as a change in 
status.  That might have something to do with it.  I thought the behavior was 
like you described, too.

I don't know what tools are installed on the builder but I'll ask around the 
office on Monday, I know there are people who are more familiar with how these 
bots are set up.

J

> On Nov 25, 2022, at 2:22 PM, Adrian Vogelsgesang 
>  wrote:
> 
> Hm... wait a second...
> 
> Which clang-version is 
> https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/ using? Is it using 
> an older version of clang? Does that version already contain the patch 
> https://reviews.llvm.org/D132580?
> 
> If not, that might explain things...
> 
> On Fri, Nov 25, 2022 at 11:18 PM Adrian Vogelsgesang 
>  wrote:
> Hi Jason,
> 
> Sorry for the late reply - your mail got caught in my spam filter, and I just 
> realized about the build breakage now after you reverted the commits. Just to 
> confirm: 
> 
> I looked at the original change again, and I think I know what's going wrong 
> here: Devirtualization fails, and `promise_type` stays `void`. Obviously, 
> `CreateValueObjectFromAddress` cannot create an object of type `void` and 
> fails. The previous version was robust against that scenario, but 
> https://reviews.llvm.org/D132815 accidentally regressed this.
> 
> If a program has all the expected debug info, devirtualization should never 
> fail and `promise_type` never stays `void`. It seems something is 
> wrong/unexpected with the debug info on Darwin. Devirtualization relies on 
> being able to identify the function pointer of the `destroy` function and 
> inspects that function. So the root cause seems to be the same as for the 
> revert 
> https://github.com/llvm/llvm-project/commit/2b2f2f66141d52dc0d3082ddd12805d36872a189:
>  For some reason, the debugger cannot find debug info for the function 
> pointed to by the `destroy` function.
> 
> However, I still don't quite understand what's wrong with the debug info on 
> Mac.
> 
> Either way, the pretty printer should of course be robust against such 
> unexpected debug info. I think a simple additional check should be enough to 
> make this robust so we no longer crash:
> if (!promise_type.isVoid()) { // < additional check
>   lldb::ValueObjectSP promise = CreateValueObjectFromAddress(
>   "promise", frame_ptr_addr + 2 * ptr_size, exe_ctx, promise_type);
>   Status error;
>   lldb::ValueObjectSP promisePtr = promise->AddressOf(error);
>   if (error.Success())
> m_promise_ptr_sp = promisePtr->Clone(ConstString("promise"));
> }
> 
> Meta question: I am a bit confused about 
> https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/. I thought LLVM's 
> buildbots were set up to send an email in case somebody breaks the build. 
> Also, I made sure that all builds in https://lab.llvm.org/buildbot/#/builders 
> stayed green after my commit. So what are the expectations around which CIs 
> need to stay green after a commit? Do I need to setup anything such that 
> green.lab.llvm.org also sends me an email if I break it?
> 
> Cheers,
> Adrian
> 
> On Thu, Nov 24, 2022 at 10:50 PM Jason Molenda  wrote:
> Ah, little misstatement below.  My first thought was that promise_type was 
> null, but when I stepped through here with a debugger, it was not.  I didn't 
> know how to dig in to a CompilerType object but there was some reason why 
> this CreateValueObjectFromAddress failed to return an actual ValueObject, and 
> I assumed it's something to do with that CompilerType.  But I didn't dig in 
> far enough to understand what the issue in the type was.
> 
> > On Nov 24, 2022, at 1:20 PM, Jason Molenda  wrote:
> > 
> > Hi Adrian, the green dragon Incremental CI bot has been failing the past 
> > couple of days after the changes for the coroutines formatter, most 
> > directly   https://reviews.llvm.org/D132815 landed - TestCoroutineHandle.py 
> > results in a segfault on Darwin systems (both on the CI and on my mac 
> > desktop) consistently.   
> > https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/
> > 
> > It's crashing in formatters::StdlibCoroutineHandleSyntheticFrontEnd where 
> > you're doing
> > 
> > ```
> >  // Add the `promise` member. We intentionally add `promise` as a pointer 
> > type
> >  // instead of a value type, and don't automatically dereference this 
> > pointer.
> >  // We do so to avoid potential very deep recursion in case there is a 
> > cycle in
> >  // formed between `std::coroutine_handle`s and their promises.
> >  lldb::ValueObjectSP promise = CreateValueObjectFromAddress(
> >  "promise", frame_ptr_addr + 2 * ptr_size, exe_ctx, promise_type);
> >  Status error;
> >  lldb::ValueObjectSP promisePtr = promise->AddressOf(error);
> > ```
> > 
> > and the promise_type dose not have a CompilerType so pr

Re: [Lldb-commits] green dragon testsuite crash on TestCoroutineHandle.py from coroutines formatter changes, temporarily revert?

2022-11-25 Thread Jason Molenda via lldb-commits 
FWIW I could repo promise_type failure on my macOS desktop which has the 
current Xcode 14 tools installed, but I can't tell you exactly what this 
corresponds to in github hash terms (it's "Apple clang version 14.0.0 
(clang-1400.0.29.100)"), I think it was originally branched 2021-10-26, 
although there have been a lot of cherrypicks pulled in too, so it's not an 
exact snapshot of October 26 sources.

J

> On Nov 25, 2022, at 2:22 PM, Adrian Vogelsgesang 
>  wrote:
> 
> Hm... wait a second...
> 
> Which clang-version is 
> https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/ using? Is it using 
> an older version of clang? Does that version already contain the patch 
> https://reviews.llvm.org/D132580?
> 
> If not, that might explain things...
> 
> On Fri, Nov 25, 2022 at 11:18 PM Adrian Vogelsgesang 
>  wrote:
> Hi Jason,
> 
> Sorry for the late reply - your mail got caught in my spam filter, and I just 
> realized about the build breakage now after you reverted the commits. Just to 
> confirm: 
> 
> I looked at the original change again, and I think I know what's going wrong 
> here: Devirtualization fails, and `promise_type` stays `void`. Obviously, 
> `CreateValueObjectFromAddress` cannot create an object of type `void` and 
> fails. The previous version was robust against that scenario, but 
> https://reviews.llvm.org/D132815 accidentally regressed this.
> 
> If a program has all the expected debug info, devirtualization should never 
> fail and `promise_type` never stays `void`. It seems something is 
> wrong/unexpected with the debug info on Darwin. Devirtualization relies on 
> being able to identify the function pointer of the `destroy` function and 
> inspects that function. So the root cause seems to be the same as for the 
> revert 
> https://github.com/llvm/llvm-project/commit/2b2f2f66141d52dc0d3082ddd12805d36872a189:
>  For some reason, the debugger cannot find debug info for the function 
> pointed to by the `destroy` function.
> 
> However, I still don't quite understand what's wrong with the debug info on 
> Mac.
> 
> Either way, the pretty printer should of course be robust against such 
> unexpected debug info. I think a simple additional check should be enough to 
> make this robust so we no longer crash:
> if (!promise_type.isVoid()) { // < additional check
>   lldb::ValueObjectSP promise = CreateValueObjectFromAddress(
>   "promise", frame_ptr_addr + 2 * ptr_size, exe_ctx, promise_type);
>   Status error;
>   lldb::ValueObjectSP promisePtr = promise->AddressOf(error);
>   if (error.Success())
> m_promise_ptr_sp = promisePtr->Clone(ConstString("promise"));
> }
> 
> Meta question: I am a bit confused about 
> https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/. I thought LLVM's 
> buildbots were set up to send an email in case somebody breaks the build. 
> Also, I made sure that all builds in https://lab.llvm.org/buildbot/#/builders 
> stayed green after my commit. So what are the expectations around which CIs 
> need to stay green after a commit? Do I need to setup anything such that 
> green.lab.llvm.org also sends me an email if I break it?
> 
> Cheers,
> Adrian
> 
> On Thu, Nov 24, 2022 at 10:50 PM Jason Molenda  wrote:
> Ah, little misstatement below.  My first thought was that promise_type was 
> null, but when I stepped through here with a debugger, it was not.  I didn't 
> know how to dig in to a CompilerType object but there was some reason why 
> this CreateValueObjectFromAddress failed to return an actual ValueObject, and 
> I assumed it's something to do with that CompilerType.  But I didn't dig in 
> far enough to understand what the issue in the type was.
> 
> > On Nov 24, 2022, at 1:20 PM, Jason Molenda  wrote:
> > 
> > Hi Adrian, the green dragon Incremental CI bot has been failing the past 
> > couple of days after the changes for the coroutines formatter, most 
> > directly   https://reviews.llvm.org/D132815 landed - TestCoroutineHandle.py 
> > results in a segfault on Darwin systems (both on the CI and on my mac 
> > desktop) consistently.   
> > https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/
> > 
> > It's crashing in formatters::StdlibCoroutineHandleSyntheticFrontEnd where 
> > you're doing
> > 
> > ```
> >  // Add the `promise` member. We intentionally add `promise` as a pointer 
> > type
> >  // instead of a value type, and don't automatically dereference this 
> > pointer.
> >  // We do so to avoid potential very deep recursion in case there is a 
> > cycle in
> >  // formed between `std::coroutine_handle`s and their promises.
> >  lldb::ValueObjectSP promise = CreateValueObjectFromAddress(
> >  "promise", frame_ptr_addr + 2 * ptr_size, exe_ctx, promise_type);
> >  Status error;
> >  lldb::ValueObjectSP promisePtr = promise->AddressOf(error);
> > ```
> > 
> > and the promise_type dose not have a CompilerType so promisePtr is nullptr 
> > and we crash on the method call to AddressOf. I looked briefly, but this 
> > isn't

[Lldb-commits] [PATCH] D138724: [lldb][Target] Flush the scratch TypeSystem when process gets deleted

2022-11-25 Thread Michael Buch via Phabricator via lldb-commits 
Michael137 updated this revision to Diff 478044.
Michael137 added a comment.

- Update comment


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138724/new/

https://reviews.llvm.org/D138724

Files:
  lldb/source/Target/Target.cpp
  lldb/test/API/functionalities/rerun_and_expr/Makefile
  lldb/test/API/functionalities/rerun_and_expr/TestRerunAndExpr.py
  lldb/test/API/functionalities/rerun_and_expr/main.cpp
  lldb/test/API/functionalities/rerun_and_expr/rebuild.cpp

Index: lldb/test/API/functionalities/rerun_and_expr/rebuild.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/rerun_and_expr/rebuild.cpp
@@ -0,0 +1,12 @@
+struct Base {
+  int m_base_val = 42;
+};
+
+struct Foo : public Base {
+  int m_derived_val = 137;
+};
+
+int main() {
+  Foo foo;
+  return 0;
+}
Index: lldb/test/API/functionalities/rerun_and_expr/main.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/rerun_and_expr/main.cpp
@@ -0,0 +1,8 @@
+struct Foo {
+  int m_val = 42;
+};
+
+int main() {
+  Foo foo;
+  return 0;
+}
Index: lldb/test/API/functionalities/rerun_and_expr/TestRerunAndExpr.py
===
--- /dev/null
+++ lldb/test/API/functionalities/rerun_and_expr/TestRerunAndExpr.py
@@ -0,0 +1,71 @@
+"""
+Test that re-running a process from within the same target
+after rebuilding the executable flushes the scratch TypeSystems
+tied to that process.
+"""
+
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestRerun(TestBase):
+def test(self):
+"""
+Tests whether re-launching a process without destroying
+the owning target keeps invalid ASTContexts in the
+scratch AST's importer.
+
+We test this by:
+1. Evaluating an expression to import 'struct Foo' into
+   the scratch AST
+2. Change the definition of 'struct Foo' and rebuild the executable
+3. Re-launch the process
+4. Evaluate the same expression in (1). We expect to have only
+   the latest definition of 'struct Foo' in the scratch AST.
+"""
+self.build(dictionary={'CXX_SOURCES':'main.cpp', 'EXE':'a.out'})
+(target, _, _, bkpt) = \
+lldbutil.run_to_source_breakpoint(self, 'return', lldb.SBFileSpec('main.cpp'))
+
+target.BreakpointCreateBySourceRegex('return', lldb.SBFileSpec('rebuild.cpp', False))
+
+self.expect_expr('foo', result_type='Foo', result_children=[
+ValueCheck(name='m_val', value='42')
+])
+
+self.build(dictionary={'CXX_SOURCES':'rebuild.cpp', 'EXE':'a.out'})
+
+self.runCmd('process launch')
+
+self.expect_expr('foo', result_type='Foo', result_children=[
+ValueCheck(name='Base', children=[
+ValueCheck(name='m_base_val', value='42')
+]),
+ValueCheck(name='m_derived_val', value='137')
+])
+
+self.filecheck("target module dump ast", __file__)
+
+# The new definition 'struct Foo' is in the scratch AST
+# CHECK:  |-CXXRecordDecl {{.*}} struct Foo definition
+# CHECK-NEXT: | |-DefinitionData pass_in_registers standard_layout trivially_copyable trivial literal
+# CHECK-NEXT: | | |-DefaultConstructor exists trivial needs_implicit
+# CHECK-NEXT: | | |-CopyConstructor simple trivial has_const_param needs_implicit implicit_has_const_param
+# CHECK-NEXT: | | |-MoveConstructor exists simple trivial needs_implicit
+# CHECK-NEXT: | | |-CopyAssignment simple trivial has_const_param needs_implicit implicit_has_const_param
+# CHECK-NEXT: | | |-MoveAssignment exists simple trivial needs_implicit
+# CHECK-NEXT: | | `-Destructor simple irrelevant trivial needs_implicit
+# CHECK-NEXT: | |-public 'Base'
+# CHECK-NEXT: | `-FieldDecl {{.*}} m_derived_val 'int'
+# CHECK-NEXT: `-CXXRecordDecl {{.*}} struct Base definition
+# CHECK-NEXT:   |-DefinitionData pass_in_registers aggregate standard_layout trivially_copyable pod trivial literal
+# CHECK-NEXT:   | |-DefaultConstructor exists trivial needs_implicit
+# CHECK-NEXT:   | |-CopyConstructor simple trivial has_const_param needs_implicit implicit_has_const_param
+# CHECK-NEXT:   | |-MoveConstructor exists simple trivial needs_implicit
+# CHECK-NEXT:   | |-CopyAssignment simple trivial has_const_param needs_implicit implicit_has_const_param
+# CHECK-NEXT:   | |-MoveAssignment exists simple trivial needs_implicit
+# CHECK-NEXT:   | `-Destructor simple irrelevant trivial needs_implicit
+
+# ...but the original definition of 'struct Foo' is not in the scratch AST anymore
+# CHECK-NOT: FieldDecl {{.*}} m_val 'int'
+
Index: lldb/test/API/func