[Lldb-commits] [lldb] 455098d - Revert "[lldb/Target] Delay image loading after corefile process creation (#70351)"

2023-10-31 Thread Med Ismail Bennani via lldb-commits

Author: Med Ismail Bennani
Date: 2023-10-31T20:35:25-07:00
New Revision: 455098d8073483e0fa40557100cfb717ea466818

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

LOG: Revert "[lldb/Target] Delay image loading after corefile process creation 
(#70351)"

This reverts commit 3c727a959d1c479ef284471701faa0e8ac6f427e because it
introduced some test failures:

https://lab.llvm.org/buildbot/#/builders/68/builds/62638

```

Failed Tests (5):
  lldb-api :: functionalities/postmortem/elf-core/TestLinuxCore.py
  lldb-api :: functionalities/postmortem/mach-core/TestMachCore.py
  lldb-api :: functionalities/postmortem/netbsd-core/TestNetBSDCore.py
  lldb-api :: 
functionalities/unwind/noreturn/module-end/TestNoReturnModuleEnd.py
  lldb-api :: tools/lldb-dap/coreFile/TestDAP_coreFile.py
```

Signed-off-by: Med Ismail Bennani 

Added: 


Modified: 
lldb/include/lldb/Target/Process.h
lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
lldb/source/Target/Process.cpp

Removed: 
lldb/test/API/functionalities/script-resource-loading/Makefile

lldb/test/API/functionalities/script-resource-loading/TestScriptResourceLoading.py
lldb/test/API/functionalities/script-resource-loading/main.cpp

lldb/test/API/functionalities/script-resource-loading/my_scripting_resource.py



diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index e25e82302a56dd9..a6d3e6c2d16926e 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -614,8 +614,6 @@ class Process : public 
std::enable_shared_from_this,
 return error;
   }
 
-  virtual void DidLoadCore() {}
-
   /// The "ShadowListener" for a process is just an ordinary Listener that 
   /// listens for all the Process event bits.  It's convenient because you can
   /// specify it in the LaunchInfo or AttachInfo, so it will get events from

diff  --git a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp 
b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
index 9b10a0b832915d3..b11062a0224abc2 100644
--- a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
+++ b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
@@ -570,6 +570,8 @@ Status ProcessMachCore::DoLoadCore() {
 
   CreateMemoryRegions();
 
+  LoadBinariesAndSetDYLD();
+
   CleanupMemoryRegionPermissions();
 
   AddressableBits addressable_bits = core_objfile->GetAddressableBits();
@@ -578,8 +580,6 @@ Status ProcessMachCore::DoLoadCore() {
   return error;
 }
 
-void ProcessMachCore::DidLoadCore() { LoadBinariesAndSetDYLD(); }
-
 lldb_private::DynamicLoader *ProcessMachCore::GetDynamicLoader() {
   if (m_dyld_up.get() == nullptr)
 m_dyld_up.reset(DynamicLoader::FindPlugin(this, m_dyld_plugin_name));

diff  --git a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.h 
b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
index 0e61daa625b53cc..c8820209e3f3830 100644
--- a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
+++ b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
@@ -46,8 +46,6 @@ class ProcessMachCore : public 
lldb_private::PostMortemProcess {
   // Creating a new process, or attaching to an existing one
   lldb_private::Status DoLoadCore() override;
 
-  void DidLoadCore() override;
-
   lldb_private::DynamicLoader *GetDynamicLoader() override;
 
   // PluginInterface protocol

diff  --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index f4bacf314dd746a..f82ab05362fbee9 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -2639,6 +2639,19 @@ Status Process::LoadCore() {
 else
   StartPrivateStateThread();
 
+DynamicLoader *dyld = GetDynamicLoader();
+if (dyld)
+  dyld->DidAttach();
+
+GetJITLoaders().DidAttach();
+
+SystemRuntime *system_runtime = GetSystemRuntime();
+if (system_runtime)
+  system_runtime->DidAttach();
+
+if (!m_os_up)
+  LoadOperatingSystemPlugin(false);
+
 // We successfully loaded a core file, now pretend we stopped so we can
 // show all of the threads in the core file and explore the crashed state.
 SetPrivateState(eStateStopped);
@@ -2655,23 +2668,7 @@ Status Process::LoadCore() {
 StateAsCString(state));
   error.SetErrorString(
   "Did not get stopped event after loading the core file.");
-} else {
-  DidLoadCore();
-
-  DynamicLoader *dyld = GetDynamicLoader();
-  if (dyld)
-dyld->DidAttach();
-
-  GetJITLoaders().DidAttach();
-
-  SystemRuntime *system_runtime = GetSystemRuntime();
-  if (system_runtime)
-system_runtime->DidAttach();
-
-  if (!m_os_up)
-  

[Lldb-commits] [lldb] [lldb/Target] Delay image loading after corefile process creation (PR #70351)

2023-10-31 Thread Med Ismail Bennani via lldb-commits

medismailben wrote:

Reverting because this broke some tests:
```

Failed Tests (5):
  lldb-api :: functionalities/postmortem/elf-core/TestLinuxCore.py
  lldb-api :: functionalities/postmortem/mach-core/TestMachCore.py
  lldb-api :: functionalities/postmortem/netbsd-core/TestNetBSDCore.py
  lldb-api :: 
functionalities/unwind/noreturn/module-end/TestNoReturnModuleEnd.py
  lldb-api :: tools/lldb-dap/coreFile/TestDAP_coreFile.py
  ```

https://github.com/llvm/llvm-project/pull/70351
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [openmp] [flang] [clang-tools-extra] [clang] [lldb] [llvm] [libcxx] [compiler-rt] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

2023-10-31 Thread via lldb-commits

https://github.com/nmustakin edited 
https://github.com/llvm/llvm-project/pull/70667
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 3c727a9 - [lldb/Target] Delay image loading after corefile process creation (#70351)

2023-10-31 Thread via lldb-commits

Author: Med Ismail Bennani
Date: 2023-10-31T19:56:02-07:00
New Revision: 3c727a959d1c479ef284471701faa0e8ac6f427e

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

LOG: [lldb/Target] Delay image loading after corefile process creation (#70351)

Added: 
lldb/test/API/functionalities/script-resource-loading/Makefile

lldb/test/API/functionalities/script-resource-loading/TestScriptResourceLoading.py
lldb/test/API/functionalities/script-resource-loading/main.cpp

lldb/test/API/functionalities/script-resource-loading/my_scripting_resource.py

Modified: 
lldb/include/lldb/Target/Process.h
lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
lldb/source/Target/Process.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index a6d3e6c2d16926e..e25e82302a56dd9 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -614,6 +614,8 @@ class Process : public 
std::enable_shared_from_this,
 return error;
   }
 
+  virtual void DidLoadCore() {}
+
   /// The "ShadowListener" for a process is just an ordinary Listener that 
   /// listens for all the Process event bits.  It's convenient because you can
   /// specify it in the LaunchInfo or AttachInfo, so it will get events from

diff  --git a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp 
b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
index b11062a0224abc2..9b10a0b832915d3 100644
--- a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
+++ b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
@@ -570,8 +570,6 @@ Status ProcessMachCore::DoLoadCore() {
 
   CreateMemoryRegions();
 
-  LoadBinariesAndSetDYLD();
-
   CleanupMemoryRegionPermissions();
 
   AddressableBits addressable_bits = core_objfile->GetAddressableBits();
@@ -580,6 +578,8 @@ Status ProcessMachCore::DoLoadCore() {
   return error;
 }
 
+void ProcessMachCore::DidLoadCore() { LoadBinariesAndSetDYLD(); }
+
 lldb_private::DynamicLoader *ProcessMachCore::GetDynamicLoader() {
   if (m_dyld_up.get() == nullptr)
 m_dyld_up.reset(DynamicLoader::FindPlugin(this, m_dyld_plugin_name));

diff  --git a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.h 
b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
index c8820209e3f3830..0e61daa625b53cc 100644
--- a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
+++ b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
@@ -46,6 +46,8 @@ class ProcessMachCore : public 
lldb_private::PostMortemProcess {
   // Creating a new process, or attaching to an existing one
   lldb_private::Status DoLoadCore() override;
 
+  void DidLoadCore() override;
+
   lldb_private::DynamicLoader *GetDynamicLoader() override;
 
   // PluginInterface protocol

diff  --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index f82ab05362fbee9..f4bacf314dd746a 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -2639,19 +2639,6 @@ Status Process::LoadCore() {
 else
   StartPrivateStateThread();
 
-DynamicLoader *dyld = GetDynamicLoader();
-if (dyld)
-  dyld->DidAttach();
-
-GetJITLoaders().DidAttach();
-
-SystemRuntime *system_runtime = GetSystemRuntime();
-if (system_runtime)
-  system_runtime->DidAttach();
-
-if (!m_os_up)
-  LoadOperatingSystemPlugin(false);
-
 // We successfully loaded a core file, now pretend we stopped so we can
 // show all of the threads in the core file and explore the crashed state.
 SetPrivateState(eStateStopped);
@@ -2668,7 +2655,23 @@ Status Process::LoadCore() {
 StateAsCString(state));
   error.SetErrorString(
   "Did not get stopped event after loading the core file.");
+} else {
+  DidLoadCore();
+
+  DynamicLoader *dyld = GetDynamicLoader();
+  if (dyld)
+dyld->DidAttach();
+
+  GetJITLoaders().DidAttach();
+
+  SystemRuntime *system_runtime = GetSystemRuntime();
+  if (system_runtime)
+system_runtime->DidAttach();
+
+  if (!m_os_up)
+LoadOperatingSystemPlugin(false);
 }
+
 RestoreProcessEvents();
   }
   return error;

diff  --git a/lldb/test/API/functionalities/script-resource-loading/Makefile 
b/lldb/test/API/functionalities/script-resource-loading/Makefile
new file mode 100644
index 000..98d4eb86e95bfc8
--- /dev/null
+++ b/lldb/test/API/functionalities/script-resource-loading/Makefile
@@ -0,0 +1,5 @@
+CXX_SOURCES := main.cpp
+
+override ARCH := $(shell uname -m)
+
+include Makefile.rules

diff  --git 
a/lldb/test/API/functionalities/script-resource-loading/TestScriptResourceLoading.py
 

[Lldb-commits] [lldb] [lldb/Target] Delay image loading after corefile process creation (PR #70351)

2023-10-31 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben closed 
https://github.com/llvm/llvm-project/pull/70351
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] Don't ignore artificial variables and members for coroutines (PR #70779)

2023-10-31 Thread Michael Buch via lldb-commits


@@ -3061,7 +3061,8 @@ void DWARFASTParserClang::ParseSingleMember(
   // artificial member with (unnamed bitfield) padding.
   // FIXME: This check should verify that this is indeed an artificial member
   // we are supposed to ignore.
-  if (attrs.is_artificial) {
+  if (attrs.is_artificial &&
+  !TypeSystemClang::IsCoroutineFrameType(class_clang_type)) {

Michael137 wrote:

I do still wonder if we should just make a `ShouldIgnoreArtificialField` API 
that returns `true` for known fields we want to skip. The only ones that comes 
to mind are artificial variables that start with `_vptr$`

Not sure if there are some Objective-C artificial vars we want to skip. Maybe 
@jimingham or @adrian-prantl would know

https://github.com/llvm/llvm-project/pull/70779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] Don't ignore artificial variables and members for coroutines (PR #70779)

2023-10-31 Thread Michael Buch via lldb-commits


@@ -41,7 +41,10 @@ CPPLanguageRuntime::CPPLanguageRuntime(Process *process)
 : LanguageRuntime(process) {}
 
 bool CPPLanguageRuntime::IsAllowedRuntimeValue(ConstString name) {
-  return name == g_this;
+  // FIXME: use a list when the list grows more.
+  return name == g_this ||
+ name == ConstString("__promise") ||
+ name == ConstString("__coro_frame");

Michael137 wrote:

Any chance we can get the `Type` from the `Variable` in 
`CommandObjectFrameVariable` and can re-use the `IsCoroutineFrameType` check?

https://github.com/llvm/llvm-project/pull/70779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread Michael Buch via lldb-commits

Michael137 wrote:

> The DWARFASTParserClang.cpp will try to create the class from the DWARF for 
> the class definition. You will need to find the DW_TAG_variable when we are 
> creating the static field if there is no DW_AT_const_value in the 
> DW_TAG_member. But we also need to support the DW_AT_const_value being in the 
> DW_TAG_member since older DWARF will be emitted like this.

That's 100% correct. I was thinking, before [this 
block](https://github.com/llvm/llvm-project/blob/8b91de5d6a3f98dcc00bbd286e339e512f7e3682/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp#L2909-L2919)
 where we check for the existence of a `const_value_form`. With this patch such 
constant won't exist on the declaration. So I was thinking we would try to look 
for the definition. What's interesting is that with this patch, the expression 
evaluator successfully finds the DW_TAG_variable which have a location 
attribute but not if they have a constant instead of a location. It's probably 
some logic that assumes statics always have a location

> Are we going to emit a DW_AT_const_expr now in the DW_TAG_member? If so, then 
> we will know that we need to look for the DW_TAG_variable. I don't think 
> clang emitted the DW_AT_const_expr attribute before.

That wasn't part of this patch. But would make sense to add (i've noticed GCC 
adds that attribute)

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread Greg Clayton via lldb-commits

clayborg wrote:

> > > Few minor issues, but looks good to me. (you metnioned somewhere an lldb 
> > > issue I think with this patch when the value is removed from the static 
> > > member declaration inside the class? If that's a problem - probably hold 
> > > off on committing this until lldb's been fixed so this doesn't regress 
> > > things? And document the dependence clearly in the commit message)
> > 
> > 
> > I saw the patch to lldb to test that we can find global variables that are 
> > `constexpr`. In upstream, we can't use find global variables, but the 
> > expression parser does work for these. We should make sure that both 
> > `FindGlobalVariables(...)` and expression parsing work for all `constexpr` 
> > globals.
> 
> Yup, the expression evaluator finds them by looking at the 
> `DW_AT_const_value` on the declaration. But since we're moving that constant 
> onto the definition with this patch, that will break that codepath.
> 
> Looking into how best to address that now

The DWARFASTParserClang.cpp will try to create the class from the DWARF for the 
class definition. You will need to find the `DW_TAG_variable` when we are 
creating the static field if there is no `DW_AT_const_value` in the 
`DW_TAG_member`. But we also need to support the `DW_AT_const_value` being in 
the `DW_TAG_member` since older DWARF will be emitted like this. Are we going 
to emit a `DW_AT_const_expr` now in the `DW_TAG_member`? If so, then we will 
know that we need to look for the DW_TAG_variable. I don't think clang emitted 
the `DW_AT_const_expr` attribute before.

The other option it to just see if the expression parser works since global 
variables are found correctly. Maybe the same will happen in this case?

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread Michael Buch via lldb-commits

https://github.com/Michael137 updated 
https://github.com/llvm/llvm-project/pull/70639

>From 18db082fc5008283f77cc98d9c733a47c63b7096 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Fri, 27 Oct 2023 16:19:47 +0100
Subject: [PATCH 1/7] [clang][DebugInfo] Emit global variable definitions for
 static data members with constant initializers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When an LLDB user asks for the value of a static data member, LLDB starts by
searching the Names accelerator table for the corresponding variable definition
DIE. For static data members with out-of-class definitions that works fine,
because those get represented as global variables with a location and making 
them
eligible to be added to the Names table. However, in-class definitions won’t get
indexed because we usually don't emit global variables for them. So in DWARF
we end up with a single `DW_TAG_member` that usually holds the constant 
initializer.
But we don't get a corresponding CU-level `DW_TAG_variable` like we do for
out-of-class definitions.

To make it more convenient for debuggers to get to the value of inline static 
data members,
this patch makes sure we emit definitions for static variables with constant 
initializers
the same way we do for other static variables. This also aligns Clang closer to 
GCC, which
produces CU-level definitions for inline statics and also emits these into 
`.debug_pubnames`.

The implementation keeps track of newly created static data members. Then in
`CGDebugInfo::finalize`, we emit a global `DW_TAG_variable` with a 
`DW_AT_const_value` for
any of those declarations that didn't end up with a definition in the 
`DeclCache`.

The newly emitted `DW_TAG_variable` will look as follows:
```
0x007b:   DW_TAG_structure_type
DW_AT_calling_convention(DW_CC_pass_by_value)
DW_AT_name  ("Foo")
...

0x008d: DW_TAG_member
  DW_AT_name("i")
  DW_AT_type(0x0062 "const int")
  DW_AT_external(true)
  DW_AT_declaration (true)
  DW_AT_const_value (4)

Newly added
v

0x009a:   DW_TAG_variable
DW_AT_specification (0x008d "i")
DW_AT_const_value   (4)
DW_AT_linkage_name  ("_ZN2t2IiE1iIfEE")
```
---
 clang/lib/CodeGen/CGDebugInfo.cpp | 46 +++
 clang/lib/CodeGen/CGDebugInfo.h   |  6 ++
 clang/test/CodeGenCXX/debug-info-class.cpp| 13 ++-
 .../debug-info-static-inline-member.cpp   | 79 +++
 .../TestConstStaticIntegralMember.py  |  7 +-
 5 files changed, 144 insertions(+), 7 deletions(-)
 create mode 100644 clang/test/CodeGenCXX/debug-info-static-inline-member.cpp

diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 0aaf678bf287c6e..7529f114996d2ec 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -1693,6 +1693,7 @@ CGDebugInfo::CreateRecordStaticField(const VarDecl *Var, 
llvm::DIType *RecordTy,
   llvm::DIDerivedType *GV = DBuilder.createStaticMemberType(
   RecordTy, VName, VUnit, LineNumber, VTy, Flags, C, Align);
   StaticDataMemberCache[Var->getCanonicalDecl()].reset(GV);
+  StaticDataMemberDefinitionsToEmit.push_back(Var->getCanonicalDecl());
   return GV;
 }
 
@@ -5613,6 +5614,39 @@ void CGDebugInfo::EmitGlobalVariable(const ValueDecl 
*VD, const APValue ) {
   TemplateParameters, Align));
 }
 
+void CGDebugInfo::EmitGlobalVariable(const VarDecl *VD) {
+  assert(VD->hasInit());
+  assert(CGM.getCodeGenOpts().hasReducedDebugInfo());
+  if (VD->hasAttr())
+return;
+
+  auto  = DeclCache[VD];
+  if (GV)
+return;
+
+  auto const *InitVal = VD->evaluateValue();
+  if (!InitVal)
+return;
+
+  llvm::DIFile *Unit = nullptr;
+  llvm::DIScope *DContext = nullptr;
+  unsigned LineNo;
+  StringRef DeclName, LinkageName;
+  QualType T;
+  llvm::MDTuple *TemplateParameters = nullptr;
+  collectVarDeclProps(VD, Unit, LineNo, T, DeclName, LinkageName,
+  TemplateParameters, DContext);
+
+  auto Align = getDeclAlignIfRequired(VD, CGM.getContext());
+  llvm::DINodeArray Annotations = CollectBTFDeclTagAnnotations(VD);
+  llvm::DIExpression *InitExpr = createConstantValueExpression(VD, *InitVal);
+
+  GV.reset(DBuilder.createGlobalVariableExpression(
+  TheCU, DeclName, LinkageName, Unit, LineNo, getOrCreateType(T, Unit),
+  true, true, InitExpr, getOrCreateStaticDataMemberDeclarationOrNull(VD),
+  TemplateParameters, Align, Annotations));
+}
+
 void CGDebugInfo::EmitExternalVariable(llvm::GlobalVariable *Var,
const VarDecl *D) {
   assert(CGM.getCodeGenOpts().hasReducedDebugInfo());
@@ -5883,6 +5917,18 @@ void CGDebugInfo::finalize() {
 

[Lldb-commits] [lldb] [lldb/Target] Delay image loading after corefile process creation (PR #70351)

2023-10-31 Thread Greg Clayton via lldb-commits

https://github.com/clayborg approved this pull request.


https://github.com/llvm/llvm-project/pull/70351
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [flang] [compiler-rt] [clang] [lldb] [llvm] [openmp] [libcxx] [clang-tools-extra] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

2023-10-31 Thread via lldb-commits


@@ -274,7 +317,7 @@ struct RecordReplayTy {
   void saveKernelOutputInfo(const char *Name) {
 SmallString<128> OutputFilename = {
 Name, (isRecording() ? ".original.output" : ".replay.output")};

nmustakin wrote:

The motivation was to save the disk usage from the memory dumps. So having the 
diff dump along with entire dump defeats the purpose. The verification compares 
the `.original.output` to the `.replay.output` anyway. Since both are now 
replaced by diffs, the verification from the `llvm-omp-kernel-replay` tool just 
compares the diffs now. 

https://github.com/llvm/llvm-project/pull/70667
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [flang] [compiler-rt] [clang] [lldb] [llvm] [openmp] [libcxx] [clang-tools-extra] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

2023-10-31 Thread via lldb-commits


@@ -274,7 +317,7 @@ struct RecordReplayTy {
   void saveKernelOutputInfo(const char *Name) {
 SmallString<128> OutputFilename = {
 Name, (isRecording() ? ".original.output" : ".replay.output")};
-dumpDeviceMemory(OutputFilename);
+dumpDeviceMemory(OutputFilename, /*saveDiff*/ true);

nmustakin wrote:

saveDiff isn't always true. For pre-record memory dump, saveDiff is false (on 
line 302)

https://github.com/llvm/llvm-project/pull/70667
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Also log the error output from xcrun, if it fails. (PR #70716)

2023-10-31 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl closed 
https://github.com/llvm/llvm-project/pull/70716
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 15733fe - Also log the error output from xcrun, if it fails. (#70716)

2023-10-31 Thread via lldb-commits

Author: Adrian Prantl
Date: 2023-10-31T15:36:06-07:00
New Revision: 15733fe5f3cbf36ad1c9fbb0c6e4f31fdec224fa

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

LOG: Also log the error output from xcrun, if it fails. (#70716)

In the rare case that an Xcode installation is damaged, this output
could contain clues to further diagnose the issue.

rdar://117698630

Added: 


Modified: 
lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm

Removed: 




diff  --git a/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm 
b/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
index 33d94504fe70f8c..110a01732b2473a 100644
--- a/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
+++ b/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
@@ -417,6 +417,8 @@ static void ParseOSVersion(llvm::VersionTuple , 
NSString *Key) {
 // xcrun didn't find a matching SDK. Not an error, we'll try
 // 
diff erent spellings.
 LLDB_LOG(log, "xcrun returned exit code {0}", status);
+if (!output_str.empty())
+  LLDB_LOG(log, "xcrun output was:\n{0}", output_str);
 return "";
   }
   if (output_str.empty()) {



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


[Lldb-commits] [lldb] [lldb][AArch64] Add SME2's ZT0 register (PR #70205)

2023-10-31 Thread Jason Molenda via lldb-commits


@@ -624,6 +661,21 @@ 
NativeRegisterContextLinux_arm64::CacheAllRegisters(uint32_t _size) {
 error = ReadZA();
 if (error.Fail())
   return error;
+
+// We will only be restoring ZT data if ZA is active. As writing to an
+// inactive ZT enables ZA, which may not be desireable.
+if (
+// If we have ZT0, or in other words, if we have SME2.
+GetRegisterInfo().IsZTPresent() &&
+// And ZA is active, which means that ZT0 is also active.
+m_za_header.size > sizeof(m_za_header)) {
+  cached_size += sizeof(RegisterSetType) + GetZTBufferSize();
+  // Unlike ZA where we have to fake data for an inactive ZA, the kernel
+  // handles an inactive ZA for us and always returns some data.

jasonmolenda wrote:

I get what this is saying but maybe "the kernel handles an inactive ZT0 for us" 
would be clearer.

https://github.com/llvm/llvm-project/pull/70205
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][AArch64] Add SME2's ZT0 register (PR #70205)

2023-10-31 Thread Jason Molenda via lldb-commits


@@ -488,6 +508,12 @@ bool RegisterInfoPOSIX_arm64::IsSMERegZA(unsigned reg) 
const {
   return reg == m_sme_regnum_collection[2];
 }
 
+bool RegisterInfoPOSIX_arm64::IsSMERegZT(unsigned reg) const {
+  // ZT0 is part of the SME register set only if SME2 is present.
+  return m_sme_regnum_collection.size() == 4 &&
+ reg == m_sme_regnum_collection.back();

jasonmolenda wrote:

Do you think it might be better to check if the register number is contained in 
`m_sme_rengum_collection` instead of expecting there to be 4 registers and this 
is the last one?  It seems like this is could be a bug when we get another 
register in the next SME update in the future.

https://github.com/llvm/llvm-project/pull/70205
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][AArch64] Add SME2's ZT0 register (PR #70205)

2023-10-31 Thread Jason Molenda via lldb-commits

https://github.com/jasonmolenda edited 
https://github.com/llvm/llvm-project/pull/70205
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][AArch64] Add SME2's ZT0 register (PR #70205)

2023-10-31 Thread Jason Molenda via lldb-commits

https://github.com/jasonmolenda approved this pull request.

Looks good to me, a few small comments inlined.  Mostly the problem I have is 
that every time I see "ZA" I think of old teenage mutant ninja turtles who 
referred to pizza as "za" and it makes it very difficult to read this patch.

https://github.com/llvm/llvm-project/pull/70205
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][AArch64] Add SME2's ZT0 register (PR #70205)

2023-10-31 Thread Jason Molenda via lldb-commits


@@ -580,7 +616,8 @@ enum RegisterSetType : uint32_t {
   // Pointer authentication registers are read only, so not included here.
   MTE,
   TLS,
-  SME, // ZA only, SVCR and SVG are pseudo registers.
+  SME,  // ZA only , SVCR and SVG are pseudo registers.

jasonmolenda wrote:

"only , SVCR" -> "only, SVCR".

https://github.com/llvm/llvm-project/pull/70205
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/Target] Delay image loading after corefile process creation (PR #70351)

2023-10-31 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere approved this pull request.

LGTM per my last comment.

https://github.com/llvm/llvm-project/pull/70351
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/Target] Delay image loading after corefile process creation (PR #70351)

2023-10-31 Thread Jonas Devlieghere via lldb-commits


@@ -614,6 +614,8 @@ class Process : public 
std::enable_shared_from_this,
 return error;
   }
 
+  virtual void DidLoadCore() {}

JDevlieghere wrote:

Okay, so if semantically this doesn't make sense (which is what I'm hearing) 
then I don't why we would reuse `DidAttach` (besides it just happens to be 
there and unused in the core case) and we should have a `DidLoadCore` as per 
the current patch. 

https://github.com/llvm/llvm-project/pull/70351
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread Michael Buch via lldb-commits

Michael137 wrote:

> > Few minor issues, but looks good to me. (you metnioned somewhere an lldb 
> > issue I think with this patch when the value is removed from the static 
> > member declaration inside the class? If that's a problem - probably hold 
> > off on committing this until lldb's been fixed so this doesn't regress 
> > things? And document the dependence clearly in the commit message)
> 
> I saw the patch to lldb to test that we can find global variables that are 
> `constexpr`. In upstream, we can't use find global variables, but the 
> expression parser does work for these. We should make sure that both 
> `FindGlobalVariables(...)` and expression parsing work for all `constexpr` 
> globals.

Yup, the expression evaluator finds them by looking at the `DW_AT_const_value` 
on the declaration. But since we're moving that constant onto the definition 
with this patch, that will break that codepath.

Looking into how best to address that now

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread Greg Clayton via lldb-commits

clayborg wrote:

> Few minor issues, but looks good to me. (you metnioned somewhere an lldb 
> issue I think with this patch when the value is removed from the static 
> member declaration inside the class? If that's a problem - probably hold off 
> on committing this until lldb's been fixed so this doesn't regress things? 
> And document the dependence clearly in the commit message)

I saw the patch to lldb to test that we can find global variables that are 
`constexpr`. In upstream, we can't use find global variables, but the 
expression parser does work for these. We should make sure that both 
`FindGlobalVariables(...)` and expression parsing work for all `constexpr` 
globals.

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread Michael Buch via lldb-commits

Michael137 wrote:

> size report sounds generally OK - but there's a bunch of what look like 
> unrelated or strange results in there, perhaps they weren't compared at 
> exactly the same version? (like why did the apple_names size go down? How did 
> the .text and .debuG_line size change at all? )

Yea I was confused about that too. Might've mixed up commits of the control 
build. Did measurements again and here's what I got:
```
$ bloaty `find ./patched-build/lib -name *.o `  │ $ bloaty `find 
./no-patch-build/lib -name *.o `
FILE SIZEVM SIZE│FILE SIZEVM 
SIZE
 --  -- │ --  
-- 
  54.6%  2.02Gi  60.3%  2.02Gi,__debug_str  │  54.5%  2.01Gi  60.3%  
2.01Gi,__debug_str
  22.0%   834Mi  24.3%   834Mi,__debug_info │  22.1%   833Mi  24.4%   
833Mi,__debug_info
   6.2%   236Mi   0.0%   0String Table  │   6.2%   236Mi   0.0% 
  0String Table
   4.5%   170Mi   5.0%   170Mi,__text   │   4.5%   170Mi   5.0%   
170Mi,__text
   2.6%  97.6Mi   2.8%  97.6Mi,__debug_line │   2.6%  98.6Mi   2.9%  
98.6Mi,__debug_line
   2.3%  88.0Mi   2.6%  88.0Mi,__apple_types│   2.3%  88.0Mi   2.6%  
88.0Mi,__apple_types
   2.2%  83.1Mi   2.4%  83.1Mi,__apple_names│   2.2%  81.8Mi   0.0% 
  0[Unmapped]
   2.2%  81.8Mi   0.0%   0[Unmapped]│   2.1%  77.8Mi   2.3%  
77.8Mi,__apple_names
   1.7%  65.6Mi   1.9%  65.6Mi,__compact_unwind │   1.7%  65.6Mi   1.9%  
65.6Mi,__compact_unwind
   1.0%  39.2Mi   0.0%   0Symbol Table  │   1.0%  39.2Mi   0.0% 
  0Symbol Table
   0.2%  8.05Mi   0.2%  8.05Mi,__const  │   0.2%  8.05Mi   0.2%  
8.05Mi,__const
   0.2%  7.91Mi   0.2%  7.91Mi,__cstring│   0.2%  7.92Mi   0.2%  
7.92Mi,__cstring
   0.1%  5.05Mi   0.1%  5.05Mi,__debug_abbrev   │   0.1%  5.22Mi   0.2%  
5.22Mi,__debug_abbrev
   0.1%  2.31Mi   0.0%   0[Mach-O Headers]  │   0.1%  2.31Mi   0.0% 
  0[Mach-O Headers]
   0.0%  1.38Mi   0.0%  1.38Mi,__debug_ranges   │   0.0%  1.38Mi   0.0%  
1.38Mi,__debug_ranges
   0.0%   994Ki   0.0%   994Ki,__apple_namespac │   0.0%   994Ki   0.0%   
994Ki,__apple_namespac
   0.0%   0   0.0%   354Ki,__bss│   0.0%   0   0.0%   
354Ki,__bss
   0.0%   324Ki   0.0%   324Ki,__data   │   0.0%   324Ki   0.0%   
324Ki,__data
   0.0%   283Ki   0.0%   283Ki,__StaticInit │   0.0%   283Ki   0.0%   
283Ki,__StaticInit
   0.0%  31.3Ki   0.0%  61.4Ki[10 Others]   │   0.0%  31.3Ki   0.0%  
61.4Ki[10 Others]
   0.0%  58.6Ki   0.0%  58.6Ki,__apple_objc │   0.0%  58.6Ki   0.0%  
58.6Ki,__apple_objc
 100.0%  3.70Gi 100.0%  3.35GiTOTAL │ 100.0%  3.69Gi 100.0%  
3.34GiTOTAL
```

Section breakdown is still similar

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread Michael Buch via lldb-commits


@@ -67,15 +67,15 @@ int C::a = 4;
 // CHECK-NOT:size:
 // CHECK-NOT:align:
 // CHECK-NOT:offset:
-// CHECK-SAME:   flags: DIFlagStaticMember,
-// CHECK-SAME:   extraData: i1 true)
+// CHECK-SAME:   flags: DIFlagStaticMember
+// CHECK-NOT:extraData:

Michael137 wrote:

Merging the two makes sense. I tried that initially but the C++98 FileCheck was 
tedious to work around. But with the latest iteration of the patch that 
shouldn't be a problem

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread David Blaikie via lldb-commits

https://github.com/dwblaikie approved this pull request.

Few minor issues, but looks good to me.
(you metnioned somewhere an lldb issue I think with this patch when the value 
is removed from the static member declaration inside the class? If that's a 
problem - probably hold off on committing this until lldb's been fixed so this 
doesn't regress things? And document the dependence clearly in the commit 
message)

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/Target] Delay image loading after corefile process creation (PR #70351)

2023-10-31 Thread Med Ismail Bennani via lldb-commits


@@ -614,6 +614,8 @@ class Process : public 
std::enable_shared_from_this,
 return error;
   }
 
+  virtual void DidLoadCore() {}

medismailben wrote:

I agree with @clayborg: attaching to a process and loading a core file are 
mutually exclusive actions so I can use re-using `DidAttach` in core file 
process plugins. However, if we rename `DidAttach` to `DidAttachOrLoadCore` 
then that would be called for non-corefile process plugins and I think that 
would be confusing to that a "LoadCore" mention in the context of the regular 
process.

@JDevlieghere if you think that using `DidAttach` in the core file process 
plugin context is confusing, I'm fine going back to my original implementation 
using `DidLoadCore`.

https://github.com/llvm/llvm-project/pull/70351
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread David Blaikie via lldb-commits


@@ -0,0 +1,87 @@
+// RUN: %clangxx -target arm64-apple-macosx11.0.0 -g %s -emit-llvm -S -o - | 
FileCheck --check-prefixes=CHECK %s
+
+enum class Enum : int {
+  VAL = -1
+};
+
+struct Empty {};
+
+constexpr auto func() { return 25; }
+
+struct Foo {
+static constexpr int cexpr_int = func();
+static constexpr int cexpr_int2 = func() + 1;
+static constexpr float cexpr_float = 2.0 + 1.0;
+static constexpr Enum cexpr_enum = Enum::VAL;
+static constexpr Empty cexpr_empty{};
+static inlineEnum inline_enum = Enum::VAL;
+
+template
+static constexpr T cexpr_template{};
+};
+
+int main() {
+Foo f;
+
+// Force global variable definitions to be emitted.
+(void)::cexpr_int;
+(void)::cexpr_empty;
+
+return Foo::cexpr_int + Foo::cexpr_float
+   + (int)Foo::cexpr_enum + Foo::cexpr_template;
+}
+
+// CHECK:  @{{.*}}cexpr_int{{.*}} =
+// CHECK-SAME:   !dbg ![[INT_GLOBAL:[0-9]+]]
+
+// CHECK:  @{{.*}}cexpr_empty{{.*}} = 
+// CHECK-SAME!dbg ![[EMPTY_GLOBAL:[0-9]+]]
+
+// CHECK:  !DIGlobalVariableExpression(var: ![[INT_VAR:[0-9]+]], expr: 
!DIExpression())

dwblaikie wrote:

Ah, that was the intent (the line 27 taking address-of)? Maybe give the 
variable a more descriptive name to make it clear this is testing the case 
where the variable has a definition emitted to the IR

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [openmp] [clang-tools-extra] [llvm] [compiler-rt] [lldb] [libcxx] [flang] [clang] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

2023-10-31 Thread Giorgis Georgakoudis via lldb-commits


@@ -141,13 +141,56 @@ struct RecordReplayTy {
 if (Err)
   report_fatal_error("Error retrieving data for target pointer");
 
-StringRef DeviceMemory(DeviceMemoryMB.get()->getBufferStart(), MemorySize);
 std::error_code EC;
 raw_fd_ostream OS(Filename, EC);
 if (EC)
   report_fatal_error("Error dumping memory to file " + Filename + " :" +
  EC.message());
-OS << DeviceMemory;
+
+if (saveDiff) {
+  // Get the pre-record memory filename
+  SmallString<128> InputFilename = {Filename.split('.').first, ".memory"};
+  // read the pre-record memorydump
+  auto InputFileBuffer = MemoryBuffer::getFileOrSTDIN(InputFilename);
+  if (std::error_code EC = InputFileBuffer.getError())
+report_fatal_error("Error reading pre-record device memory");
+
+  StringRef InputBufferContents = (*InputFileBuffer)->getBuffer();
+  if (InputBufferContents.size() != MemorySize)
+report_fatal_error("Error: Pre-record device memory size mismatch");
+
+  // get current memory contents
+  StringRef DeviceMemoryContents(DeviceMemoryMB.get()->getBuffer().data(),
+ DeviceMemoryMB.get()->getBuffer().size());
+
+  // compare pre-record memorydump to current contents
+  size_t i = 0;
+  while (i < MemorySize) {
+// if mismatch found, create a new diff line
+// current format - location, size, differences ...
+if (InputBufferContents[i] != DeviceMemoryContents[i]) {
+  OS << i << " "; // marks the start offset
+  SmallVector modified;
+  modified.push_back(DeviceMemoryContents[i]);
+  size_t j = 1;
+  // loop until next match is found
+  while (InputBufferContents[i + j] != DeviceMemoryContents[i + j]) {
+modified.push_back(DeviceMemoryContents[i + j]);
+j++;
+  }
+  OS << j << " "; // marks the length of the mismatching sequence
+  for (const auto  : modified)
+OS << value << " ";
+  OS << "\n";
+  i += j + 1;
+} else
+  i++;
+  }
+} else {
+  StringRef DeviceMemory(DeviceMemoryMB.get()->getBufferStart(),
+ MemorySize);
+  OS << DeviceMemory;
+}

ggeorgakoudis wrote:

Simplify control flow for readability:
```
for(size_t I = 0; I < MemorySize; ++I) {
  If (InputBufferContest[I] == DeviceMemoryContest[I]
continue;
   ...
   // do stuff, simplify too
   ...
   I += J;
 }
```

https://github.com/llvm/llvm-project/pull/70667
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [llvm] [openmp] [clang] [libcxx] [flang] [compiler-rt] [clang-tools-extra] [lldb] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

2023-10-31 Thread Giorgis Georgakoudis via lldb-commits


@@ -274,7 +317,7 @@ struct RecordReplayTy {
   void saveKernelOutputInfo(const char *Name) {
 SmallString<128> OutputFilename = {
 Name, (isRecording() ? ".original.output" : ".replay.output")};

ggeorgakoudis wrote:

Create a new extensions when outputting in the diff format, e.g., 
`.replay.diff.output` to avoid mixing up verification from the 
`llvm-omp-kernel-replay` tool

https://github.com/llvm/llvm-project/pull/70667
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [llvm] [compiler-rt] [clang] [openmp] [lldb] [libcxx] [flang] [clang-tools-extra] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

2023-10-31 Thread Giorgis Georgakoudis via lldb-commits


@@ -141,13 +141,56 @@ struct RecordReplayTy {
 if (Err)
   report_fatal_error("Error retrieving data for target pointer");
 
-StringRef DeviceMemory(DeviceMemoryMB.get()->getBufferStart(), MemorySize);
 std::error_code EC;
 raw_fd_ostream OS(Filename, EC);
 if (EC)
   report_fatal_error("Error dumping memory to file " + Filename + " :" +
  EC.message());
-OS << DeviceMemory;
+
+if (saveDiff) {
+  // Get the pre-record memory filename
+  SmallString<128> InputFilename = {Filename.split('.').first, ".memory"};
+  // read the pre-record memorydump
+  auto InputFileBuffer = MemoryBuffer::getFileOrSTDIN(InputFilename);
+  if (std::error_code EC = InputFileBuffer.getError())
+report_fatal_error("Error reading pre-record device memory");
+
+  StringRef InputBufferContents = (*InputFileBuffer)->getBuffer();
+  if (InputBufferContents.size() != MemorySize)
+report_fatal_error("Error: Pre-record device memory size mismatch");
+
+  // get current memory contents
+  StringRef DeviceMemoryContents(DeviceMemoryMB.get()->getBuffer().data(),
+ DeviceMemoryMB.get()->getBuffer().size());
+
+  // compare pre-record memorydump to current contents
+  size_t i = 0;

ggeorgakoudis wrote:

rename i -> I

https://github.com/llvm/llvm-project/pull/70667
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [clang] [flang] [llvm] [openmp] [compiler-rt] [clang-tools-extra] [libcxx] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

2023-10-31 Thread Giorgis Georgakoudis via lldb-commits

https://github.com/ggeorgakoudis edited 
https://github.com/llvm/llvm-project/pull/70667
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang-tools-extra] [clang] [openmp] [llvm] [compiler-rt] [flang] [lldb] [libcxx] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

2023-10-31 Thread Giorgis Georgakoudis via lldb-commits


@@ -130,7 +130,7 @@ struct RecordReplayTy {
 return preAllocateHeuristic(DevMemSize, ReqVAddr);
   }
 
-  void dumpDeviceMemory(StringRef Filename) {
+  void dumpDeviceMemory(StringRef Filename, bool saveDiff) {

ggeorgakoudis wrote:

rename saveDiff -> SaveDiff

https://github.com/llvm/llvm-project/pull/70667
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [llvm] [openmp] [compiler-rt] [clang-tools-extra] [libcxx] [flang] [clang] [lldb] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

2023-10-31 Thread Giorgis Georgakoudis via lldb-commits


@@ -141,13 +141,56 @@ struct RecordReplayTy {
 if (Err)
   report_fatal_error("Error retrieving data for target pointer");
 
-StringRef DeviceMemory(DeviceMemoryMB.get()->getBufferStart(), MemorySize);
 std::error_code EC;
 raw_fd_ostream OS(Filename, EC);
 if (EC)
   report_fatal_error("Error dumping memory to file " + Filename + " :" +
  EC.message());
-OS << DeviceMemory;
+
+if (saveDiff) {
+  // Get the pre-record memory filename
+  SmallString<128> InputFilename = {Filename.split('.').first, ".memory"};
+  // read the pre-record memorydump
+  auto InputFileBuffer = MemoryBuffer::getFileOrSTDIN(InputFilename);
+  if (std::error_code EC = InputFileBuffer.getError())
+report_fatal_error("Error reading pre-record device memory");
+
+  StringRef InputBufferContents = (*InputFileBuffer)->getBuffer();
+  if (InputBufferContents.size() != MemorySize)
+report_fatal_error("Error: Pre-record device memory size mismatch");
+
+  // get current memory contents
+  StringRef DeviceMemoryContents(DeviceMemoryMB.get()->getBuffer().data(),
+ DeviceMemoryMB.get()->getBuffer().size());
+
+  // compare pre-record memorydump to current contents
+  size_t i = 0;
+  while (i < MemorySize) {
+// if mismatch found, create a new diff line
+// current format - location, size, differences ...
+if (InputBufferContents[i] != DeviceMemoryContents[i]) {
+  OS << i << " "; // marks the start offset
+  SmallVector modified;

ggeorgakoudis wrote:

rename modified -> Modified

https://github.com/llvm/llvm-project/pull/70667
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang-tools-extra] [libcxx] [llvm] [lldb] [compiler-rt] [openmp] [flang] [clang] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

2023-10-31 Thread Giorgis Georgakoudis via lldb-commits


@@ -141,13 +141,56 @@ struct RecordReplayTy {
 if (Err)
   report_fatal_error("Error retrieving data for target pointer");
 
-StringRef DeviceMemory(DeviceMemoryMB.get()->getBufferStart(), MemorySize);
 std::error_code EC;
 raw_fd_ostream OS(Filename, EC);
 if (EC)
   report_fatal_error("Error dumping memory to file " + Filename + " :" +
  EC.message());
-OS << DeviceMemory;
+
+if (saveDiff) {
+  // Get the pre-record memory filename
+  SmallString<128> InputFilename = {Filename.split('.').first, ".memory"};
+  // read the pre-record memorydump
+  auto InputFileBuffer = MemoryBuffer::getFileOrSTDIN(InputFilename);
+  if (std::error_code EC = InputFileBuffer.getError())
+report_fatal_error("Error reading pre-record device memory");
+
+  StringRef InputBufferContents = (*InputFileBuffer)->getBuffer();
+  if (InputBufferContents.size() != MemorySize)
+report_fatal_error("Error: Pre-record device memory size mismatch");
+
+  // get current memory contents
+  StringRef DeviceMemoryContents(DeviceMemoryMB.get()->getBuffer().data(),
+ DeviceMemoryMB.get()->getBuffer().size());
+
+  // compare pre-record memorydump to current contents
+  size_t i = 0;
+  while (i < MemorySize) {
+// if mismatch found, create a new diff line
+// current format - location, size, differences ...
+if (InputBufferContents[i] != DeviceMemoryContents[i]) {
+  OS << i << " "; // marks the start offset
+  SmallVector modified;
+  modified.push_back(DeviceMemoryContents[i]);
+  size_t j = 1;

ggeorgakoudis wrote:

rename j -> J

https://github.com/llvm/llvm-project/pull/70667
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [compiler-rt] [llvm] [libcxx] [flang] [openmp] [clang-tools-extra] [lldb] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

2023-10-31 Thread Giorgis Georgakoudis via lldb-commits

https://github.com/ggeorgakoudis requested changes to this pull request.


https://github.com/llvm/llvm-project/pull/70667
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [libcxx] [openmp] [flang] [clang] [lldb] [compiler-rt] [llvm] [clang-tools-extra] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

2023-10-31 Thread Giorgis Georgakoudis via lldb-commits


@@ -274,7 +317,7 @@ struct RecordReplayTy {
   void saveKernelOutputInfo(const char *Name) {
 SmallString<128> OutputFilename = {
 Name, (isRecording() ? ".original.output" : ".replay.output")};
-dumpDeviceMemory(OutputFilename);
+dumpDeviceMemory(OutputFilename, /*saveDiff*/ true);

ggeorgakoudis wrote:

If `saveDiff` is always `true` when replaying then this is incompatible with 
verification in the `llvm-omp-kernel-replay` tool, right? We should set 
`saveDiff` either through an env var or through the `llvm-omp-kernel-replay` 
tool (latter is better) and make the `llvm-omp-kernel-replay` tool aware. If 
`saveDiff` is true then the tool should just show the differences already saved 
in the diff files.

https://github.com/llvm/llvm-project/pull/70667
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread Greg Clayton via lldb-commits

https://github.com/clayborg commented:

One question I have here: where will the DW_TAG_variable get emitted for these 
`constexpr`? For actual static member variables we emit a single 
DW_TAG_variable in the file that declares the global variable, but for 
`constexpr` we won't be able to do this will we? Will we end up emitting a new 
copy each time someone include the header file? In that case we might end up 
with many global variables being defined in a linked executable that includes 
this header file more than once?

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/Target] Delay image loading after corefile process creation (PR #70351)

2023-10-31 Thread Greg Clayton via lldb-commits


@@ -614,6 +614,8 @@ class Process : public 
std::enable_shared_from_this,
 return error;
   }
 
+  virtual void DidLoadCore() {}

clayborg wrote:

I think it makes sense in the process plug-in landscape. We are attaching to a 
core file image from a process plug-in perspective. I would rather add a 
`DidLoadCore()` over renaming to `DidAttachOrLoadCore()` if we do need to make 
a change though.

https://github.com/llvm/llvm-project/pull/70351
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Replace the usage of module imp with module importlib (PR #70443)

2023-10-31 Thread Tulio Magno Quites Machado Filho via lldb-commits

https://github.com/tuliom closed https://github.com/llvm/llvm-project/pull/70443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 2260ebf - [lldb] Replace the usage of module imp with module importlib (#70443)

2023-10-31 Thread via lldb-commits

Author: Tulio Magno Quites Machado Filho
Date: 2023-10-31T17:08:55-03:00
New Revision: 2260ebf7b6df15db96c76039758dd9dbf009c334

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

LOG: [lldb] Replace the usage of module imp with module importlib (#70443)

imp got removed in Python 3.12 [1] and the community recommends using
importlib in newer Python versions.

[1] https://docs.python.org/3.12/whatsnew/3.12.html#imp

Added: 


Modified: 
lldb/scripts/use_lldb_suite.py
lldb/test/API/use_lldb_suite.py

Removed: 




diff  --git a/lldb/scripts/use_lldb_suite.py b/lldb/scripts/use_lldb_suite.py
index 6388d87b181ce03..a050db0e79e6807 100644
--- a/lldb/scripts/use_lldb_suite.py
+++ b/lldb/scripts/use_lldb_suite.py
@@ -17,11 +17,12 @@ def find_lldb_root():
 
 
 lldb_root = find_lldb_root()
-import imp
 
-fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
-try:
-imp.load_module("use_lldb_suite_root", fp, pathname, desc)
-finally:
-if fp:
-fp.close()
+import importlib.machinery
+import importlib.util
+
+path = os.path.join(lldb_root, "use_lldb_suite_root.py")
+loader = importlib.machinery.SourceFileLoader("use_lldb_suite_root", path)
+spec = importlib.util.spec_from_loader("use_lldb_suite_root", loader=loader)
+module = importlib.util.module_from_spec(spec)
+loader.exec_module(module)

diff  --git a/lldb/test/API/use_lldb_suite.py b/lldb/test/API/use_lldb_suite.py
index e237dd4b8a5607c..a680f8c466a34f0 100644
--- a/lldb/test/API/use_lldb_suite.py
+++ b/lldb/test/API/use_lldb_suite.py
@@ -20,11 +20,11 @@ def find_lldb_root():
 
 lldb_root = find_lldb_root()
 
-import imp
+import importlib.machinery
+import importlib.util
 
-fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
-try:
-imp.load_module("use_lldb_suite_root", fp, pathname, desc)
-finally:
-if fp:
-fp.close()
+path = os.path.join(lldb_root, "use_lldb_suite_root.py")
+loader = importlib.machinery.SourceFileLoader("use_lldb_suite_root", path)
+spec = importlib.util.spec_from_loader("use_lldb_suite_root", loader=loader)
+module = importlib.util.module_from_spec(spec)
+loader.exec_module(module)



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


[Lldb-commits] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

2023-10-31 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben requested changes to this pull request.


https://github.com/llvm/llvm-project/pull/70793
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

2023-10-31 Thread Med Ismail Bennani via lldb-commits


@@ -791,11 +791,10 @@ void ObjectFilePECOFF::AppendFromCOFFSymbolTable(
   for (const auto _ref : m_binary->symbols()) {
 const auto coff_sym_ref = m_binary->getCOFFSymbol(sym_ref);
 auto name_or_error = sym_ref.getName();
-if (auto err = name_or_error.takeError()) {
-  LLDB_LOG(log,
-   "ObjectFilePECOFF::AppendFromCOFFSymbolTable - failed to get "
-   "symbol table entry name: {0}",
-   llvm::fmt_consume(std::move(err)));
+if (!name_or_error) {
+  LLDB_LOG_ERROR(log, name_or_error.takeError(),
+ "ObjectFilePECOFF::AppendFromCOFFSymbolTable - failed to "

medismailben wrote:

Same here

https://github.com/llvm/llvm-project/pull/70793
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

2023-10-31 Thread Med Ismail Bennani via lldb-commits


@@ -271,9 +271,9 @@ void ObjectFileCOFF::ParseSymtab(lldb_private::Symtab 
) {
 const auto COFFSymRef = m_object->getCOFFSymbol(SymRef);
 
 Expected NameOrErr = SymRef.getName();
-if (auto error = NameOrErr.takeError()) {
-  LLDB_LOG(log, "ObjectFileCOFF: failed to get symbol name: {0}",
-   llvm::fmt_consume(std::move(error)));
+if (!NameOrErr) {
+  LLDB_LOG_ERROR(log, NameOrErr.takeError(),
+ "ObjectFileCOFF: failed to get symbol name: {0}");

medismailben wrote:

I don't think you need to specify `ObjectFileCOFF:` anymore since 
`LLDB_LOG_ERROR` will take care of adding the file name and the function symbol 
for you.

https://github.com/llvm/llvm-project/pull/70793
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

2023-10-31 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben edited 
https://github.com/llvm/llvm-project/pull/70793
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Replace the usage of module imp with module importlib (PR #70443)

2023-10-31 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere approved this pull request.


https://github.com/llvm/llvm-project/pull/70443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/Target] Delay image loading after corefile process creation (PR #70351)

2023-10-31 Thread Jonas Devlieghere via lldb-commits


@@ -614,6 +614,8 @@ class Process : public 
std::enable_shared_from_this,
 return error;
   }
 
+  virtual void DidLoadCore() {}

JDevlieghere wrote:

Would it be worth to rename that function to `DidAttachOrLoadCore` (or just 
`DidAttachOrLoad`) to make it obvious that it handles both cases? I'm all for 
reusing `DidAttach` but it does seem a bit weird for a core file process.

https://github.com/llvm/llvm-project/pull/70351
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

2023-10-31 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere approved this pull request.

Thanks Stefan!

https://github.com/llvm/llvm-project/pull/70793
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread David Blaikie via lldb-commits


@@ -5883,6 +5907,18 @@ void CGDebugInfo::finalize() {
 DBuilder.replaceTemporary(std::move(FwdDecl), cast(Repl));
   }
 
+  for (auto const *VD : StaticDataMemberDefinitionsToEmit) {
+assert(VD->isStaticDataMember());
+
+if (auto It = DeclCache.find(VD); It != DeclCache.end())

dwblaikie wrote:

DeclCache.contains might be simpler to use/read here?

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread David Blaikie via lldb-commits


@@ -67,15 +67,15 @@ int C::a = 4;
 // CHECK-NOT:size:
 // CHECK-NOT:align:
 // CHECK-NOT:offset:
-// CHECK-SAME:   flags: DIFlagStaticMember,
-// CHECK-SAME:   extraData: i1 true)
+// CHECK-SAME:   flags: DIFlagStaticMember
+// CHECK-NOT:extraData:

dwblaikie wrote:

Perhaps this test case could be extended to check the constatn values on the 
definition metadata? & /maybe/ we don't need a new test case? (or maybe we do, 
but perhaps they could be added to this file, rather than another one?)

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][AArch64] Add SME2's ZT0 register (PR #70205)

2023-10-31 Thread Alex Langford via lldb-commits

bulbazord wrote:

Looks fine to me, though I'm not an expert in this area. If nobody else reviews 
or approves soon, I can do so.

https://github.com/llvm/llvm-project/pull/70205
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Replace the usage of module imp with module importlib (PR #70443)

2023-10-31 Thread Alex Langford via lldb-commits

https://github.com/bulbazord approved this pull request.

Thanks for taking the time to make sure it works with Python 3.6! I'm a big fan 
of this kind of modernization/cleanup work.  

https://github.com/llvm/llvm-project/pull/70443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Replace the usage of module imp with module importlib (PR #70443)

2023-10-31 Thread Tulio Magno Quites Machado Filho via lldb-commits

tuliom wrote:

I confirmed the new code works with Python 3.6 and removed the conditional.

https://github.com/llvm/llvm-project/pull/70443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Replace the usage of module imp with module importlib (PR #70443)

2023-10-31 Thread Tulio Magno Quites Machado Filho via lldb-commits

https://github.com/tuliom updated 
https://github.com/llvm/llvm-project/pull/70443

>From 16fd09f102eff20825847e32f225715960d1c082 Mon Sep 17 00:00:00 2001
From: Tulio Magno Quites Machado Filho 
Date: Wed, 25 Oct 2023 10:48:53 -0300
Subject: [PATCH 1/2] [lldb] Replace the usage of module imp with module
 importlib

imp got removed in Python 3.12 [1] and the community recommends using
importlib in newer Python versions.

[1] https://docs.python.org/3.12/whatsnew/3.12.html#imp
---
 lldb/scripts/use_lldb_suite.py  | 30 ++
 lldb/test/API/use_lldb_suite.py | 29 +
 2 files changed, 43 insertions(+), 16 deletions(-)

diff --git a/lldb/scripts/use_lldb_suite.py b/lldb/scripts/use_lldb_suite.py
index 6388d87b181ce03..4cedfa532cf972d 100644
--- a/lldb/scripts/use_lldb_suite.py
+++ b/lldb/scripts/use_lldb_suite.py
@@ -17,11 +17,25 @@ def find_lldb_root():
 
 
 lldb_root = find_lldb_root()
-import imp
-
-fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
-try:
-imp.load_module("use_lldb_suite_root", fp, pathname, desc)
-finally:
-if fp:
-fp.close()
+
+# Module imp got removed in Python 3.12.
+if (
+sys.version_info.major == 3 and sys.version_info.minor >= 12
+) or sys.version_info.major > 3:
+import importlib.machinery
+import importlib.util
+
+path = os.path.join(lldb_root, "use_lldb_suite_root.py")
+loader = importlib.machinery.SourceFileLoader("use_lldb_suite_root", path)
+spec = importlib.util.spec_from_loader("use_lldb_suite_root", 
loader=loader)
+module = importlib.util.module_from_spec(spec)
+loader.exec_module(module)
+else:
+import imp
+
+fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
+try:
+imp.load_module("use_lldb_suite_root", fp, pathname, desc)
+finally:
+if fp:
+fp.close()
diff --git a/lldb/test/API/use_lldb_suite.py b/lldb/test/API/use_lldb_suite.py
index e237dd4b8a5607c..c9332d9921b4eb3 100644
--- a/lldb/test/API/use_lldb_suite.py
+++ b/lldb/test/API/use_lldb_suite.py
@@ -20,11 +20,24 @@ def find_lldb_root():
 
 lldb_root = find_lldb_root()
 
-import imp
-
-fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
-try:
-imp.load_module("use_lldb_suite_root", fp, pathname, desc)
-finally:
-if fp:
-fp.close()
+# Module imp got removed in Python 3.12.
+if (
+sys.version_info.major == 3 and sys.version_info.minor >= 12
+) or sys.version_info.major > 3:
+import importlib.machinery
+import importlib.util
+
+path = os.path.join(lldb_root, "use_lldb_suite_root.py")
+loader = importlib.machinery.SourceFileLoader("use_lldb_suite_root", path)
+spec = importlib.util.spec_from_loader("use_lldb_suite_root", 
loader=loader)
+module = importlib.util.module_from_spec(spec)
+loader.exec_module(module)
+else:
+import imp
+
+fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
+try:
+imp.load_module("use_lldb_suite_root", fp, pathname, desc)
+finally:
+if fp:
+fp.close()

>From be8d5a305de8241d51fcca1189a3d56d9cfa9243 Mon Sep 17 00:00:00 2001
From: Tulio Magno Quites Machado Filho 
Date: Tue, 31 Oct 2023 15:05:24 -0300
Subject: [PATCH 2/2] fixup! [lldb] Replace the usage of module imp with module
 importlib

---
 lldb/scripts/use_lldb_suite.py  | 29 -
 lldb/test/API/use_lldb_suite.py | 29 -
 2 files changed, 16 insertions(+), 42 deletions(-)

diff --git a/lldb/scripts/use_lldb_suite.py b/lldb/scripts/use_lldb_suite.py
index 4cedfa532cf972d..a050db0e79e6807 100644
--- a/lldb/scripts/use_lldb_suite.py
+++ b/lldb/scripts/use_lldb_suite.py
@@ -18,24 +18,11 @@ def find_lldb_root():
 
 lldb_root = find_lldb_root()
 
-# Module imp got removed in Python 3.12.
-if (
-sys.version_info.major == 3 and sys.version_info.minor >= 12
-) or sys.version_info.major > 3:
-import importlib.machinery
-import importlib.util
-
-path = os.path.join(lldb_root, "use_lldb_suite_root.py")
-loader = importlib.machinery.SourceFileLoader("use_lldb_suite_root", path)
-spec = importlib.util.spec_from_loader("use_lldb_suite_root", 
loader=loader)
-module = importlib.util.module_from_spec(spec)
-loader.exec_module(module)
-else:
-import imp
-
-fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
-try:
-imp.load_module("use_lldb_suite_root", fp, pathname, desc)
-finally:
-if fp:
-fp.close()
+import importlib.machinery
+import importlib.util
+
+path = os.path.join(lldb_root, "use_lldb_suite_root.py")
+loader = importlib.machinery.SourceFileLoader("use_lldb_suite_root", path)
+spec = importlib.util.spec_from_loader("use_lldb_suite_root", loader=loader)
+module = importlib.util.module_from_spec(spec)
+loader.exec_module(module)
diff --git a/lldb/test/API/use_lldb_suite.py 

[Lldb-commits] [lldb] Add the ability to get a C++ vtable ValueObject from another ValueObj… (PR #67599)

2023-10-31 Thread Greg Clayton via lldb-commits

clayborg wrote:

Phew! Still getting. used to this new workflow. Thanks for the confirmation

https://github.com/llvm/llvm-project/pull/67599
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add the ability to get a C++ vtable ValueObject from another ValueObj… (PR #67599)

2023-10-31 Thread Alex Langford via lldb-commits

bulbazord wrote:

The change was not reverted upstream. It was reverted in that @DanielCChen 's 
llvm-project fork. Unfortunately that's the nature of GitHub.



https://github.com/llvm/llvm-project/pull/67599
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add the ability to get a C++ vtable ValueObject from another ValueObj… (PR #67599)

2023-10-31 Thread via lldb-commits

jimingham wrote:

I hope that's not the case...  It would be really noisy to see what goes on on 
people's private forks in a PR on the main repo.  

Jim

> On Oct 31, 2023, at 10:42 AM, Greg Clayton ***@***.***> wrote:
> 
> 
> Maybe this was only reverted in his branch?
> 
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because your review was requested.
> 



https://github.com/llvm/llvm-project/pull/67599
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add the ability to get a C++ vtable ValueObject from another ValueObj… (PR #67599)

2023-10-31 Thread Greg Clayton via lldb-commits

clayborg wrote:

Maybe this was only reverted in his branch?

https://github.com/llvm/llvm-project/pull/67599
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add the ability to get a C++ vtable ValueObject from another ValueObj… (PR #67599)

2023-10-31 Thread Greg Clayton via lldb-commits

clayborg wrote:

> You should never revert a commit without saying why in your revert-commit 
> message.

I just synced with top of tree and it seems to still be there??

https://github.com/llvm/llvm-project/pull/67599
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add the ability to get a C++ vtable ValueObject from another ValueObj… (PR #67599)

2023-10-31 Thread via lldb-commits

jimingham wrote:

You should never revert a commit without saying why in your revert-commit 
message.

https://github.com/llvm/llvm-project/pull/67599
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add the ability to get a C++ vtable ValueObject from another ValueObj… (PR #67599)

2023-10-31 Thread Greg Clayton via lldb-commits

clayborg wrote:

@DanielCChen see above

https://github.com/llvm/llvm-project/pull/67599
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add the ability to get a C++ vtable ValueObject from another ValueObj… (PR #67599)

2023-10-31 Thread Greg Clayton via lldb-commits

clayborg wrote:

How do we find out why something was reverted? I didn't get any emails and this 
got reverted. Is there a new workflow to find out this info when using github?

https://github.com/llvm/llvm-project/pull/67599
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

2023-10-31 Thread Alex Langford via lldb-commits

https://github.com/bulbazord approved this pull request.


https://github.com/llvm/llvm-project/pull/70793
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread David Blaikie via lldb-commits

dwblaikie wrote:

size report sounds generally OK - but there's a bunch of what look like 
unrelated or strange results in there, perhaps they weren't compared at exactly 
the same version? (like why did the apple_names size go down? How did the .text 
and .debuG_line size change at all? )

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] d402645 - [LLDB] On AArch64, reconfigure register context first (#70742)

2023-10-31 Thread via lldb-commits

Author: Jason Molenda
Date: 2023-10-31T15:38:42Z
New Revision: d4026458d4ced8471cc0fcbf3a1a4cd1944ebea9

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

LOG: [LLDB] On AArch64, reconfigure register context first (#70742)

On an SVE/SME the register context configuration may change after the
inferior process has executed. This was handled via
https://reviews.llvm.org/D159504 but it is reconfiguring and clearing
the register context after we've parsed any expedited reigster values
from the stop reply packet. That results in lldb having to read each
register value one at a time while at that stop location, which will be
a performance problem on non-local debug setups.

The configuration & clearing needs to happen first. Also, update the
names of the local variables for a little clarity.

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 dad1396698050d4..16b3ba661d07162 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -1642,9 +1642,22 @@ ThreadSP ProcessGDBRemote::SetThreadStopInfo(
   }
 
   ThreadGDBRemote *gdb_thread = static_cast(thread_sp.get());
-  RegisterContextSP gdb_reg_ctx_sp(gdb_thread->GetRegisterContext());
+  RegisterContextSP reg_ctx_sp(gdb_thread->GetRegisterContext());
 
-  gdb_reg_ctx_sp->InvalidateIfNeeded(true);
+  reg_ctx_sp->InvalidateIfNeeded(true);
+
+  // AArch64 SVE/SME specific code below updates SVE and ZA register sizes and
+  // offsets if value of VG or SVG registers has changed since last stop.
+  const ArchSpec  = GetTarget().GetArchitecture();
+  if (arch.IsValid() && arch.GetTriple().isAArch64()) {
+GDBRemoteRegisterContext *gdb_remote_reg_ctx =
+static_cast(reg_ctx_sp.get());
+
+if (gdb_remote_reg_ctx) {
+  gdb_remote_reg_ctx->AArch64Reconfigure();
+  gdb_remote_reg_ctx->InvalidateAllRegisters();
+}
+  }
 
   auto iter = std::find(m_thread_ids.begin(), m_thread_ids.end(), tid);
   if (iter != m_thread_ids.end())
@@ -1655,25 +1668,10 @@ ThreadSP ProcessGDBRemote::SetThreadStopInfo(
 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(
+uint32_t lldb_regnum = reg_ctx_sp->ConvertRegisterKindToRegisterNumber(
 eRegisterKindProcessPlugin, pair.first);
 gdb_thread->PrivateSetRegisterValue(lldb_regnum, buffer_sp->GetData());
   }
-
-  // AArch64 SVE/SME specific code below updates SVE and ZA register sizes and
-  // offsets if value of VG or SVG registers has changed since last stop.
-  const ArchSpec  = 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->AArch64Reconfigure();
-  reg_ctx_sp->InvalidateAllRegisters();
-}
-  }
-
   thread_sp->SetName(thread_name.empty() ? nullptr : thread_name.c_str());
 
   gdb_thread->SetThreadDispatchQAddr(thread_dispatch_qaddr);



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


[Lldb-commits] [lldb] [LLDB] On AArch64, reconfigure register context first (PR #70742)

2023-10-31 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett closed 
https://github.com/llvm/llvm-project/pull/70742
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] On AArch64, reconfigure register context first (PR #70742)

2023-10-31 Thread David Spickett via lldb-commits

DavidSpickett wrote:

I'm gonna merge this so I can do a patch on top of this where we both 
understand the starting point. I think I've got to the bottom of the issues my 
workarounds were addressing.

https://github.com/llvm/llvm-project/pull/70742
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] On AArch64, reconfigure register context first (PR #70742)

2023-10-31 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

>  Or fishing the vg and svg register values of of the expedited register list 
> if they're there.

ignore that suggestion, we can't hardcode a register number here, the stub is 
allowed to use whatever numbers it wants for the registers and the expedited 
register numbers are all in the stub's numbering ordering at this point.  I 
think your parse-reconfigure-parse plan is good.

https://github.com/llvm/llvm-project/pull/70742
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] On AArch64, reconfigure register context first (PR #70742)

2023-10-31 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

> So, as silly as it sounds this might be the way to go:
> 
> * Parse expedited registers.
> * Reconfigure if needed and invalidate all registers.
> * Parse expedited registers again.

I'm fine with that, it doesn't require packets over the wire so the perf hit is 
tiny.  Or fishing the vg and svg register values of of the expedited register 
list if they're there.  I'm fine with abandoning this PR if you'd like to write 
that patch, it's not pressing that this be fixed immediately.  Thanks!

https://github.com/llvm/llvm-project/pull/70742
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] f5f4c5b - [clang][NFC] Follow up to ArraySizeModifier refactoring

2023-10-31 Thread Vlad Serebrennikov via lldb-commits

Author: Vlad Serebrennikov
Date: 2023-10-31T18:21:36+03:00
New Revision: f5f4c5b313fc809b9b1b9d600d0ec3cec0d12941

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

LOG: [clang][NFC] Follow up to ArraySizeModifier refactoring

This addresses issues found by 
https://lab.llvm.org/buildbot/#/builders/68/builds/62599 introduced in 
d71ac4b05bcf2804368ec7217a13c2c47fce7479

Added: 


Modified: 
clang-tools-extra/clangd/Hover.cpp
libcxxabi/test/test_demangle.pass.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/Hover.cpp 
b/clang-tools-extra/clangd/Hover.cpp
index 933c69294b40926..7f7b5513dff6fee 100644
--- a/clang-tools-extra/clangd/Hover.cpp
+++ b/clang-tools-extra/clangd/Hover.cpp
@@ -686,9 +686,9 @@ getPredefinedExprHoverContents(const PredefinedExpr , 
ASTContext ,
 HI.Type = printType(Name->getType(), Ctx, PP);
   } else {
 // Inside templates, the approximate type `const char[]` is still useful.
-QualType StringType = Ctx.getIncompleteArrayType(
-Ctx.CharTy.withConst(), ArrayType::ArraySizeModifier::Normal,
-/*IndexTypeQuals=*/0);
+QualType StringType = Ctx.getIncompleteArrayType(Ctx.CharTy.withConst(),
+ ArraySizeModifier::Normal,
+ /*IndexTypeQuals=*/0);
 HI.Type = printType(StringType, Ctx, PP);
   }
   return HI;

diff  --git a/libcxxabi/test/test_demangle.pass.cpp 
b/libcxxabi/test/test_demangle.pass.cpp
index 77741a952850ab9..3bfdc04ced50b36 100644
--- a/libcxxabi/test/test_demangle.pass.cpp
+++ b/libcxxabi/test/test_demangle.pass.cpp
@@ -5989,7 +5989,7 @@ const char* cases[][2] =
 
{"_ZN5clang13TreeTransformIN12_GLOBAL__N_129CurrentInstantiationRebuilderEE13TransformTypeERNS_14TypeLocBuilderENS_7TypeLocE",
 "clang::TreeTransform<(anonymous 
namespace)::CurrentInstantiationRebuilder>::TransformType(clang::TypeLocBuilder&,
 clang::TypeLoc)"},
 
{"_ZN5clang13TreeTransformIN12_GLOBAL__N_129CurrentInstantiationRebuilderEE27TransformFunctionTypeParamsENS_14SourceLocationEPPNS_11ParmVarDeclEjPKNS_8QualTypeERN4llvm15SmallVectorImplIS8_EEPNSC_IS6_EE",
 "clang::TreeTransform<(anonymous 
namespace)::CurrentInstantiationRebuilder>::TransformFunctionTypeParams(clang::SourceLocation,
 clang::ParmVarDecl**, unsigned int, clang::QualType const*, 
llvm::SmallVectorImpl&, 
llvm::SmallVectorImpl*)"},
 
{"_ZN5clang13TreeTransformIN12_GLOBAL__N_129CurrentInstantiationRebuilderEE26TransformFunctionTypeParamEPNS_11ParmVarDeclEN4llvm8OptionalIjEE",
 "clang::TreeTransform<(anonymous 
namespace)::CurrentInstantiationRebuilder>::TransformFunctionTypeParam(clang::ParmVarDecl*,
 llvm::Optional)"},
-
{"_ZN5clang13TreeTransformIN12_GLOBAL__N_129CurrentInstantiationRebuilderEE16RebuildArrayTypeENS_8QualTypeENS_9ArrayType17ArraySizeModifierEPKN4llvm5APIntEPNS_4ExprEjNS_11SourceRangeE",
 "clang::TreeTransform<(anonymous 
namespace)::CurrentInstantiationRebuilder>::RebuildArrayType(clang::QualType, 
clang::ArrayType::ArraySizeModifier, llvm::APInt const*, clang::Expr*, unsigned 
int, clang::SourceRange)"},
+
{"_ZN5clang13TreeTransformIN12_GLOBAL__N_129CurrentInstantiationRebuilderEE16RebuildArrayTypeENS_8QualTypeENS_9ArrayType17ArraySizeModifierEPKN4llvm5APIntEPNS_4ExprEjNS_11SourceRangeE",
 "clang::TreeTransform<(anonymous 
namespace)::CurrentInstantiationRebuilder>::RebuildArrayType(clang::QualType, 
clang::ArraySizeModifier, llvm::APInt const*, clang::Expr*, unsigned int, 
clang::SourceRange)"},
 
{"_ZN5clang13TreeTransformIN12_GLOBAL__N_129CurrentInstantiationRebuilderEE22TransformReferenceTypeERNS_14TypeLocBuilderENS_16ReferenceTypeLocE",
 "clang::TreeTransform<(anonymous 
namespace)::CurrentInstantiationRebuilder>::TransformReferenceType(clang::TypeLocBuilder&,
 clang::ReferenceTypeLoc)"},
 
{"_ZN5clang13TreeTransformIN12_GLOBAL__N_129CurrentInstantiationRebuilderEE26TransformTemplateArgumentsINS_33TemplateArgumentLocInventIteratorIS2_PKNS_16TemplateArgumentEbT_SA_RNS_24TemplateArgumentListInfoE",
 "bool clang::TreeTransform<(anonymous 
namespace)::CurrentInstantiationRebuilder>::TransformTemplateArguments>(clang::TemplateArgumentLocInventIterator<(anonymous 
namespace)::CurrentInstantiationRebuilder, clang::TemplateArgument const*>, 
clang::TemplateArgumentLocInventIterator<(anonymous 
namespace)::CurrentInstantiationRebuilder, clang::TemplateArgument const*>, 
clang::TemplateArgumentListInfo&)"},
 
{"_ZN5clang13TreeTransformIN12_GLOBAL__N_129CurrentInstantiationRebuilderEE25TransformTemplateArgumentERKNS_19TemplateArgumentLocERS4_",
 "clang::TreeTransform<(anonymous 

[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

2023-10-31 Thread Michael Buch via lldb-commits

https://github.com/Michael137 updated 
https://github.com/llvm/llvm-project/pull/70639

>From 18db082fc5008283f77cc98d9c733a47c63b7096 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Fri, 27 Oct 2023 16:19:47 +0100
Subject: [PATCH 1/4] [clang][DebugInfo] Emit global variable definitions for
 static data members with constant initializers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When an LLDB user asks for the value of a static data member, LLDB starts by
searching the Names accelerator table for the corresponding variable definition
DIE. For static data members with out-of-class definitions that works fine,
because those get represented as global variables with a location and making 
them
eligible to be added to the Names table. However, in-class definitions won’t get
indexed because we usually don't emit global variables for them. So in DWARF
we end up with a single `DW_TAG_member` that usually holds the constant 
initializer.
But we don't get a corresponding CU-level `DW_TAG_variable` like we do for
out-of-class definitions.

To make it more convenient for debuggers to get to the value of inline static 
data members,
this patch makes sure we emit definitions for static variables with constant 
initializers
the same way we do for other static variables. This also aligns Clang closer to 
GCC, which
produces CU-level definitions for inline statics and also emits these into 
`.debug_pubnames`.

The implementation keeps track of newly created static data members. Then in
`CGDebugInfo::finalize`, we emit a global `DW_TAG_variable` with a 
`DW_AT_const_value` for
any of those declarations that didn't end up with a definition in the 
`DeclCache`.

The newly emitted `DW_TAG_variable` will look as follows:
```
0x007b:   DW_TAG_structure_type
DW_AT_calling_convention(DW_CC_pass_by_value)
DW_AT_name  ("Foo")
...

0x008d: DW_TAG_member
  DW_AT_name("i")
  DW_AT_type(0x0062 "const int")
  DW_AT_external(true)
  DW_AT_declaration (true)
  DW_AT_const_value (4)

Newly added
v

0x009a:   DW_TAG_variable
DW_AT_specification (0x008d "i")
DW_AT_const_value   (4)
DW_AT_linkage_name  ("_ZN2t2IiE1iIfEE")
```
---
 clang/lib/CodeGen/CGDebugInfo.cpp | 46 +++
 clang/lib/CodeGen/CGDebugInfo.h   |  6 ++
 clang/test/CodeGenCXX/debug-info-class.cpp| 13 ++-
 .../debug-info-static-inline-member.cpp   | 79 +++
 .../TestConstStaticIntegralMember.py  |  7 +-
 5 files changed, 144 insertions(+), 7 deletions(-)
 create mode 100644 clang/test/CodeGenCXX/debug-info-static-inline-member.cpp

diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 0aaf678bf287c6e..7529f114996d2ec 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -1693,6 +1693,7 @@ CGDebugInfo::CreateRecordStaticField(const VarDecl *Var, 
llvm::DIType *RecordTy,
   llvm::DIDerivedType *GV = DBuilder.createStaticMemberType(
   RecordTy, VName, VUnit, LineNumber, VTy, Flags, C, Align);
   StaticDataMemberCache[Var->getCanonicalDecl()].reset(GV);
+  StaticDataMemberDefinitionsToEmit.push_back(Var->getCanonicalDecl());
   return GV;
 }
 
@@ -5613,6 +5614,39 @@ void CGDebugInfo::EmitGlobalVariable(const ValueDecl 
*VD, const APValue ) {
   TemplateParameters, Align));
 }
 
+void CGDebugInfo::EmitGlobalVariable(const VarDecl *VD) {
+  assert(VD->hasInit());
+  assert(CGM.getCodeGenOpts().hasReducedDebugInfo());
+  if (VD->hasAttr())
+return;
+
+  auto  = DeclCache[VD];
+  if (GV)
+return;
+
+  auto const *InitVal = VD->evaluateValue();
+  if (!InitVal)
+return;
+
+  llvm::DIFile *Unit = nullptr;
+  llvm::DIScope *DContext = nullptr;
+  unsigned LineNo;
+  StringRef DeclName, LinkageName;
+  QualType T;
+  llvm::MDTuple *TemplateParameters = nullptr;
+  collectVarDeclProps(VD, Unit, LineNo, T, DeclName, LinkageName,
+  TemplateParameters, DContext);
+
+  auto Align = getDeclAlignIfRequired(VD, CGM.getContext());
+  llvm::DINodeArray Annotations = CollectBTFDeclTagAnnotations(VD);
+  llvm::DIExpression *InitExpr = createConstantValueExpression(VD, *InitVal);
+
+  GV.reset(DBuilder.createGlobalVariableExpression(
+  TheCU, DeclName, LinkageName, Unit, LineNo, getOrCreateType(T, Unit),
+  true, true, InitExpr, getOrCreateStaticDataMemberDeclarationOrNull(VD),
+  TemplateParameters, Align, Annotations));
+}
+
 void CGDebugInfo::EmitExternalVariable(llvm::GlobalVariable *Var,
const VarDecl *D) {
   assert(CGM.getCodeGenOpts().hasReducedDebugInfo());
@@ -5883,6 +5917,18 @@ void CGDebugInfo::finalize() {
 

[Lldb-commits] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

2023-10-31 Thread Saleem Abdulrasool via lldb-commits

https://github.com/compnerd approved this pull request.


https://github.com/llvm/llvm-project/pull/70793
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] On AArch64, reconfigure register context first (PR #70742)

2023-10-31 Thread David Spickett via lldb-commits


@@ -1642,9 +1642,22 @@ ThreadSP ProcessGDBRemote::SetThreadStopInfo(
   }
 
   ThreadGDBRemote *gdb_thread = static_cast(thread_sp.get());
-  RegisterContextSP gdb_reg_ctx_sp(gdb_thread->GetRegisterContext());
+  RegisterContextSP reg_ctx_sp(gdb_thread->GetRegisterContext());
 
-  gdb_reg_ctx_sp->InvalidateIfNeeded(true);
+  reg_ctx_sp->InvalidateIfNeeded(true);
+
+  // AArch64 SVE/SME specific code below updates SVE and ZA register sizes and
+  // offsets if value of VG or SVG registers has changed since last stop.
+  const ArchSpec  = GetTarget().GetArchitecture();
+  if (arch.IsValid() && arch.GetTriple().isAArch64()) {

DavidSpickett wrote:

It needs to modify the register context itself, so it's unlikely that it'll be 
as clean as that but I can give it a go. At least the ABI plugin could give a 
yes/no as to whether reconfiguring should occur.

https://github.com/llvm/llvm-project/pull/70742
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

2023-10-31 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett approved this pull request.

Assuming I understand correctly that previously, the error was only consumed 
when logging was enabled, this LGTM.

https://github.com/llvm/llvm-project/pull/70793
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix misleading indentiation warning in ScriptInterpreterPython (NFC) (PR #70732)

2023-10-31 Thread Tulio Magno Quites Machado Filho via lldb-commits

tuliom wrote:

Thank you!

https://github.com/llvm/llvm-project/pull/70732
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

2023-10-31 Thread Stefan Gränitz via lldb-commits

weliveindetail wrote:

Sorry, I had a few unrelated patched in the pipe. I force-pushed to fix that.

https://github.com/llvm/llvm-project/pull/70793
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

2023-10-31 Thread via lldb-commits

github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff c280bed85a8b9cd6ebf48f9f2923890edc7039f0 
5091d1ffec05ec65e4e762d2bea8735d0de7b6fb -- 
lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp 
lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp 
llvm/include/llvm-c/Orc.h llvm/include/llvm/ExecutionEngine/JITLink/JITLink.h 
llvm/include/llvm/ExecutionEngine/JITLink/aarch32.h 
llvm/include/llvm/ExecutionEngine/JITLink/aarch64.h 
llvm/include/llvm/ExecutionEngine/JITLink/loongarch.h 
llvm/lib/ExecutionEngine/JITLink/ELF_aarch32.cpp 
llvm/lib/ExecutionEngine/JITLink/aarch32.cpp 
llvm/tools/llvm-jitlink/llvm-jitlink-elf.cpp
``





View the diff from clang-format here.


``diff
diff --git a/llvm/lib/ExecutionEngine/JITLink/aarch32.cpp 
b/llvm/lib/ExecutionEngine/JITLink/aarch32.cpp
index b31dd5c22..674220025 100644
--- a/llvm/lib/ExecutionEngine/JITLink/aarch32.cpp
+++ b/llvm/lib/ExecutionEngine/JITLink/aarch32.cpp
@@ -627,7 +627,7 @@ static Symbol (LinkGraph , Section 
,
   constexpr uint8_t AlignmentThumb = 2;
   constexpr orc::ExecutorAddr MaxAddrThumb{~uint32_t(AlignmentThumb - 1)};
   constexpr uint64_t PointerSize = 4;
-  constexpr char NullPointerContent[] { 0x00, 0x00, 0x00, 0x00 };
+  constexpr char NullPointerContent[]{0x00, 0x00, 0x00, 0x00};
   auto  = G.createContentBlock(PointerSection, NullPointerContent,
  MaxAddrThumb, AlignmentThumb, 0);
   if (InitialTarget)
diff --git a/llvm/tools/llvm-jitlink/llvm-jitlink-elf.cpp 
b/llvm/tools/llvm-jitlink/llvm-jitlink-elf.cpp
index 2adf6df9b..4b7b3f9be 100644
--- a/llvm/tools/llvm-jitlink/llvm-jitlink-elf.cpp
+++ b/llvm/tools/llvm-jitlink/llvm-jitlink-elf.cpp
@@ -56,9 +56,9 @@ static Expected getELFStubTarget(LinkGraph , 
Block ) {
 return E.takeError();
   auto  = E->getTarget();
   if (!GOTSym.isDefined())
-return make_error(
-"Stubs entry in " + G.getName() + " does not point to GOT entry",
-inconvertibleErrorCode());
+return make_error("Stubs entry in " + G.getName() +
+   " does not point to GOT entry",
+   inconvertibleErrorCode());
   if (!isELFGOTSection(GOTSym.getBlock().getSection()))
 return make_error(
 "Stubs entry in " + G.getName() + ", \"" +

``




https://github.com/llvm/llvm-project/pull/70793
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

2023-10-31 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Stefan Gränitz (weliveindetail)


Changes

I actually ran into it with a downstream fork:
```
llvm::Error::fatalUncheckedError(), llvm-project\llvm\lib\Support\Error.cpp, 
line 117
ObjectFilePECOFF::AppendFromCOFFSymbolTable(), 
llvm-project\lldb\source\Plugins\ObjectFile\PECOFF\ObjectFilePECOFF.cpp, line 
806
ObjectFilePECOFF::ParseSymtab(), 
llvm-project\lldb\source\Plugins\ObjectFile\PECOFF\ObjectFilePECOFF.cpp, line 
777
```

If logging is disabled `LLDB_LOG_ERROR` calls `llvm::consumeError()`, which 
marks the error as checked. All `llvm::Error`s must be checked before 
destruction. This patch fixes one more such case in 
`ObjectFileCOFF::ParseSymtab()`.

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


11 Files Affected:

- (modified) lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp (+3-3) 
- (modified) lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp (+4-5) 


``diff
diff --git a/lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp 
b/lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp
index 03c454bf3efab14..a7ad5d27b237f12 100644
--- a/lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp
+++ b/lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp
@@ -271,9 +271,9 @@ void ObjectFileCOFF::ParseSymtab(lldb_private::Symtab 
) {
 const auto COFFSymRef = m_object->getCOFFSymbol(SymRef);
 
 Expected NameOrErr = SymRef.getName();
-if (auto error = NameOrErr.takeError()) {
-  LLDB_LOG(log, "ObjectFileCOFF: failed to get symbol name: {0}",
-   llvm::fmt_consume(std::move(error)));
+if (!NameOrErr) {
+  LLDB_LOG_ERROR(log, NameOrErr.takeError(),
+ "ObjectFileCOFF: failed to get symbol name: {0}");
   continue;
 }
 
diff --git a/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp 
b/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
index 7fb10a69391c566..be0020cad5bee8e 100644
--- a/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ b/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
@@ -791,11 +791,10 @@ void ObjectFilePECOFF::AppendFromCOFFSymbolTable(
   for (const auto _ref : m_binary->symbols()) {
 const auto coff_sym_ref = m_binary->getCOFFSymbol(sym_ref);
 auto name_or_error = sym_ref.getName();
-if (auto err = name_or_error.takeError()) {
-  LLDB_LOG(log,
-   "ObjectFilePECOFF::AppendFromCOFFSymbolTable - failed to get "
-   "symbol table entry name: {0}",
-   llvm::fmt_consume(std::move(err)));
+if (!name_or_error) {
+  LLDB_LOG_ERROR(log, name_or_error.takeError(),
+ "ObjectFilePECOFF::AppendFromCOFFSymbolTable - failed to "
+ "get symbol table entry name: {0}");
   continue;
 }
 const llvm::StringRef sym_name = *name_or_error;

``




https://github.com/llvm/llvm-project/pull/70793
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

2023-10-31 Thread Stefan Gränitz via lldb-commits

https://github.com/weliveindetail updated 
https://github.com/llvm/llvm-project/pull/70793

From a4fecdd4bd9b12b1151d62892bcad7bab6833ce0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?= 
Date: Tue, 31 Oct 2023 13:12:21 +0100
Subject: [PATCH] [lldb] Fix missing comsumeError() with LLDB_LOG in
 ObjectFileCOFF/PECOFF

---
 lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp   | 6 +++---
 .../Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp   | 9 -
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp 
b/lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp
index 03c454bf3efab14..a7ad5d27b237f12 100644
--- a/lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp
+++ b/lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp
@@ -271,9 +271,9 @@ void ObjectFileCOFF::ParseSymtab(lldb_private::Symtab 
) {
 const auto COFFSymRef = m_object->getCOFFSymbol(SymRef);
 
 Expected NameOrErr = SymRef.getName();
-if (auto error = NameOrErr.takeError()) {
-  LLDB_LOG(log, "ObjectFileCOFF: failed to get symbol name: {0}",
-   llvm::fmt_consume(std::move(error)));
+if (!NameOrErr) {
+  LLDB_LOG_ERROR(log, NameOrErr.takeError(),
+ "ObjectFileCOFF: failed to get symbol name: {0}");
   continue;
 }
 
diff --git a/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp 
b/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
index 7fb10a69391c566..be0020cad5bee8e 100644
--- a/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ b/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
@@ -791,11 +791,10 @@ void ObjectFilePECOFF::AppendFromCOFFSymbolTable(
   for (const auto _ref : m_binary->symbols()) {
 const auto coff_sym_ref = m_binary->getCOFFSymbol(sym_ref);
 auto name_or_error = sym_ref.getName();
-if (auto err = name_or_error.takeError()) {
-  LLDB_LOG(log,
-   "ObjectFilePECOFF::AppendFromCOFFSymbolTable - failed to get "
-   "symbol table entry name: {0}",
-   llvm::fmt_consume(std::move(err)));
+if (!name_or_error) {
+  LLDB_LOG_ERROR(log, name_or_error.takeError(),
+ "ObjectFilePECOFF::AppendFromCOFFSymbolTable - failed to "
+ "get symbol table entry name: {0}");
   continue;
 }
 const llvm::StringRef sym_name = *name_or_error;

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


[Lldb-commits] [llvm] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

2023-10-31 Thread Stefan Gränitz via lldb-commits

https://github.com/weliveindetail created 
https://github.com/llvm/llvm-project/pull/70793

I actually ran into it with a downstream fork:
```
llvm::Error::fatalUncheckedError(), llvm-project\llvm\lib\Support\Error.cpp, 
line 117
ObjectFilePECOFF::AppendFromCOFFSymbolTable(), 
llvm-project\lldb\source\Plugins\ObjectFile\PECOFF\ObjectFilePECOFF.cpp, line 
806
ObjectFilePECOFF::ParseSymtab(), 
llvm-project\lldb\source\Plugins\ObjectFile\PECOFF\ObjectFilePECOFF.cpp, line 
777
```

If logging is disabled `LLDB_LOG_ERROR` calls `llvm::consumeError()`, which 
marks the error as checked. All `llvm::Error`s must be checked before 
destruction. This patch fixes one more such case in 
`ObjectFileCOFF::ParseSymtab()`.

From 923cabecd8486514f00c9cf81263169e5b263ef0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?= 
Date: Wed, 18 Oct 2023 14:27:51 +0200
Subject: [PATCH 1/4] [llvm-jitlink] Avoid assertion failure in make_error

If GOTSym is not defined this failed with:
```
Assertion failed: (Base->isDefined() && "Not a defined symbol"), function 
getBlock, file JITLink.h, line 554.
```
---
 llvm/tools/llvm-jitlink/llvm-jitlink-elf.cpp | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/llvm/tools/llvm-jitlink/llvm-jitlink-elf.cpp 
b/llvm/tools/llvm-jitlink/llvm-jitlink-elf.cpp
index 7881660d1a73851..2adf6df9b7615e9 100644
--- a/llvm/tools/llvm-jitlink/llvm-jitlink-elf.cpp
+++ b/llvm/tools/llvm-jitlink/llvm-jitlink-elf.cpp
@@ -55,7 +55,11 @@ static Expected getELFStubTarget(LinkGraph , 
Block ) {
   if (!E)
 return E.takeError();
   auto  = E->getTarget();
-  if (!GOTSym.isDefined() || !isELFGOTSection(GOTSym.getBlock().getSection()))
+  if (!GOTSym.isDefined())
+return make_error(
+"Stubs entry in " + G.getName() + " does not point to GOT entry",
+inconvertibleErrorCode());
+  if (!isELFGOTSection(GOTSym.getBlock().getSection()))
 return make_error(
 "Stubs entry in " + G.getName() + ", \"" +
 GOTSym.getBlock().getSection().getName() +

From c07c00bc4dc11430b965cdcade028d9375cf8cbc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?= 
Date: Wed, 18 Oct 2023 14:30:11 +0200
Subject: [PATCH 2/4] [JITLink] Fix typos: symobls -> symbols (NFC)

---
 llvm/include/llvm-c/Orc.h | 2 +-
 llvm/include/llvm/ExecutionEngine/JITLink/JITLink.h   | 2 +-
 llvm/include/llvm/ExecutionEngine/JITLink/aarch64.h   | 2 +-
 llvm/include/llvm/ExecutionEngine/JITLink/loongarch.h | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/llvm/include/llvm-c/Orc.h b/llvm/include/llvm-c/Orc.h
index a40b17b712fb3f2..3d17073dfdd8d41 100644
--- a/llvm/include/llvm-c/Orc.h
+++ b/llvm/include/llvm-c/Orc.h
@@ -346,7 +346,7 @@ typedef struct LLVMOrcOpaqueLookupState 
*LLVMOrcLookupStateRef;
  * into.
  *
  * The JDLookupFlags argument can be inspected to determine whether the 
original
- * lookup included non-exported symobls.
+ * lookup included non-exported symbols.
  *
  * Finally, the LookupSet argument contains the set of symbols that could not
  * be found in JD already (the set of generation candidates).
diff --git a/llvm/include/llvm/ExecutionEngine/JITLink/JITLink.h 
b/llvm/include/llvm/ExecutionEngine/JITLink/JITLink.h
index fb758f7a66cf55f..8a019492c12d593 100644
--- a/llvm/include/llvm/ExecutionEngine/JITLink/JITLink.h
+++ b/llvm/include/llvm/ExecutionEngine/JITLink/JITLink.h
@@ -1862,7 +1862,7 @@ Error makeAlignmentError(llvm::orc::ExecutorAddr Loc, 
uint64_t Value, int N,
  const Edge );
 
 /// Creates a new pointer block in the given section and returns an
-/// Anonymous symobl pointing to it.
+/// Anonymous symbol pointing to it.
 ///
 /// The pointer block will have the following default values:
 ///   alignment: PointerSize
diff --git a/llvm/include/llvm/ExecutionEngine/JITLink/aarch64.h 
b/llvm/include/llvm/ExecutionEngine/JITLink/aarch64.h
index 8d3f29b545f21ad..27a90ebef3d6d6a 100644
--- a/llvm/include/llvm/ExecutionEngine/JITLink/aarch64.h
+++ b/llvm/include/llvm/ExecutionEngine/JITLink/aarch64.h
@@ -618,7 +618,7 @@ extern const char NullPointerContent[PointerSize];
 extern const char PointerJumpStubContent[12];
 
 /// Creates a new pointer block in the given section and returns an
-/// Anonymous symobl pointing to it.
+/// Anonymous symbol pointing to it.
 ///
 /// If InitialTarget is given then an Pointer64 relocation will be added to the
 /// block pointing at InitialTarget.
diff --git a/llvm/include/llvm/ExecutionEngine/JITLink/loongarch.h 
b/llvm/include/llvm/ExecutionEngine/JITLink/loongarch.h
index bec657723a38cf9..26351ed9971cc46 100644
--- a/llvm/include/llvm/ExecutionEngine/JITLink/loongarch.h
+++ b/llvm/include/llvm/ExecutionEngine/JITLink/loongarch.h
@@ -280,7 +280,7 @@ inline ArrayRef getStubBlockContent(LinkGraph ) {
 }
 
 /// Creates a new pointer block in the given section and returns an
-/// Anonymous symobl pointing to it.
+/// Anonymous symbol pointing to 

[Lldb-commits] [lldb] [LLDB] On AArch64, reconfigure register context first (PR #70742)

2023-10-31 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett approved this pull request.

Happy for this to land as is given that it is a strict improvement over the 
current state (however weird that is).

https://github.com/llvm/llvm-project/pull/70742
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] On AArch64, reconfigure register context first (PR #70742)

2023-10-31 Thread David Spickett via lldb-commits

DavidSpickett wrote:

> Parse the expedited registers once, reconfigure then parse them again. On the 
> assumption that no scalable register will ever be in the expedited set.

This works but due to more pessimism in: 
https://github.com/llvm/llvm-project/blob/a6dabed3483c60469ff53d51622b22efc4b7b7d2/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp#L765

We actually invalidate vg and svg before reading them again. I will check if 
this is still needed.

So, as silly as it sounds this might be the way to go:
* Parse expedited registers.
* Reconfigure if needed and invalidate all registers.
* Parse expedited registers again.

https://github.com/llvm/llvm-project/pull/70742
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] On AArch64, reconfigure register context first (PR #70742)

2023-10-31 Thread David Spickett via lldb-commits

DavidSpickett wrote:

> Invalidate only registers we know can change size.

This one doesn't work because in changing the size of any register in the 
context, you invalidate the offsets of the rest. We also cannot be sure that 
the scalable registers are in a certain place in that context. Beyond general 
purpose registers, yes, but beyond that you could have a mix of scalable and 
unscalable registers depending on the target's extensions.

https://github.com/llvm/llvm-project/pull/70742
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [llvm] [libc] [libcxx] [lldb] [flang] [compiler-rt] [clang-tools-extra] [clang] [AMDGPU] Fix nondeterminism in SIFixSGPRCopies (PR #70644)

2023-10-31 Thread Jay Foad via lldb-commits

https://github.com/jayfoad closed 
https://github.com/llvm/llvm-project/pull/70644
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] On AArch64, reconfigure register context first (PR #70742)

2023-10-31 Thread David Spickett via lldb-commits

DavidSpickett wrote:

This passed all the tests, and I see a reduction in the packets sent for a 
single step.

The value of vg is 8 and svg 4 is 4 in this case.

Before:
```
(lldb) b-remote.async>  < 800> read packet: 
$T05thread:p56d.56d;name:main.o;threads:56d;thread-pcs:0040056c;00:;01:38f5;02:48f5;03:88044000;04:;05:3d170907e9f5e52b;06:0886fcf7;07:0001;08:;09:ff00;0a:;0b:1000;0c:0822e6f7;0d:;0e:;0f:476f;10:a8efe7f7;11:4200;12:40625173;13:70054000;14:;15:50044000;16:;17:;18:;19:;1a:;1b:;1c:;1d:e0f3;1e:90f0e7f7;1f:e0f3;20:6c054000;21:2060;a1:0800;d9:0400;reason:trace;#c9
intern-state <  20> send packet: $pa1;thread:056d;#29
intern-state <  20> read packet: $0800#08
intern-state <  20> send packet: $pd9;thread:056d;#34
intern-state <  20> read packet: $0400#04
intern-state <  20> send packet: $p20;thread:056d;#f9
intern-state <  20> read packet: $6c054000#42
intern-state <  20> send packet: $p1f;thread:056d;#2e
intern-state <  20> read packet: $e0f3#1e
intern-state <  20> send packet: $p1e;thread:056d;#2d
intern-state <  20> read packet: $90f0e7f7#90
intern-state <  21> send packet: $xf200,200#5e
intern-state < 516> read packet: 
$e4f210f3905efdf730f4b035fff701f2fff7c8f3b8f32e4e3df62703400098f5fff7e4f2e8f238f5d803d8024000c8f3c079fef70100b8f3b035fff76035fff701000300010001f2fff700f4749efdf74200203bfff72043fff70100a0f33c4be9f7a0f3ac054000e0f338f0e7f770054000e0f354f0e7f77005400084044000#71
intern-state <  15> send packet: $Z0,400568,4#4d
intern-state <   6> read packet: $OK#9a
dbg.evt-handler  <  16> send packet: $jThreadsInfo#c1
dbg.evt-handler  < 224> read packet: 
$[{"name":"main.o","reason":"trace","registers":{"161":"0800","217":"0400","29":"e0f3","30":"90f0e7f7","31":"e0f3","32":"6c054000"}],"signal":5,"tid":1389}]]#76
dbg.evt-handler  <  20> send packet: $pa1;thread:056d;#29
dbg.evt-handler  <  20> read packet: $0800#08
dbg.evt-handler  <  20> send packet: $pd9;thread:056d;#34
dbg.evt-handler  <  20> read packet: $0400#04
dbg.evt-handler  <  20> send packet: $p20;thread:056d;#f9
dbg.evt-handler  <  20> read packet: $6c054000#42
```

After:
```
(lldb) b-remote.async>  < 800> read packet: 
$T05thread:p514.514;name:main.o;threads:514;thread-pcs:0040056c;00:;01:38f5;02:48f5;03:88044000;04:;05:b610134a0aa5296f;06:0886fcf7;07:0001;08:;09:ff00;0a:;0b:1000;0c:0822e6f7;0d:;0e:;0f:476f;10:a8efe7f7;11:4200;12:40625173;13:70054000;14:;15:50044000;16:;17:;18:;19:;1a:;1b:;1c:;1d:e0f3;1e:90f0e7f7;1f:e0f3;20:6c054000;21:2060;a1:0800;d9:0400;reason:trace;#14
intern-state <  20> send packet: $pa1;thread:0514;#f4
intern-state <  20> read packet: $0800#08
intern-state <  20> send packet: $pd9;thread:0514;#ff
intern-state <  20> read packet: $0400#04
intern-state <  21> send packet: $xf200,200#5e
intern-state < 516> read packet: 

[Lldb-commits] [lldb] [lldb][AArch64][Linux] Add field information for the CPSR register (PR #70300)

2023-10-31 Thread David Spickett via lldb-commits

DavidSpickett wrote:

Ping!

If you are short on time, maybe just look at `LinuxArm64RegisterFlags` which is 
the core of the change. The rest is the field information itself.

https://github.com/llvm/llvm-project/pull/70300
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [compiler-rt] [flang] [libc] [libcxx] [llvm] [lldb] [clang-tools-extra] [clang] [AMDGPU] Fix nondeterminism in SIFixSGPRCopies (PR #70644)

2023-10-31 Thread Jay Foad via lldb-commits

https://github.com/jayfoad updated 
https://github.com/llvm/llvm-project/pull/70644

>From bfc7b2041f5a05105808b0b1ee0427d9c9eb9f4b Mon Sep 17 00:00:00 2001
From: Jay Foad 
Date: Mon, 30 Oct 2023 15:23:48 +
Subject: [PATCH 1/4] Precommit test

---
 .../AMDGPU/fix-sgpr-copies-nondeterminism.ll  | 52 +++
 1 file changed, 52 insertions(+)
 create mode 100644 llvm/test/CodeGen/AMDGPU/fix-sgpr-copies-nondeterminism.ll

diff --git a/llvm/test/CodeGen/AMDGPU/fix-sgpr-copies-nondeterminism.ll 
b/llvm/test/CodeGen/AMDGPU/fix-sgpr-copies-nondeterminism.ll
new file mode 100644
index 000..8b7e691dbddeae5
--- /dev/null
+++ b/llvm/test/CodeGen/AMDGPU/fix-sgpr-copies-nondeterminism.ll
@@ -0,0 +1,52 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py 
UTC_ARGS: --version 3
+; RUN: llc -mtriple=amdgcn -mcpu=gfx1100 < %s | FileCheck %s
+
+define amdgpu_gs void @f(i32 inreg %arg, i32 %arg1, i32 %arg2) {
+; CHECK-LABEL: f:
+; CHECK:   ; %bb.0: ; %bb
+; CHECK-NEXT:s_cmp_eq_u32 s0, 0
+; CHECK-NEXT:s_mov_b32 s0, 0
+; CHECK-NEXT:s_cbranch_scc1 .LBB0_2
+; CHECK-NEXT:  ; %bb.1: ; %bb3
+; CHECK-NEXT:v_mov_b32_e32 v4, v1
+; CHECK-NEXT:s_branch .LBB0_3
+; CHECK-NEXT:  .LBB0_2:
+; CHECK-NEXT:v_mov_b32_e32 v0, 1
+; CHECK-NEXT:v_mov_b32_e32 v4, 0
+; CHECK-NEXT:  .LBB0_3: ; %bb4
+; CHECK-NEXT:v_mov_b32_e32 v1, 0
+; CHECK-NEXT:s_mov_b32 s1, s0
+; CHECK-NEXT:s_mov_b32 s2, s0
+; CHECK-NEXT:s_mov_b32 s3, s0
+; CHECK-NEXT:s_delay_alu instid0(VALU_DEP_1)
+; CHECK-NEXT:v_mov_b32_e32 v2, v1
+; CHECK-NEXT:v_mov_b32_e32 v3, v1
+; CHECK-NEXT:v_mov_b32_e32 v5, v1
+; CHECK-NEXT:v_mov_b32_e32 v6, v1
+; CHECK-NEXT:v_mov_b32_e32 v7, v1
+; CHECK-NEXT:s_clause 0x1
+; CHECK-NEXT:buffer_store_b128 v[0:3], v1, s[0:3], 0 idxen
+; CHECK-NEXT:buffer_store_b128 v[4:7], v1, s[0:3], 0 idxen
+; CHECK-NEXT:s_nop 0
+; CHECK-NEXT:s_sendmsg sendmsg(MSG_DEALLOC_VGPRS)
+; CHECK-NEXT:s_endpgm
+bb:
+  %i = icmp eq i32 %arg, 0
+  br i1 %i, label %bb4, label %bb3
+
+bb3:
+  br label %bb4
+
+bb4:
+  %i5 = phi i32 [ %arg1, %bb3 ], [ 1, %bb ]
+  %i6 = phi i32 [ %arg2, %bb3 ], [ 0, %bb ]
+  %i7 = insertelement <4 x i32> zeroinitializer, i32 %i5, i64 0
+  %i8 = bitcast <4 x i32> %i7 to <4 x float>
+  call void @llvm.amdgcn.struct.buffer.store.v4f32(<4 x float> %i8, <4 x i32> 
zeroinitializer, i32 0, i32 0, i32 0, i32 0)
+  %i9 = insertelement <4 x i32> zeroinitializer, i32 %i6, i64 0
+  %i10 = bitcast <4 x i32> %i9 to <4 x float>
+  call void @llvm.amdgcn.struct.buffer.store.v4f32(<4 x float> %i10, <4 x i32> 
zeroinitializer, i32 0, i32 0, i32 0, i32 0)
+  ret void
+}
+
+declare void @llvm.amdgcn.struct.buffer.store.v4f32(<4 x float>, <4 x i32>, 
i32, i32, i32, i32 immarg)

>From aa050e8d720150b97d7af18d97d1d7f5d010bedc Mon Sep 17 00:00:00 2001
From: Jay Foad 
Date: Mon, 30 Oct 2023 10:40:22 +
Subject: [PATCH 2/4] [AMDGPU] Fix nondeterminism in SIFixSGPRCopies

There are a couple of loops that iterate over V2SCopies. The iteration
order needs to be deterministic, otherwise we can call moveToVALU in
different orders, which causes temporary vregs to be allocated in
different orders, which can affect register allocation heuristics.
---
 llvm/lib/Target/AMDGPU/SIFixSGPRCopies.cpp|  8 +++
 .../AMDGPU/fix-sgpr-copies-nondeterminism.ll  | 22 +--
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/llvm/lib/Target/AMDGPU/SIFixSGPRCopies.cpp 
b/llvm/lib/Target/AMDGPU/SIFixSGPRCopies.cpp
index b32ed9fef5dd34e..3e6ed2d793ae563 100644
--- a/llvm/lib/Target/AMDGPU/SIFixSGPRCopies.cpp
+++ b/llvm/lib/Target/AMDGPU/SIFixSGPRCopies.cpp
@@ -125,7 +125,7 @@ class SIFixSGPRCopies : public MachineFunctionPass {
   SmallVector PHINodes;
   SmallVector S2VCopies;
   unsigned NextVGPRToSGPRCopyID;
-  DenseMap V2SCopies;
+  MapVector V2SCopies;
   DenseMap> SiblingPenalty;
 
 public:
@@ -988,7 +988,7 @@ bool SIFixSGPRCopies::needToBeConvertedToVALU(V2SCopyInfo 
*Info) {
   for (auto J : Info->Siblings) {
 auto InfoIt = V2SCopies.find(J);
 if (InfoIt != V2SCopies.end()) {
-  MachineInstr *SiblingCopy = InfoIt->getSecond().Copy;
+  MachineInstr *SiblingCopy = InfoIt->second.Copy;
   if (SiblingCopy->isImplicitDef())
 // the COPY has already been MoveToVALUed
 continue;
@@ -1023,12 +1023,12 @@ void 
SIFixSGPRCopies::lowerVGPR2SGPRCopies(MachineFunction ) {
 unsigned CurID = LoweringWorklist.pop_back_val();
 auto CurInfoIt = V2SCopies.find(CurID);
 if (CurInfoIt != V2SCopies.end()) {
-  V2SCopyInfo C = CurInfoIt->getSecond();
+  V2SCopyInfo C = CurInfoIt->second;
   LLVM_DEBUG(dbgs() << "Processing ...\n"; C.dump());
   for (auto S : C.Siblings) {
 auto SibInfoIt = V2SCopies.find(S);
 if (SibInfoIt != V2SCopies.end()) {
-  V2SCopyInfo  = SibInfoIt->getSecond();
+  V2SCopyInfo  = SibInfoIt->second;
   

[Lldb-commits] [lldb] [LLDB] Don't ignore artificial variables and members for coroutines (PR #70779)

2023-10-31 Thread Adrian Vogelsgesang via lldb-commits

https://github.com/vogelsgesang edited 
https://github.com/llvm/llvm-project/pull/70779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] Don't ignore artificial variables and members for coroutines (PR #70779)

2023-10-31 Thread Adrian Vogelsgesang via lldb-commits


@@ -41,7 +41,10 @@ CPPLanguageRuntime::CPPLanguageRuntime(Process *process)
 : LanguageRuntime(process) {}
 
 bool CPPLanguageRuntime::IsAllowedRuntimeValue(ConstString name) {
-  return name == g_this;
+  // FIXME: use a list when the list grows more.
+  return name == g_this ||
+ name == ConstString("__promise") ||
+ name == ConstString("__coro_frame");

vogelsgesang wrote:

I am not sure if I would expose the `__coro_frame` variable. Maybe I would only 
expose the `__promise` variable by default. The `__coro_frame` is usually 
out-of-sync and does not hold the up-to-date coroutine state while the 
coroutine is in flight

https://github.com/llvm/llvm-project/pull/70779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] Don't ignore artificial variables and members for coroutines (PR #70779)

2023-10-31 Thread Adrian Vogelsgesang via lldb-commits

https://github.com/vogelsgesang commented:

I can't provide feedback on the lldb integration aspects, as I don't know the 
lldb code base well enough

https://github.com/llvm/llvm-project/pull/70779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] Don't ignore artificial variables and members for coroutines (PR #70779)

2023-10-31 Thread via lldb-commits

github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff 00a831421fdd94aec65221bdb37042c1aacfe8e0 
4cc40aafef4db5133f4360b2fb367e1776dc2901 -- 
lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
``





View the diff from clang-format here.


``diff
diff --git 
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp 
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
index c7d9eb37f9b5..1018db81a58a 100644
--- a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
+++ b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
@@ -42,8 +42,7 @@ CPPLanguageRuntime::CPPLanguageRuntime(Process *process)
 
 bool CPPLanguageRuntime::IsAllowedRuntimeValue(ConstString name) {
   // FIXME: use a list when the list grows more.
-  return name == g_this ||
- name == ConstString("__promise") ||
+  return name == g_this || name == ConstString("__promise") ||
  name == ConstString("__coro_frame");
 }
 

``




https://github.com/llvm/llvm-project/pull/70779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] Don't ignore artificial variables and members for coroutines (PR #70779)

2023-10-31 Thread Haojian Wu via lldb-commits

https://github.com/hokein created 
https://github.com/llvm/llvm-project/pull/70779

Fixes #69309 

* always populate all fields for the generated coroutine frame type;
* make the artificial variables `__promise`, `__coro_frame` visible, so that 
they are present in the `frame var` command;

>From 4cc40aafef4db5133f4360b2fb367e1776dc2901 Mon Sep 17 00:00:00 2001
From: Haojian Wu 
Date: Tue, 31 Oct 2023 11:15:45 +0100
Subject: [PATCH] [LLDB] Don't ignore artificial variables and members for
 coroutines

* always populate all fields for the generated coroutine frame type;
* make the artificial variables `__promise`, `__coro_frame` visible, so
  that they are present in the `frame var` command;
---
 .../Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp | 5 -
 lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp | 3 ++-
 lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp | 4 
 lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h   | 3 +++
 4 files changed, 13 insertions(+), 2 deletions(-)

diff --git 
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp 
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
index c2488eaa9f5b50d..c7d9eb37f9b5199 100644
--- a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
+++ b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
@@ -41,7 +41,10 @@ CPPLanguageRuntime::CPPLanguageRuntime(Process *process)
 : LanguageRuntime(process) {}
 
 bool CPPLanguageRuntime::IsAllowedRuntimeValue(ConstString name) {
-  return name == g_this;
+  // FIXME: use a list when the list grows more.
+  return name == g_this ||
+ name == ConstString("__promise") ||
+ name == ConstString("__coro_frame");
 }
 
 bool CPPLanguageRuntime::GetObjectDescription(Stream ,
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 182cc6764651747..d2708d183801035 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -3061,7 +3061,8 @@ void DWARFASTParserClang::ParseSingleMember(
   // artificial member with (unnamed bitfield) padding.
   // FIXME: This check should verify that this is indeed an artificial member
   // we are supposed to ignore.
-  if (attrs.is_artificial) {
+  if (attrs.is_artificial &&
+  !TypeSystemClang::IsCoroutineFrameType(class_clang_type)) {
 last_field_info.SetIsArtificial(true);
 return;
   }
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index f037708efc38007..138f5531db2a9fb 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -771,6 +771,10 @@ TypeSystemClang 
*TypeSystemClang::GetASTContext(clang::ASTContext *ast) {
   return clang_ast;
 }
 
+bool TypeSystemClang::IsCoroutineFrameType(const CompilerType ) {
+  return Type.GetTypeName().GetStringRef().ends_with(".coro_frame_ty");
+}
+
 clang::MangleContext *TypeSystemClang::getMangleContext() {
   if (m_mangle_ctx_up == nullptr)
 m_mangle_ctx_up.reset(getASTContext().createMangleContext());
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
index 0ec2d026e996105..6168a065eb522e9 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
@@ -154,6 +154,9 @@ class TypeSystemClang : public TypeSystem {
 
   static TypeSystemClang *GetASTContext(clang::ASTContext *ast_ctx);
 
+  // Returns true if the given type is a coroutine frame debug type.
+  static bool IsCoroutineFrameType(const CompilerType );
+
   /// Returns the display name of this TypeSystemClang that indicates what
   /// purpose it serves in LLDB. Used for example in logs.
   llvm::StringRef getDisplayName() const { return m_display_name; }

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


[Lldb-commits] [lldb] [lldb][AArch64] Add SME2's ZT0 register (PR #70205)

2023-10-31 Thread David Spickett via lldb-commits

DavidSpickett wrote:

Rebased this to include the `IsPresent` change, otherwise it's the same as 
before.

https://github.com/llvm/llvm-project/pull/70205
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][AArch64] Add SME2's ZT0 register (PR #70205)

2023-10-31 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett updated 
https://github.com/llvm/llvm-project/pull/70205

>From da28585bcb47732ee54e8bd8e5b483c797f9f1d8 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Tue, 3 Oct 2023 13:24:39 +0100
Subject: [PATCH 1/4] [lldb][AArch64] Add SME2's ZT0 register

SME2 is documented as part of the main SME supplement:
https://developer.arm.com/documentation/ddi0616/latest/

The one change for debug is this new ZT0 register. This register
contains data to be used with new table lookup instructions.
It's size is always 512 bits (not scalable) and can be
interpreted in many different ways depending on the instructions
that use it.

The kernel has implemented this as a new register set containing
this single register. It always returns register data (with no header,
unlike ZA which does have a header).

https://docs.kernel.org/arch/arm64/sme.html

ZT0 is only active when ZA is active (when SVCR.ZA is 1). In the
inactive state the kernel returns 0s for its contents. Therefore
lldb doesn't need to create 0s like it does for ZA.

However, we will skip restoring the value of ZT0 if we know that
ZA is inactive. As writing to an inactive ZT0 sets SVCR.ZA to 1,
which is not desireable as it would activate ZA also. Whether
SVCR.ZA is set will be determined only by the ZA data we restore.

Due to this, I've added a new save/restore kind SME2. This is easier
than accounting for the variable length ZA in the SME data. We'll only
save an SME2 data block if ZA is active. If it's not we can get fresh
0s back from the kernel for ZT0 anyway so there's nothing for us to restore.

This new register will only show up if the system has SME2 therefore
the SME set presented to the user may change, and I've had to account
for that in in a few places.

I've referred to it internally as simply "ZT" as the kernel does in
NT_ARM_ZT, but the architecture refers to the specific register as "ZT0"
so that's what you'll see in lldb.

```
(lldb) register read -s 6
Scalable Matrix Extension Registers:
  svcr = 0x
   svg = 0x0004
za = {0x00 <...> 0x00}
   zt0 = {0x00 <...> 0x00}
```
---
 .../NativeRegisterContextLinux_arm64.cpp  | 133 --
 .../Linux/NativeRegisterContextLinux_arm64.h  |  12 ++
 .../Utility/RegisterInfoPOSIX_arm64.cpp   |  50 +--
 .../Process/Utility/RegisterInfoPOSIX_arm64.h |   5 +-
 .../Process/elf-core/RegisterUtilities.h  |   4 +
 5 files changed, 177 insertions(+), 27 deletions(-)

diff --git 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
index 22aa2f3a920945d..1127d577e344c43 100644
--- a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -45,6 +45,11 @@
 #define NT_ARM_ZA 0x40c /* ARM Scalable Matrix Extension, Array Storage */
 #endif
 
+#ifndef NT_ARM_ZT
+#define NT_ARM_ZT  
\
+  0x40d /* ARM Scalable Matrix Extension 2, lookup table register */
+#endif
+
 #ifndef NT_ARM_PAC_MASK
 #define NT_ARM_PAC_MASK 0x406 /* Pointer authentication code masks */
 #endif
@@ -104,6 +109,17 @@ 
NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux(
 .Success())
   opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskZA);
 
+// SME's ZT0 is a 512 bit register.
+std::array zt_reg;
+ioVec.iov_base = zt_reg.data();
+ioVec.iov_len = zt_reg.size();
+regset = NT_ARM_ZT;
+if (NativeProcessLinux::PtraceWrapper(PTRACE_GETREGSET,
+  native_thread.GetID(), ,
+  , zt_reg.size())
+.Success())
+  opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskZT);
+
 NativeProcessLinux  = native_thread.GetProcess();
 
 std::optional auxv_at_hwcap =
@@ -148,6 +164,7 @@ 
NativeRegisterContextLinux_arm64::NativeRegisterContextLinux_arm64(
   ::memset(_pac_mask, 0, sizeof(m_pac_mask));
   ::memset(_tls_regs, 0, sizeof(m_tls_regs));
   ::memset(_sme_pseudo_regs, 0, sizeof(m_sme_pseudo_regs));
+  std::fill(m_zt_reg.begin(), m_zt_reg.end(), 0);
 
   m_mte_ctrl_reg = 0;
 
@@ -164,6 +181,7 @@ 
NativeRegisterContextLinux_arm64::NativeRegisterContextLinux_arm64(
   m_pac_mask_is_valid = false;
   m_mte_ctrl_is_valid = false;
   m_tls_is_valid = false;
+  m_zt_buffer_is_valid = false;
 
   // SME adds the tpidr2 register
   m_tls_size = GetRegisterInfo().IsSSVEPresent() ? sizeof(m_tls_regs)
@@ -355,6 +373,15 @@ NativeRegisterContextLinux_arm64::ReadRegister(const 
RegisterInfo *reg_info,
   // storage. Therefore its effective byte offset is always 0 even if it
   // isn't 0 within the SME register set.
   src = (uint8_t *)GetZABuffer() + GetZAHeaderSize();
+} else if (GetRegisterInfo().IsSMERegZT(reg)) {
+  // Unlike ZA, the kernel will return 

[Lldb-commits] [lldb] [LLDB] On AArch64, reconfigure register context first (PR #70742)

2023-10-31 Thread David Spickett via lldb-commits

DavidSpickett wrote:

> That results in lldb having to read each register value one at a time while 
> at that stop location, which will be a performance problem on non-local debug 
> setups.

And given that SVE/SME size can change every time we stop, "this stop" means 
"all stops". So yeah I can see the issue there.

https://github.com/llvm/llvm-project/pull/70742
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Colorize output when searching for symbols in lldb (PR #69422)

2023-10-31 Thread via lldb-commits

taalhaataahir0102 wrote:

Hi David! 

> That file does essentially what you're doing using it. You'd use the strings 
> found 
> [here](https://github.com/llvm/llvm-project/blob/cbbb545c4618969850d88bb008ab7f1c2918d5c3/lldb/include/lldb/Utility/AnsiTerminal.h#L83)
>  instead of the ASNI_...
>
> Which brings me onto the fact that this feature will have to respect the 
> `use-color` setting. The function mentioned above allows you to pass a bool 
> to it to do that, you can look at other callers of it to see how they get 
> that bool. To set this setting in lldb itself

I searched for the function `FormatAnsiTerminalCodes` to see how the bool 
option is passed in other parts of LLDB. In most of the places, `GetUseColor()` 
function of Debugger class was used to check the use-color settings. So I 
decided to use this approach `interpreter->GetDebugger().GetUseColor()` inside 
printRed function.
Few instances:
https://lldb.llvm.org/cpp_reference/Debugger_8cpp_source.html#:~:text=std%3A%3Astring%20str%20%3D,226%20%20%20%20%20%20%20%20%20%20new_prompt%2C%20GetUseColor())%3B
https://lldb.llvm.org/cpp_reference/Debugger_8cpp_source.html#:~:text=const%20bool%20use_color,%2C%20message.c_str())%3B
I guess I could not fully understand your comment :( If possible can you please 
explain it a little bit more.

https://github.com/llvm/llvm-project/pull/69422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][test] Add FindGlobalVariables tests for C++ inline static data members (PR #70641)

2023-10-31 Thread Michael Buch via lldb-commits

https://github.com/Michael137 updated 
https://github.com/llvm/llvm-project/pull/70641

>From 7de2335efd85ae6058705a6a6cd9c5b160aef757 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Sat, 28 Oct 2023 15:24:47 +0100
Subject: [PATCH 1/2] [lldb][test] Add FindGlobalVariables tests for C++
 constexpr static data members

---
 .../TestConstStaticIntegralMember.py  | 31 +++
 1 file changed, 31 insertions(+)

diff --git 
a/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
 
b/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
index 530191e8a37ba1b..8944044d5a265c0 100644
--- 
a/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
+++ 
b/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
@@ -113,6 +113,37 @@ def test_class_with_only_const_static(self):
 
 self.expect_expr("ClassWithOnlyConstStatic::member", result_value="3")
 
+def check_global_var(self, name: str, expect_type, expect_val):
+var_list = self.target().FindGlobalVariables(name, lldb.UINT32_MAX)
+self.assertEqual(len(var_list), 1)
+varobj = var_list[0]
+self.assertEqual(varobj.type.name, expect_type)
+self.assertEqual(varobj.value, expect_val)
+
+# For debug-info produced by older versions of clang, inline static data 
members
+# wouldn't get indexed into the Names accelerator table preventing LLDB 
from finding
+# them.
+@expectedFailureAll(compiler=["clang"], compiler_version=["<", "18.0"])
+@expectedFailureAll(debug_info=no_match(["dsym"]))
+def test_inline_static_members(self):
+self.build()
+lldbutil.run_to_source_breakpoint(
+self, "// break here", lldb.SBFileSpec("main.cpp")
+)
+
+self.check_global_var("A::int_val", "const int", "1")
+self.check_global_var("A::int_val_with_address", "const int", "2")
+self.check_global_var("A::bool_val", "const bool", "true")
+self.check_global_var("A::enum_val", "Enum", "enum_case2")
+self.check_global_var("A::enum_bool_val", "EnumBool", 
"enum_bool_case1")
+self.check_global_var("A::scoped_enum_val", "ScopedEnum", 
"scoped_enum_case2")
+
+self.check_global_var("ClassWithOnlyConstStatic::member", "const int", 
"3")
+
+self.check_global_var("ClassWithConstexprs::member", "const int", "2")
+self.check_global_var("ClassWithConstexprs::enum_val", "Enum", 
"enum_case2")
+self.check_global_var("ClassWithConstexprs::scoped_enum_val", 
"ScopedEnum", "scoped_enum_case2")
+
 # With older versions of Clang, LLDB fails to evaluate classes with only
 # constexpr members when dsymutil is enabled
 @expectedFailureAll(

>From 7356debaf9d6080e35a1aa3b3562bdb990a0a33e Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Tue, 31 Oct 2023 09:03:15 +
Subject: [PATCH 2/2] fixup! fix format

---
 .../TestConstStaticIntegralMember.py  | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git 
a/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
 
b/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
index 8944044d5a265c0..dd972ae401a6c62 100644
--- 
a/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
+++ 
b/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
@@ -142,7 +142,9 @@ def test_inline_static_members(self):
 
 self.check_global_var("ClassWithConstexprs::member", "const int", "2")
 self.check_global_var("ClassWithConstexprs::enum_val", "Enum", 
"enum_case2")
-self.check_global_var("ClassWithConstexprs::scoped_enum_val", 
"ScopedEnum", "scoped_enum_case2")
+self.check_global_var(
+"ClassWithConstexprs::scoped_enum_val", "ScopedEnum", 
"scoped_enum_case2"
+)
 
 # With older versions of Clang, LLDB fails to evaluate classes with only
 # constexpr members when dsymutil is enabled

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


[Lldb-commits] [flang] [clang-tools-extra] [compiler-rt] [libc] [llvm] [lldb] [clang] [libcxx] [PowerPC] Support mcmodel=large for AIX (PR #70652)

2023-10-31 Thread Qiu Chaofan via lldb-commits


@@ -5723,16 +5723,14 @@ void Clang::ConstructJob(Compilation , const 
JobAction ,
   if (Arg *A = Args.getLastArg(options::OPT_mcmodel_EQ)) {
 StringRef CM = A->getValue();
 bool Ok = false;
-if (Triple.isOSAIX() && CM == "medium") {
+if (Triple.isOSAIX() && CM == "medium")
   CM = "large";
-  Ok = true;
-}
 if (Triple.isAArch64(64)) {
   Ok = CM == "tiny" || CM == "small" || CM == "large";
   if (CM == "large" && RelocationModel != llvm::Reloc::Static)
 D.Diag(diag::err_drv_argument_only_allowed_with)
 << A->getAsString(Args) << "-fno-pic";
-} else if (Triple.isPPC64()) {
+} else if (Triple.isPPC64() || Triple.isOSAIX()) {

ecnelises wrote:

CC @chmeeedalf 

https://github.com/llvm/llvm-project/pull/70652
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [compiler-rt] [libcxx] [llvm] [lldb] [flang] [clang] [clang-tools-extra] [libc] [PowerPC] Support mcmodel=large for AIX (PR #70652)

2023-10-31 Thread Chen Zheng via lldb-commits


@@ -5723,16 +5723,14 @@ void Clang::ConstructJob(Compilation , const 
JobAction ,
   if (Arg *A = Args.getLastArg(options::OPT_mcmodel_EQ)) {
 StringRef CM = A->getValue();
 bool Ok = false;
-if (Triple.isOSAIX() && CM == "medium") {
+if (Triple.isOSAIX() && CM == "medium")
   CM = "large";
-  Ok = true;
-}
 if (Triple.isAArch64(64)) {
   Ok = CM == "tiny" || CM == "small" || CM == "large";
   if (CM == "large" && RelocationModel != llvm::Reloc::Static)
 D.Diag(diag::err_drv_argument_only_allowed_with)
 << A->getAsString(Args) << "-fno-pic";
-} else if (Triple.isPPC64()) {
+} else if (Triple.isPPC64() || Triple.isOSAIX()) {

chenzheng1030 wrote:

AIX seems good now.
However I think we still have one active ppc32 target like SPE working on PPC. 
So now clang can not accept any code model for target `-target powerpcspe`.
>From simple testing, this target supports all these three models.

https://github.com/llvm/llvm-project/pull/70652
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


  1   2   >