[Lldb-commits] [lldb] [lldb][AArch64] Simplify handing of scalable registers using vg and svg (PR #70914)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett created 
https://github.com/llvm/llvm-project/pull/70914

This removes explicit invalidation of vg and svg that was done in 
`GDBRemoteRegisterContext::AArch64Reconfigure`. This was in fact covering up a 
bug elsehwere.

Register information says that a write to vg also invalidates svg (it does not 
unless you are in streaming mode, but we decided to keep it simple and say it 
always does).

This invalidation was not being applied until *after* AArch64Reconfigure was 
called. This meant that without those manual invalidates this happened:
* vg is written
* svg is not invalidated
* Reconfigure uses the written vg value
* Reconfigure uses the *old* svg value

I have moved the AArch64Reconfigure call to after we've processed the 
invalidations caused by the register write, so we no longer need the manual 
invalidates in AArch64Reconfigure.

In addition I have changed the order in which expedited registers as parsed. 
These registers come with a stop notification and include, amongst others, vg 
and svg.

So now we:
* Parse them and update register values (including vg and svg)
* AArch64Reconfigure, which uses those values, and invalidates every register, 
because offsets may have changed.
* Parse the expedited registers again, knowing that none of the values will 
have changed due to the scaling.

This means we use the expedited registers during the reconfigure, but the 
invalidate does not mean we throw all of them away.

The cost is we parse them twice client side, but this is cheap compared to a 
network packet, and is limited to AArch64 targets only.

On a system with SVE and SME, these are the packets sent for a step:
```
(lldb) b-remote.async>  < 803> read packet:
$T05thread:p1f80.1f80;name:main.o;threads:1f80;thread-pcs:0040056c<...>a1:0800;d9:0400;reason:trace;#fc
intern-state <  21> send packet: $xf200,200#5e
intern-state < 516> read packet:
$e4f200<...>#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",<...>}],"signal":5,"tid":8064}]]#73
```

You can see there are no extra register reads which means we're using the 
expedited registers.

For a write to vg:
```
(lldb) register write vg 4
lldb <  37> send packet:
$Pa1=0400;thread:1f80;#4a
lldb <   6> read packet: $OK#9a
lldb <  20> send packet: $pa1;thread:1f80;#29
lldb <  20> read packet: $0400#04
lldb <  20> send packet: $pd9;thread:1f80;#34
lldb <  20> read packet: $0400#04
```

There is the initial P write, and lldb correctly assumes that SVG is 
invalidated by this also so we read back the new vg and svg values afterwards.

>From 8b92eb75f1f728a95e91d48e02937bf91bcfb501 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Tue, 31 Oct 2023 14:11:47 +
Subject: [PATCH] [lldb][AArch64] Simplify handing of scalable registers using
 vg and svg

This removes explicit invalidation of vg and svg that was done in
`GDBRemoteRegisterContext::AArch64Reconfigure`. This was in fact
covering up a bug elsehwere.

Register information says that a write to vg also invalidates svg
(it does not unless you are in streaming mode, but we decided to
keep it simple and say it always does).

This invalidation was not being applied until *after* AArch64Reconfigure
was called. This meant that without those manual invalidates this
happened:
* vg is written
* svg is not invalidated
* Reconfigure uses the written vg value
* Reconfigure uses the *old* svg value

I have moved the AArch64Reconfigure call to after we've processed
the invalidations caused by the register write, so we no longer
need the manual invalidates in AArch64Reconfigure.

In addition I have changed the order in which expedited registers
as parsed. These registers come with a stop notification and include,
amongst others, vg and svg.

So now we:
* Parse them and update register values (including vg and svg)
* AArch64Reconfigure, which uses those values, and invalidates every
  register, because offsets may have changed.
* Parse the expedited registers again, knowing that none of the
  values will have changed due to the scaling.

This means we use the expedited registers during the reconfigure,
but the invalidate does not mean we throw all of them away.

The cost is we parse them twice client side, but this is cheap
compared to a network packet, and is limited to AArch64 targets
only.

On a system with SVE and SME, these are the packets sent for a step:
```
(lldb) b-remote.async>  < 803> read packet:
$T05thread:p1f80.1f80;name:main.o;threads:1f80;thread-pcs:0040056c<...>a1:0800;d9:0400;reason:trace;#fc
intern-state <  21> send packet: $xf200,200#5e
intern

[Lldb-commits] [lldb] b120fe8 - [clang][NFC] Refactor `ArgPassingKind`

[Vlad Serebrennikov via lldb-commits]

Author: Vlad Serebrennikov
Date: 2023-11-01T11:49:59+03:00
New Revision: b120fe8d3288c4dca1b5427ca34839ce8833f71c

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

LOG: [clang][NFC] Refactor `ArgPassingKind`

This patch moves `RecordDecl::ArgPassingKind` to DeclBase.h to namespace scope, 
so that it's complete at the time bit-field is declared.

Added: 


Modified: 
clang/include/clang/AST/Decl.h
clang/include/clang/AST/DeclBase.h
clang/lib/AST/Decl.cpp
clang/lib/AST/DeclCXX.cpp
clang/lib/CodeGen/CGCall.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclCXX.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/lib/Serialization/ASTWriterDecl.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Removed: 




diff  --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index 7f076cc77ea82cb..1c2158f51aa184d 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -4069,28 +4069,6 @@ class RecordDecl : public TagDecl {
 public:
   friend class DeclContext;
   friend class ASTDeclReader;
-  /// Enum that represents the 
diff erent ways arguments are passed to and
-  /// returned from function calls. This takes into account the target-specific
-  /// and version-specific rules along with the rules determined by the
-  /// language.
-  enum ArgPassingKind : unsigned {
-/// The argument of this type can be passed directly in registers.
-APK_CanPassInRegs,
-
-/// The argument of this type cannot be passed directly in registers.
-/// Records containing this type as a subobject are not forced to be passed
-/// indirectly. This value is used only in C++. This value is required by
-/// C++ because, in uncommon situations, it is possible for a class to have
-/// only trivial copy/move constructors even when one of its subobjects has
-/// a non-trivial copy/move constructor (if e.g. the corresponding 
copy/move
-/// constructor in the derived class is deleted).
-APK_CannotPassInRegs,
-
-/// The argument of this type cannot be passed directly in registers.
-/// Records containing this type as a subobject are forced to be passed
-/// indirectly.
-APK_CanNeverPassInRegs
-  };
 
 protected:
   RecordDecl(Kind DK, TagKind TK, const ASTContext &C, DeclContext *DC,
@@ -4215,7 +4193,7 @@ class RecordDecl : public TagDecl {
   /// it must have at least one trivial, non-deleted copy or move constructor.
   /// FIXME: This should be set as part of completeDefinition.
   bool canPassInRegisters() const {
-return getArgPassingRestrictions() == APK_CanPassInRegs;
+return getArgPassingRestrictions() == ArgPassingKind::CanPassInRegs;
   }
 
   ArgPassingKind getArgPassingRestrictions() const {
@@ -4223,7 +4201,7 @@ class RecordDecl : public TagDecl {
   }
 
   void setArgPassingRestrictions(ArgPassingKind Kind) {
-RecordDeclBits.ArgPassingRestrictions = Kind;
+RecordDeclBits.ArgPassingRestrictions = llvm::to_underlying(Kind);
   }
 
   bool isParamDestroyedInCallee() const {

diff  --git a/clang/include/clang/AST/DeclBase.h 
b/clang/include/clang/AST/DeclBase.h
index 978e4255e877ec2..ba6dadd7d3563c3 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -1399,6 +1399,29 @@ enum class DeductionCandidate : unsigned char {
   Aggregate,
 };
 
+/// Enum that represents the 
diff erent ways arguments are passed to and
+/// returned from function calls. This takes into account the target-specific
+/// and version-specific rules along with the rules determined by the
+/// language.
+enum class ArgPassingKind {
+  /// The argument of this type can be passed directly in registers.
+  CanPassInRegs,
+
+  /// The argument of this type cannot be passed directly in registers.
+  /// Records containing this type as a subobject are not forced to be passed
+  /// indirectly. This value is used only in C++. This value is required by
+  /// C++ because, in uncommon situations, it is possible for a class to have
+  /// only trivial copy/move constructors even when one of its subobjects has
+  /// a non-trivial copy/move constructor (if e.g. the corresponding copy/move
+  /// constructor in the derived class is deleted).
+  CannotPassInRegs,
+
+  /// The argument of this type cannot be passed directly in registers.
+  /// Records containing this type as a subobject are forced to be passed
+  /// indirectly.
+  CanNeverPassInRegs
+};
+
 /// DeclContext - This is used only as base class of specific decl types that
 /// can act as declaration contexts. These decls are (only the top classes
 /// that directly derive from DeclContext are mentioned, not their subclasses):

diff  --git a/clan

[Lldb-commits] [lldb] [lldb][AArch64] Simplify handing of scalable registers using vg and svg (PR #70914)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)


Changes

This removes explicit invalidation of vg and svg that was done in 
`GDBRemoteRegisterContext::AArch64Reconfigure`. This was in fact covering up a 
bug elsehwere.

Register information says that a write to vg also invalidates svg (it does not 
unless you are in streaming mode, but we decided to keep it simple and say it 
always does).

This invalidation was not being applied until *after* AArch64Reconfigure was 
called. This meant that without those manual invalidates this happened:
* vg is written
* svg is not invalidated
* Reconfigure uses the written vg value
* Reconfigure uses the *old* svg value

I have moved the AArch64Reconfigure call to after we've processed the 
invalidations caused by the register write, so we no longer need the manual 
invalidates in AArch64Reconfigure.

In addition I have changed the order in which expedited registers as parsed. 
These registers come with a stop notification and include, amongst others, vg 
and svg.

So now we:
* Parse them and update register values (including vg and svg)
* AArch64Reconfigure, which uses those values, and invalidates every register, 
because offsets may have changed.
* Parse the expedited registers again, knowing that none of the values will 
have changed due to the scaling.

This means we use the expedited registers during the reconfigure, but the 
invalidate does not mean we throw all of them away.

The cost is we parse them twice client side, but this is cheap compared to a 
network packet, and is limited to AArch64 targets only.

On a system with SVE and SME, these are the packets sent for a step:
```
(lldb) b-remote.async>  < 803> read packet:
$T05thread:p1f80.1f80;name:main.o;threads:1f80;thread-pcs:0040056c<...>a1:0800;d9:0400;reason:trace;#fc
intern-state <  21> send packet: $xf200,200#5e
intern-state < 516> read packet:
$e4f200<...>#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",<...>}],"signal":5,"tid":8064}]]#73
```

You can see there are no extra register reads which means we're using the 
expedited registers.

For a write to vg:
```
(lldb) register write vg 4
lldb <  37> send packet:
$Pa1=0400;thread:1f80;#4a
lldb <   6> read packet: $OK#9a
lldb <  20> send packet: $pa1;thread:1f80;#29
lldb <  20> read packet: $0400#04
lldb <  20> send packet: $pd9;thread:1f80;#34
lldb <  20> read packet: $0400#04
```

There is the initial P write, and lldb correctly assumes that SVG is 
invalidated by this also so we read back the new vg and svg values afterwards.

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


3 Files Affected:

- (modified) 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp (+5-12) 
- (modified) lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
(+37-18) 
- (modified) lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h (+3) 


``diff
diff --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
index 72280927471f883..013b2bbc0e67f27 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -434,11 +434,6 @@ bool GDBRemoteRegisterContext::WriteRegisterBytes(const 
RegisterInfo *reg_info,
 } else {
   // This is an actual register, write it
   success = SetPrimordialRegister(reg_info, gdb_comm);
-
-  if (success && do_reconfigure_arm64_sve) {
-AArch64Reconfigure();
-InvalidateAllRegisters();
-  }
 }
 
 // Check if writing this register will invalidate any other register
@@ -452,6 +447,11 @@ bool GDBRemoteRegisterContext::WriteRegisterBytes(const 
RegisterInfo *reg_info,
false);
 }
 
+if (success && do_reconfigure_arm64_sve) {
+  AArch64Reconfigure();
+  InvalidateAllRegisters();
+}
+
 return success;
   }
 } else {
@@ -772,8 +772,6 @@ void GDBRemoteRegisterContext::AArch64Reconfigure() {
   std::optional vg_reg_value;
   const RegisterInfo *vg_reg_info = m_reg_info_sp->GetRegisterInfo("vg");
   if (vg_reg_info) {
-// Make sure we get the latest value of vg from the remote.
-SetRegisterIsValid(vg_reg_info, false);
 uint32_t vg_reg_num = vg_reg_info->kinds[eRegisterKindLLDB];
 uint64_t reg_value = ReadRegisterAsUnsigned(vg_reg_num, fail_value);
 if (reg_value != fail_value && reg_value <= 32)
@@ -783,11 +781,6 @@ void GDBRe

[Lldb-commits] [lldb] [lldb][AArch64] Simplify handing of scalable registers using vg and svg (PR #70914)

[David Spickett via lldb-commits]

DavidSpickett wrote:

And test plan here is - it passes all existing SVE/SME testing. When I simply 
removed the manual invalidates, a lot of them failed, so we have coverage 
already.

https://github.com/llvm/llvm-project/pull/70914
___
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)

[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/5] [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(), ®set,
+  &ioVec, zt_reg.size())
+.Success())
+  opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskZT);
+
 NativeProcessLinux &process = native_thread.GetProcess();
 
 std::optional auxv_at_hwcap =
@@ -148,6 +164,7 @@ 
NativeRegisterContextLinux_arm64::NativeRegisterContextLinux_arm64(
   ::memset(&m_pac_mask, 0, sizeof(m_pac_mask));
   ::memset(&m_tls_regs, 0, sizeof(m_tls_regs));
   ::memset(&m_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 

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

[David Spickett 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.

DavidSpickett wrote:

Done.

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)

[David Spickett via lldb-commits]

@@ -624,6 +661,21 @@ 
NativeRegisterContextLinux_arm64::CacheAllRegisters(uint32_t &cached_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.

DavidSpickett wrote:

Done.

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)

[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/6] [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(), ®set,
+  &ioVec, zt_reg.size())
+.Success())
+  opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskZT);
+
 NativeProcessLinux &process = native_thread.GetProcess();
 
 std::optional auxv_at_hwcap =
@@ -148,6 +164,7 @@ 
NativeRegisterContextLinux_arm64::NativeRegisterContextLinux_arm64(
   ::memset(&m_pac_mask, 0, sizeof(m_pac_mask));
   ::memset(&m_tls_regs, 0, sizeof(m_tls_regs));
   ::memset(&m_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 

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

[David Spickett 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();

DavidSpickett wrote:

We can't say "is contained in" because that could be svcr/svg or za.

I've already had to hardcode the assumption that the base sme registers are in 
SVCR/SVG/ZA order, and I think we can assume Arm won't add more registers to 
SME1. Anything new would be SME2 or a hypothetical SME3.

That means ZT0 will always be the 4th one. So I've updated the check to say if 
we have >= 4 registers, and it matches index 3 in the collection. That way this 
won't have to change when there are more later. We do have to keep the order 
the same overall, but that's unavoidable.

(and tests will fail spectacularly if you get it wrong anyway, though it won't 
be fun to debug if you weren't expecting it)

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][Symtab][NFCI] Replace vector::swap with shrink_to_fit (PR #70918)

[Michael Buch via lldb-commits]

https://github.com/Michael137 created 
https://github.com/llvm/llvm-project/pull/70918

Replaces the old idiom of swapping the container to shrink it with the newer 
STL alternative.

Similar transition in LLDB was done in: https://reviews.llvm.org/D47492

>From 52c5caf0c352fc13377e56367cc6935e3d9c8c3f Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Wed, 1 Nov 2023 10:29:20 +
Subject: [PATCH] [lldb][Symtab][NFCI] Replace vector::swap with shrink_to_fit

---
 lldb/source/Symbol/Symtab.cpp | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/lldb/source/Symbol/Symtab.cpp b/lldb/source/Symbol/Symtab.cpp
index 104faac38ffa0fe..1aebe198f9e78ae 100644
--- a/lldb/source/Symbol/Symtab.cpp
+++ b/lldb/source/Symbol/Symtab.cpp
@@ -1010,10 +1010,7 @@ void Symtab::Finalize() {
   // Calculate the size of symbols inside InitAddressIndexes.
   InitAddressIndexes();
   // Shrink to fit the symbols so we don't waste memory
-  if (m_symbols.capacity() > m_symbols.size()) {
-collection new_symbols(m_symbols.begin(), m_symbols.end());
-m_symbols.swap(new_symbols);
-  }
+  m_symbols.shrink_to_fit();
   SaveToCache();
 }
 

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

[Lldb-commits] [lldb] [lldb][Symtab][NFCI] Replace vector::swap with shrink_to_fit (PR #70918)

[Michael Buch via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][Symtab][NFCI] Replace vector::swap with shrink_to_fit (PR #70918)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)


Changes

Replaces the old idiom of swapping the container to shrink it, with the newer 
STL alternative.

Similar transition in LLDB was done in: https://reviews.llvm.org/D47492

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


1 Files Affected:

- (modified) lldb/source/Symbol/Symtab.cpp (+1-4) 


``diff
diff --git a/lldb/source/Symbol/Symtab.cpp b/lldb/source/Symbol/Symtab.cpp
index 104faac38ffa0fe..1aebe198f9e78ae 100644
--- a/lldb/source/Symbol/Symtab.cpp
+++ b/lldb/source/Symbol/Symtab.cpp
@@ -1010,10 +1010,7 @@ void Symtab::Finalize() {
   // Calculate the size of symbols inside InitAddressIndexes.
   InitAddressIndexes();
   // Shrink to fit the symbols so we don't waste memory
-  if (m_symbols.capacity() > m_symbols.size()) {
-collection new_symbols(m_symbols.begin(), m_symbols.end());
-m_symbols.swap(new_symbols);
-  }
+  m_symbols.shrink_to_fit();
   SaveToCache();
 }
 

``




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

[Lldb-commits] [lldb] [lldb][Symtab][NFCI] Replace vector::swap with shrink_to_fit (PR #70918)

[Michael Buch via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][Symtab][NFCI] Replace vector::swap with shrink_to_fit (PR #70918)

[David Spickett via lldb-commits]

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

LGTM

https://github.com/llvm/llvm-project/pull/70918
___
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)

[David Spickett via lldb-commits]

DavidSpickett wrote:

>I think of old teenage mutant ninja turtles

No ninjas over here, only heroes :)

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] aaba376 - [clang][NFC] Refactor `ObjCMethodDecl::ImplementationControl`

[Vlad Serebrennikov via lldb-commits]

Author: Vlad Serebrennikov
Date: 2023-11-01T13:40:11+03:00
New Revision: aaba3761db84032541712899964714f3184e8b3d

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

LOG: [clang][NFC] Refactor `ObjCMethodDecl::ImplementationControl`

This patch moves `ObjCMethodDecl::ImplementationControl` to a DeclBase.h so 
that it's complete at the point where corresponsing bit-field is declared. This 
patch also converts it to a scoped enum `clang::ObjCImplementationControl`.

Added: 


Modified: 
clang/include/clang/AST/DeclBase.h
clang/include/clang/AST/DeclObjC.h
clang/lib/ARCMigrate/ObjCMT.cpp
clang/lib/AST/DeclObjC.cpp
clang/lib/AST/ODRDiagsEmitter.cpp
clang/lib/AST/ODRHash.cpp
clang/lib/CodeGen/CodeGenModule.cpp
clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp
clang/lib/Sema/SemaDeclObjC.cpp
clang/lib/Sema/SemaExprObjC.cpp
clang/lib/Sema/SemaObjCProperty.cpp
clang/lib/Sema/SemaPseudoObject.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
clang/lib/Serialization/ASTWriterDecl.cpp
clang/tools/libclang/CIndex.cpp

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCDeclVendor.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Removed: 




diff  --git a/clang/include/clang/AST/DeclBase.h 
b/clang/include/clang/AST/DeclBase.h
index 7b743edf9452526..6f2c5b96554a9d1 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -1428,6 +1428,8 @@ enum class OMPDeclareReductionInitKind {
   Copy// omp_priv = 
 };
 
+enum class ObjCImplementationControl { None, Required, Optional };
+
 /// DeclContext - This is used only as base class of specific decl types that
 /// can act as declaration contexts. These decls are (only the top classes
 /// that directly derive from DeclContext are mentioned, not their subclasses):

diff  --git a/clang/include/clang/AST/DeclObjC.h 
b/clang/include/clang/AST/DeclObjC.h
index ee8ec7a6a016ba3..2b205bee51de18e 100644
--- a/clang/include/clang/AST/DeclObjC.h
+++ b/clang/include/clang/AST/DeclObjC.h
@@ -139,10 +139,6 @@ class ObjCMethodDecl : public NamedDecl, public 
DeclContext {
   // This class stores some data in DeclContext::ObjCMethodDeclBits
   // to save some space. Use the provided accessors to access it.
 
-public:
-  enum ImplementationControl { None, Required, Optional };
-
-private:
   /// Return type of this method.
   QualType MethodDeclType;
 
@@ -168,14 +164,14 @@ class ObjCMethodDecl : public NamedDecl, public 
DeclContext {
   /// constructed by createImplicitParams.
   ImplicitParamDecl *CmdDecl = nullptr;
 
-  ObjCMethodDecl(SourceLocation beginLoc, SourceLocation endLoc,
- Selector SelInfo, QualType T, TypeSourceInfo *ReturnTInfo,
- DeclContext *contextDecl, bool isInstance = true,
- bool isVariadic = false, bool isPropertyAccessor = false,
- bool isSynthesizedAccessorStub = false,
- bool isImplicitlyDeclared = false, bool isDefined = false,
- ImplementationControl impControl = None,
- bool HasRelatedResultType = false);
+  ObjCMethodDecl(
+  SourceLocation beginLoc, SourceLocation endLoc, Selector SelInfo,
+  QualType T, TypeSourceInfo *ReturnTInfo, DeclContext *contextDecl,
+  bool isInstance = true, bool isVariadic = false,
+  bool isPropertyAccessor = false, bool isSynthesizedAccessorStub = false,
+  bool isImplicitlyDeclared = false, bool isDefined = false,
+  ObjCImplementationControl impControl = ObjCImplementationControl::None,
+  bool HasRelatedResultType = false);
 
   SelectorLocationsKind getSelLocsKind() const {
 return static_cast(ObjCMethodDeclBits.SelLocsKind);
@@ -235,7 +231,7 @@ class ObjCMethodDecl : public NamedDecl, public DeclContext 
{
  bool isVariadic = false, bool isPropertyAccessor = false,
  bool isSynthesizedAccessorStub = false,
  bool isImplicitlyDeclared = false, bool isDefined = false,
- ImplementationControl impControl = None,
+ ObjCImplementationControl impControl = 
ObjCImplementationControl::None,
  bool HasRelatedResultType = false);
 
   static ObjCMethodDecl *CreateDeserialized(ASTContext &C, unsigned ID);
@@ -495,16 +491,17 @@ class ObjCMethodDecl : public NamedDecl, public 
DeclContext {
   const ObjCPropertyDecl *findPropertyDecl(bool CheckOverrides = true) const;
 
   // Related to protocols declared in  \@protocol
-  void setDeclImplementation(ImplementationControl ic) {
-ObjCMethodDeclBits.DeclImplementation = ic;
+  void setDeclImplementation(ObjCImplementationControl ic) {
+ObjCMethodDeclBits.DeclImplementation = llvm::to_underlying(ic);
   }
 
-  ImplementationControl getImplementa

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

[via lldb-commits]

Author: David Spickett
Date: 2023-11-01T10:40:25Z
New Revision: b8150c8f12fcb3c3c5e40611ddd883db1506be35

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

LOG: [lldb][AArch64] Add SME2's ZT0 register (#70205)

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}
```

Added: 

lldb/test/API/commands/register/register/aarch64_sme_z_registers/save_restore/Makefile

lldb/test/API/commands/register/register/aarch64_sme_z_registers/save_restore/TestSMEZRegistersSaveRestore.py

lldb/test/API/commands/register/register/aarch64_sme_z_registers/save_restore/main.c

lldb/test/API/commands/register/register/aarch64_sme_z_registers/za_dynamic_resize/Makefile

lldb/test/API/commands/register/register/aarch64_sme_z_registers/za_dynamic_resize/TestZAThreadedDynamic.py

lldb/test/API/commands/register/register/aarch64_sme_z_registers/za_dynamic_resize/main.c

Modified: 
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
lldb/source/Plugins/Process/elf-core/RegisterUtilities.h

lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py

Removed: 

lldb/test/API/commands/register/register/aarch64_za_register/za_dynamic_resize/Makefile

lldb/test/API/commands/register/register/aarch64_za_register/za_dynamic_resize/TestZAThreadedDynamic.py

lldb/test/API/commands/register/register/aarch64_za_register/za_dynamic_resize/main.c

lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/Makefile

lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py

lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/main.c



diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index fefe91401cb8e52..15e8ba21266c896 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -1271,6 +1271,10 @@ def isAArch64SVE(self):
 def isAArch64SME(self):
 return self.isAArch64() and "sme" in self.getCPUInfo()
 
+def isAArch64SME2(self):
+# If you have sme2, you also have sme.
+return self.isAArch64() and "sme2" in self.getCPUInfo()
+
 def isAArch64SMEFA64(self):
 # smefa64 allows the use of the full A64 instruction set in streaming
 # mode. This is required by certain test programs to setup register

diff  --git 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
index 22aa2f3a920945d..e23165933c221cf 100644
--- a/lldb/source/Plugins/Process/Linux

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

[David Spickett via lldb-commits]

https://github.com/DavidSpickett closed 
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] bc41b0a - [lldb][Symtab][NFCI] Replace vector::swap with shrink_to_fit (#70918)

[via lldb-commits]

Author: Michael Buch
Date: 2023-11-01T10:43:55Z
New Revision: bc41b0ac2b03b8c305d7399d772c87d27cc9831c

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

LOG: [lldb][Symtab][NFCI] Replace vector::swap with shrink_to_fit (#70918)

Replaces the old idiom (of swapping the container to shrink it) with the
newer STL alternative.

Similar transition in LLDB was done in: https://reviews.llvm.org/D47492

Added: 


Modified: 
lldb/source/Symbol/Symtab.cpp

Removed: 




diff  --git a/lldb/source/Symbol/Symtab.cpp b/lldb/source/Symbol/Symtab.cpp
index 104faac38ffa0fe..1aebe198f9e78ae 100644
--- a/lldb/source/Symbol/Symtab.cpp
+++ b/lldb/source/Symbol/Symtab.cpp
@@ -1010,10 +1010,7 @@ void Symtab::Finalize() {
   // Calculate the size of symbols inside InitAddressIndexes.
   InitAddressIndexes();
   // Shrink to fit the symbols so we don't waste memory
-  if (m_symbols.capacity() > m_symbols.size()) {
-collection new_symbols(m_symbols.begin(), m_symbols.end());
-m_symbols.swap(new_symbols);
-  }
+  m_symbols.shrink_to_fit();
   SaveToCache();
 }
 



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

[Lldb-commits] [lldb] [lldb][Symtab][NFCI] Replace vector::swap with shrink_to_fit (PR #70918)

[Michael Buch via lldb-commits]

https://github.com/Michael137 closed 
https://github.com/llvm/llvm-project/pull/70918
___
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)

[Stefan Gränitz via lldb-commits]

@@ -271,9 +271,9 @@ void ObjectFileCOFF::ParseSymtab(lldb_private::Symtab 
&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}");

weliveindetail wrote:

Hey Ismail! Right, this seems unconventional compared to other logging code in 
LLDB. It's not something that changed when moving from `LLDB_LOG` to 
`LLDB_LOG_ERROR` though. We should keep printing the same info, but I agree 
that this is worth fixing while I am 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] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

[Michael Buch via lldb-commits]

Michael137 wrote:

Hmmm it seems like for `constexpr static` data members we don't get a symbol in 
the MachO the same way we do for out-of-line `const static`s that have a 
location:
```
struct Foo {   
static const int val1; 
static constexpr int val2 = 5; 
}; 
   
const int Foo::val1 = 10;  

$ nm a.out
00013fa4 S __ZN3Foo4val1E 
0001 T __mh_execute_header
00013f90 T _main
```

LLDB can fish out the value out of `val1` by doing a `FindSymbol` on the 
mangled name. But that doesn't work with `val2` because it's not in the symbol 
table. @clayborg or @jasonmolenda probably know more about this.

Seems to me like if we want to drop the constant off of the declaration 
entirely, we need to lookup the variable definition in the accelerator table in 
DWARFASTParserClang when we're constructing the VarDecls.

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] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

[Stefan Gränitz via lldb-commits]

https://github.com/weliveindetail 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] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

[Stefan Gränitz via lldb-commits]

@@ -791,11 +791,10 @@ void ObjectFilePECOFF::AppendFromCOFFSymbolTable(
   for (const auto &sym_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 "

weliveindetail wrote:

As above

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] 43db8ac - [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (#70793)

[via lldb-commits]

Author: Stefan Gränitz
Date: 2023-11-01T12:09:12+01:00
New Revision: 43db8ac8ae56f24b5c06e9edb194fe1b7e9cbda0

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

LOG: [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF 
(#70793)

All `llvm::Error`s must be checked/consumed before destruction. Previously,
the errors in this patch were only consumed when logging was enabled.
Using `LLDB_LOG_ERROR` instead of `LLDB_LOG` fixes that, because it
calls `llvm::consumeError()` explicitly when logging is disabled.

Added: 


Modified: 
lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp
lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp

Removed: 




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 
&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 &sym_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] [lldb] [lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (PR #70793)

[Stefan Gränitz via lldb-commits]

https://github.com/weliveindetail closed 
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)

[Michael Buch via lldb-commits]

Michael137 wrote:

> 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?

That's true, if defined in a header, we'll emit a `DW_TAG_variable` for the 
constant in each compile unit the header is included in. GCC does do the right 
thing and only emit the definition DIE in a single CU. We should probably do 
the same. Though not sure at which level. Possibly the DWARF linker?

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] Read SME2's ZT0 register from Linux core files (PR #70934)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett created 
https://github.com/llvm/llvm-project/pull/70934

The ZT0 register is always 64 bytes in size so it is a lot easier to handle 
than ZA which is scalable. In addition, reading an inactive ZT0 via ptrace 
returns all 0s, unlike ZA which returns no register data.

This means that a corefile from a process where ZA and ZT0 were inactive still 
contains an NT_ARM_ZT note and we can simply say that if it's there, then we 
should be able to read from it.

Along the way I removed a redundant check on the size of the ZA note. If that 
note's size is < the ZA header size, we do not have SME, and therefore could 
not have SME2 either.

I have added ZT0 to the existing SME core files tests. This means that you need 
an SME2 system to generate them (Arm's FVP at this point). I think this is a 
fair tradeoff given that this is all running in simulation anyway and seperate 
ZT0 tests would be 99% identical copies of the ZA only tests.

>From cb4ccd594c948548d4e906391e45f65809c2f2aa Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Fri, 6 Oct 2023 17:26:44 +0100
Subject: [PATCH] [lldb][AArch64] Read SME2's ZT0 register from Linux core
 files

The ZT0 register is always 64 bytes in size so it is a lot easier
to handle than ZA which is scalable. In addition, reading an
inactive ZT0 via ptrace returns all 0s, unlike ZA which returns
no register data.

This means that a corefile from a process where ZA and ZT0 were
inactive still contains an NT_ARM_ZT note and we can simply say that
if it's there, then we should be able to read from it.

Along the way I removed a redundant check on the size of the ZA note.
If that note's size is < the ZA header size, we do not have SME,
and therefore could not have SME2 either.

I have added ZT0 to the existing SME core files tests. This means
that you need an SME2 system to generate them (Arm's FVP at this point).
I think this is a fair tradeoff given that this is all running in
simulation anyway and seperate ZT0 tests would be 99% identical
copies of the ZA only tests.
---
 .../RegisterContextPOSIXCore_arm64.cpp|  36 +++---
 .../elf-core/RegisterContextPOSIXCore_arm64.h |   1 +
 .../TestAArch64LinuxSMECoreFile.py|   5 +++
 .../aarch64/sme_core_file/core_0_16_32_1  | Bin 20480 -> 20480 bytes
 .../aarch64/sme_core_file/core_0_32_16_0  | Bin 20480 -> 20480 bytes
 .../aarch64/sme_core_file/core_1_16_32_0  | Bin 20480 -> 20480 bytes
 .../aarch64/sme_core_file/core_1_32_16_1  | Bin 20480 -> 20480 bytes
 .../linux/aarch64/sme_core_file/generate.sh   |   9 +
 .../API/linux/aarch64/sme_core_file/main.c|  29 +++---
 9 files changed, 61 insertions(+), 19 deletions(-)
 create mode 100644 lldb/test/API/linux/aarch64/sme_core_file/generate.sh

diff --git 
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
index db37b7cbb99d7e8..85073b56f64bf79 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
+++ b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
@@ -54,6 +54,13 @@ RegisterContextCorePOSIX_arm64::Create(Thread &thread, const 
ArchSpec &arch,
   if (mte_data.GetByteSize() >= sizeof(uint64_t))
 opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskMTE);
 
+  DataExtractor zt_data = getRegset(notes, arch.GetTriple(), AARCH64_ZT_Desc);
+  // Although ZT0 can be in a disabled state like ZA can, the kernel reports
+  // its content as 0s in that state. Therefore even a disabled ZT0 will have
+  // a note containing those 0s. ZT0 is a 512 bit / 64 byte register.
+  if (zt_data.GetByteSize() >= 64)
+opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskZT);
+
   auto register_info_up =
   std::make_unique(arch, opt_regsets);
   return std::unique_ptr(
@@ -98,6 +105,9 @@ 
RegisterContextCorePOSIX_arm64::RegisterContextCorePOSIX_arm64(
   if (m_register_info_up->IsMTEPresent())
 m_mte_data = getRegset(notes, target_triple, AARCH64_MTE_Desc);
 
+  if (m_register_info_up->IsZTPresent())
+m_zt_data = getRegset(notes, target_triple, AARCH64_ZT_Desc);
+
   ConfigureRegisterContext();
 }
 
@@ -298,19 +308,7 @@ bool RegisterContextCorePOSIX_arm64::ReadRegister(const 
RegisterInfo *reg_info,
 if (m_za_data.GetByteSize() < sizeof(sve::user_za_header))
   return false;
 
-if (!IsSMEZA(reg)) {
-  offset = reg_info->byte_offset - m_register_info_up->GetSMEOffset();
-  assert(offset < sizeof(m_sme_pseudo_regs));
-  // Host endian since these values are derived instead of being read from 
a
-  // core file note.
-  value.SetFromMemoryData(
-  *reg_info, reinterpret_cast(&m_sme_pseudo_regs) + offset,
-  reg_info->byte_size, lldb_private::endian::InlHostByteOrder(), 
error);
-} else {
-  // If the process did not have the SME extension.
-  if (m_za_data.GetByteSize() < sizeof(sve::user_za_header

[Lldb-commits] [lldb] [lldb][AArch64] Read SME2's ZT0 register from Linux core files (PR #70934)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)


Changes

The ZT0 register is always 64 bytes in size so it is a lot easier to handle 
than ZA which is scalable. In addition, reading an inactive ZT0 via ptrace 
returns all 0s, unlike ZA which returns no register data.

This means that a corefile from a process where ZA and ZT0 were inactive still 
contains an NT_ARM_ZT note and we can simply say that if it's there, then we 
should be able to read from it.

Along the way I removed a redundant check on the size of the ZA note. If that 
note's size is < the ZA header size, we do not have SME, and therefore could 
not have SME2 either.

I have added ZT0 to the existing SME core files tests. This means that you need 
an SME2 system to generate them (Arm's FVP at this point). I think this is a 
fair tradeoff given that this is all running in simulation anyway and seperate 
ZT0 tests would be 99% identical copies of the ZA only tests.

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


9 Files Affected:

- (modified) 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp 
(+23-13) 
- (modified) 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h (+1) 
- (modified) 
lldb/test/API/linux/aarch64/sme_core_file/TestAArch64LinuxSMECoreFile.py (+5) 
- (modified) lldb/test/API/linux/aarch64/sme_core_file/core_0_16_32_1 () 
- (modified) lldb/test/API/linux/aarch64/sme_core_file/core_0_32_16_0 () 
- (modified) lldb/test/API/linux/aarch64/sme_core_file/core_1_16_32_0 () 
- (modified) lldb/test/API/linux/aarch64/sme_core_file/core_1_32_16_1 () 
- (added) lldb/test/API/linux/aarch64/sme_core_file/generate.sh (+9) 
- (modified) lldb/test/API/linux/aarch64/sme_core_file/main.c (+23-6) 


``diff
diff --git 
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
index db37b7cbb99d7e8..85073b56f64bf79 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
+++ b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
@@ -54,6 +54,13 @@ RegisterContextCorePOSIX_arm64::Create(Thread &thread, const 
ArchSpec &arch,
   if (mte_data.GetByteSize() >= sizeof(uint64_t))
 opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskMTE);
 
+  DataExtractor zt_data = getRegset(notes, arch.GetTriple(), AARCH64_ZT_Desc);
+  // Although ZT0 can be in a disabled state like ZA can, the kernel reports
+  // its content as 0s in that state. Therefore even a disabled ZT0 will have
+  // a note containing those 0s. ZT0 is a 512 bit / 64 byte register.
+  if (zt_data.GetByteSize() >= 64)
+opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskZT);
+
   auto register_info_up =
   std::make_unique(arch, opt_regsets);
   return std::unique_ptr(
@@ -98,6 +105,9 @@ 
RegisterContextCorePOSIX_arm64::RegisterContextCorePOSIX_arm64(
   if (m_register_info_up->IsMTEPresent())
 m_mte_data = getRegset(notes, target_triple, AARCH64_MTE_Desc);
 
+  if (m_register_info_up->IsZTPresent())
+m_zt_data = getRegset(notes, target_triple, AARCH64_ZT_Desc);
+
   ConfigureRegisterContext();
 }
 
@@ -298,19 +308,7 @@ bool RegisterContextCorePOSIX_arm64::ReadRegister(const 
RegisterInfo *reg_info,
 if (m_za_data.GetByteSize() < sizeof(sve::user_za_header))
   return false;
 
-if (!IsSMEZA(reg)) {
-  offset = reg_info->byte_offset - m_register_info_up->GetSMEOffset();
-  assert(offset < sizeof(m_sme_pseudo_regs));
-  // Host endian since these values are derived instead of being read from 
a
-  // core file note.
-  value.SetFromMemoryData(
-  *reg_info, reinterpret_cast(&m_sme_pseudo_regs) + offset,
-  reg_info->byte_size, lldb_private::endian::InlHostByteOrder(), 
error);
-} else {
-  // If the process did not have the SME extension.
-  if (m_za_data.GetByteSize() < sizeof(sve::user_za_header))
-return false;
-
+if (m_register_info_up->IsSMERegZA(reg)) {
   // Don't use the size of the note to tell whether ZA is enabled. There 
may
   // be non-register padding data after the header. Use the embedded
   // header's size field instead.
@@ -339,6 +337,18 @@ bool RegisterContextCorePOSIX_arm64::ReadRegister(const 
RegisterInfo *reg_info,
   value.SetFromMemoryData(*reg_info, src + sizeof(sve::user_za_header),
   reg_info->byte_size, lldb::eByteOrderLittle,
   error);
+} else if (m_register_info_up->IsSMERegZT(reg)) {
+  value.SetFromMemoryData(*reg_info, m_zt_data.GetDataStart(),
+  reg_info->byte_size, lldb::eByteOrderLittle,
+  error);
+} else {
+  offset = reg_info->byte_offset - m_register_info_up->GetSMEOffset();
+  assert(offset < sizeof(m_sme_pseudo_regs));
+  // Host endian since these values are derived 

[Lldb-commits] [lldb] [llvm] [lldb][AArch64][Linux] Add SME2 release notes and usage docs (PR #70935)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett created 
https://github.com/llvm/llvm-project/pull/70935

ZT0 is much like ZA apart from not being scalable, so there's not much new to 
cover.

>From 6ee6e1cf98f442e82f1e4aa408ac0a2e30ac6161 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Mon, 9 Oct 2023 09:07:32 +0100
Subject: [PATCH] [lldb][AArch64][Linux] Add SME2 release notes and usage docs

ZT0 is much like ZA apart from not being scalable, so there's
not much new to cover.
---
 lldb/docs/use/aarch64-linux.rst | 41 -
 llvm/docs/ReleaseNotes.rst  |  6 ++---
 2 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/lldb/docs/use/aarch64-linux.rst b/lldb/docs/use/aarch64-linux.rst
index fcd0d1b805bf7df..c790d9d369a4805 100644
--- a/lldb/docs/use/aarch64-linux.rst
+++ b/lldb/docs/use/aarch64-linux.rst
@@ -194,9 +194,48 @@ instrucion could interpret its contents as many kinds and 
sizes of data.
 So LLDB will default to showing  ``za`` as one large vector of individual 
bytes.
 You can override this with a format option (see the SVE example above).
 
-Expression evaluation
+Expression Evaluation
 .
 
 The mode (streaming or non-streaming), streaming vector length and ZA state 
will
 be restored after expression evaluation. On top of all the things saved for SVE
 in general.
+
+Scalable Matrix Extension (SME2)
+
+
+The Scalable Matrix Extension 2 is documented in the same architecture
+specification as SME, and covered by the same kernel documentation page as SME.
+
+SME2 adds 1 new register, ``zt0``. This register is a fixed size 512 bit
+register that is used by new instructions added in SME2. It is shown in LLDB in
+the existing SME register set.
+
+``zt0`` can be active or inactive, as ``za`` can. The same ``SVCR.ZA`` bit
+controls this. An inactive ``zt0`` is shown as 0s, like ``za`` is. Though in
+``zt0``'s case, LLDB does not need to fake the value. Ptrace already returns a
+block of 0s for an inactive ``zt0``.
+
+Like ``za``, writing to an inactive ``zt0`` will enable it and ``za``. This can
+be done from within LLDB. If the write is instead to ``za``, ``zt0`` becomes
+active but with a value of all 0s.
+
+Since ``svcr`` is read only, there is no way at this time to deactivate the
+registers from within LLDB (though of course a running process can still do
+this).
+
+To check whether ``zt0`` is active, refer to ``SVCR.ZA`` and not to the value 
of
+``zt0``.
+
+ZT0 Register Presentation
+.
+
+As for ``za``, the meaning of ``zt0`` depends on the instructions used with it,
+so LLDB does not attempt to guess this and defaults to showing it as a vector 
of
+bytes.
+
+Expression Evaluation
+.
+
+``zt0``'s value and whether it is active or not will be saved prior to
+expression evaluation and restored afterwards.
\ No newline at end of file
diff --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst
index 25817e6e1d7f413..6c7e60fbe8cdf92 100644
--- a/llvm/docs/ReleaseNotes.rst
+++ b/llvm/docs/ReleaseNotes.rst
@@ -216,9 +216,9 @@ Changes to LLDB
   instructions have been updated to reflect this. The underlying functionality
   remains unchanged.
 * The ``mte_ctrl`` register can now be read from AArch64 Linux core files.
-
-* LLDB now supports debugging the Scalable Matrix Extension (SME) on AArch64
-  Linux for both running processes and core files. For details refer to the
+* LLDB on AArch64 Linux now supports debugging the Scalable Matrix Extension
+  (SME) and Scalable Matrix Extension 2 (SME2) for both live processes and core
+  files. For details refer to the
   `AArch64 Linux documentation 
`_.
 
 Changes to Sanitizers

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

[Lldb-commits] [llvm] [lldb] [lldb][AArch64][Linux] Add SME2 release notes and usage docs (PR #70935)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)


Changes

ZT0 is much like ZA apart from not being scalable, so there's not much new to 
cover.

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


2 Files Affected:

- (modified) lldb/docs/use/aarch64-linux.rst (+40-1) 
- (modified) llvm/docs/ReleaseNotes.rst (+3-3) 


``diff
diff --git a/lldb/docs/use/aarch64-linux.rst b/lldb/docs/use/aarch64-linux.rst
index fcd0d1b805bf7df..c790d9d369a4805 100644
--- a/lldb/docs/use/aarch64-linux.rst
+++ b/lldb/docs/use/aarch64-linux.rst
@@ -194,9 +194,48 @@ instrucion could interpret its contents as many kinds and 
sizes of data.
 So LLDB will default to showing  ``za`` as one large vector of individual 
bytes.
 You can override this with a format option (see the SVE example above).
 
-Expression evaluation
+Expression Evaluation
 .
 
 The mode (streaming or non-streaming), streaming vector length and ZA state 
will
 be restored after expression evaluation. On top of all the things saved for SVE
 in general.
+
+Scalable Matrix Extension (SME2)
+
+
+The Scalable Matrix Extension 2 is documented in the same architecture
+specification as SME, and covered by the same kernel documentation page as SME.
+
+SME2 adds 1 new register, ``zt0``. This register is a fixed size 512 bit
+register that is used by new instructions added in SME2. It is shown in LLDB in
+the existing SME register set.
+
+``zt0`` can be active or inactive, as ``za`` can. The same ``SVCR.ZA`` bit
+controls this. An inactive ``zt0`` is shown as 0s, like ``za`` is. Though in
+``zt0``'s case, LLDB does not need to fake the value. Ptrace already returns a
+block of 0s for an inactive ``zt0``.
+
+Like ``za``, writing to an inactive ``zt0`` will enable it and ``za``. This can
+be done from within LLDB. If the write is instead to ``za``, ``zt0`` becomes
+active but with a value of all 0s.
+
+Since ``svcr`` is read only, there is no way at this time to deactivate the
+registers from within LLDB (though of course a running process can still do
+this).
+
+To check whether ``zt0`` is active, refer to ``SVCR.ZA`` and not to the value 
of
+``zt0``.
+
+ZT0 Register Presentation
+.
+
+As for ``za``, the meaning of ``zt0`` depends on the instructions used with it,
+so LLDB does not attempt to guess this and defaults to showing it as a vector 
of
+bytes.
+
+Expression Evaluation
+.
+
+``zt0``'s value and whether it is active or not will be saved prior to
+expression evaluation and restored afterwards.
\ No newline at end of file
diff --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst
index 25817e6e1d7f413..6c7e60fbe8cdf92 100644
--- a/llvm/docs/ReleaseNotes.rst
+++ b/llvm/docs/ReleaseNotes.rst
@@ -216,9 +216,9 @@ Changes to LLDB
   instructions have been updated to reflect this. The underlying functionality
   remains unchanged.
 * The ``mte_ctrl`` register can now be read from AArch64 Linux core files.
-
-* LLDB now supports debugging the Scalable Matrix Extension (SME) on AArch64
-  Linux for both running processes and core files. For details refer to the
+* LLDB on AArch64 Linux now supports debugging the Scalable Matrix Extension
+  (SME) and Scalable Matrix Extension 2 (SME2) for both live processes and core
+  files. For details refer to the
   `AArch64 Linux documentation 
`_.
 
 Changes to Sanitizers

``




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

[Lldb-commits] [lldb] 6576120 - [clang][NFC] Refactor `LinkageSpecDecl::LanguageIDs`

[Vlad Serebrennikov via lldb-commits]

Author: Vlad Serebrennikov
Date: 2023-11-01T16:44:34+03:00
New Revision: 65761200ce4e1f366e8418652efdafd2f744291b

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

LOG: [clang][NFC] Refactor `LinkageSpecDecl::LanguageIDs`

This patch converts `LinkageSpecDecl::LanguageIDs` into scoped enum, and moves 
it to namespace scope, so that it can be forward-declared where required.

Added: 


Modified: 
clang/include/clang/AST/DeclBase.h
clang/include/clang/AST/DeclCXX.h
clang/lib/AST/DeclBase.cpp
clang/lib/AST/DeclCXX.cpp
clang/lib/AST/DeclPrinter.cpp
clang/lib/AST/JSONNodeDumper.cpp
clang/lib/AST/TextNodeDumper.cpp
clang/lib/CodeGen/CodeGenModule.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclCXX.cpp
clang/lib/Sema/SemaModule.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
clang/lib/Serialization/ASTWriterDecl.cpp
lldb/source/Plugins/ExpressionParser/Clang/NameSearchContext.cpp

Removed: 




diff  --git a/clang/include/clang/AST/DeclBase.h 
b/clang/include/clang/AST/DeclBase.h
index 6f2c5b96554a9d1..32b6aed6397668c 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -1430,6 +1430,8 @@ enum class OMPDeclareReductionInitKind {
 
 enum class ObjCImplementationControl { None, Required, Optional };
 
+enum class LinkageSpecLanguageIDs;
+
 /// DeclContext - This is used only as base class of specific decl types that
 /// can act as declaration contexts. These decls are (only the top classes
 /// that directly derive from DeclContext are mentioned, not their subclasses):

diff  --git a/clang/include/clang/AST/DeclCXX.h 
b/clang/include/clang/AST/DeclCXX.h
index 5eaae6bdd2bc63e..df1dc5a401f39a5 100644
--- a/clang/include/clang/AST/DeclCXX.h
+++ b/clang/include/clang/AST/DeclCXX.h
@@ -2897,6 +2897,12 @@ class CXXConversionDecl : public CXXMethodDecl {
   static bool classofKind(Kind K) { return K == CXXConversion; }
 };
 
+/// Represents the language in a linkage specification.
+///
+/// The values are part of the serialization ABI for
+/// ASTs and cannot be changed without altering that ABI.
+enum class LinkageSpecLanguageIDs { C = 1, CXX = 2 };
+
 /// Represents a linkage specification.
 ///
 /// For example:
@@ -2907,14 +2913,7 @@ class LinkageSpecDecl : public Decl, public DeclContext {
   virtual void anchor();
   // This class stores some data in DeclContext::LinkageSpecDeclBits to save
   // some space. Use the provided accessors to access it.
-public:
-  /// Represents the language in a linkage specification.
-  ///
-  /// The values are part of the serialization ABI for
-  /// ASTs and cannot be changed without altering that ABI.
-  enum LanguageIDs { lang_c = 1, lang_cxx = 2 };
 
-private:
   /// The source location for the extern keyword.
   SourceLocation ExternLoc;
 
@@ -2922,22 +2921,25 @@ class LinkageSpecDecl : public Decl, public DeclContext 
{
   SourceLocation RBraceLoc;
 
   LinkageSpecDecl(DeclContext *DC, SourceLocation ExternLoc,
-  SourceLocation LangLoc, LanguageIDs lang, bool HasBraces);
+  SourceLocation LangLoc, LinkageSpecLanguageIDs lang,
+  bool HasBraces);
 
 public:
   static LinkageSpecDecl *Create(ASTContext &C, DeclContext *DC,
  SourceLocation ExternLoc,
- SourceLocation LangLoc, LanguageIDs Lang,
- bool HasBraces);
+ SourceLocation LangLoc,
+ LinkageSpecLanguageIDs Lang, bool HasBraces);
   static LinkageSpecDecl *CreateDeserialized(ASTContext &C, unsigned ID);
 
   /// Return the language specified by this linkage specification.
-  LanguageIDs getLanguage() const {
-return static_cast(LinkageSpecDeclBits.Language);
+  LinkageSpecLanguageIDs getLanguage() const {
+return static_cast(LinkageSpecDeclBits.Language);
   }
 
   /// Set the language specified by this linkage specification.
-  void setLanguage(LanguageIDs L) { LinkageSpecDeclBits.Language = L; }
+  void setLanguage(LinkageSpecLanguageIDs L) {
+LinkageSpecDeclBits.Language = llvm::to_underlying(L);
+  }
 
   /// Determines whether this linkage specification had braces in
   /// its syntactic form.

diff  --git a/clang/lib/AST/DeclBase.cpp b/clang/lib/AST/DeclBase.cpp
index a3847a73faf8183..3fd4751d6d1f31d 100644
--- a/clang/lib/AST/DeclBase.cpp
+++ b/clang/lib/AST/DeclBase.cpp
@@ -1320,7 +1320,7 @@ bool DeclContext::isTransparentContext() const {
 }
 
 static bool isLinkageSpecContext(const DeclContext *DC,
- LinkageSpecDecl::LanguageIDs ID) {
+ LinkageSpecLanguageIDs ID) {
   while (DC->getDeclKind() != Decl::Translati

[Lldb-commits] [lld] [clang] [lldb] [llvm] [Clang] Defer the instantiation of explicit-specifier until constraint checking completes (PR #70548)

[Erich Keane via lldb-commits]

https://github.com/erichkeane updated 
https://github.com/llvm/llvm-project/pull/70548

>From 11ceaed39b3f0c60c5a44c3b3a2b5856e7ee9a8d Mon Sep 17 00:00:00 2001
From: letrec 
Date: Sat, 28 Oct 2023 18:05:36 +0800
Subject: [PATCH 1/7] Defer the instantiation of explicit-specifier after
 constraint checking

---
 clang/docs/ReleaseNotes.rst   |  4 ++
 clang/include/clang/Sema/Sema.h   |  3 +
 clang/lib/Sema/SemaTemplateDeduction.cpp  | 59 +++
 .../lib/Sema/SemaTemplateInstantiateDecl.cpp  | 40 -
 .../SemaCXX/cxx2a-explicit-bool-deferred.cpp  | 31 ++
 5 files changed, 123 insertions(+), 14 deletions(-)
 create mode 100644 clang/test/SemaCXX/cxx2a-explicit-bool-deferred.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index bc28bb567f6932a..d9980694de40f6f 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -670,6 +670,10 @@ Bug Fixes to C++ Support
   default initializing a base class in a constant expression context. Fixes:
   (`#69890 `_)
 
+- Clang now defers the instantiation of explicit specifier until constraint 
checking
+  completes (except deduction guides). Fixes:
+  (`#59827 `_)
+
 Bug Fixes to AST Handling
 ^
 - Fixed an import failure of recursive friend class template.
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 91a4211a5cf5cce..daed24be0a86d11 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -10430,6 +10430,9 @@ class Sema final {
   const CXXConstructorDecl *Tmpl,
 const MultiLevelTemplateArgumentList 
&TemplateArgs);
 
+  ExplicitSpecifier instantiateExplicitSpecifier(
+  const MultiLevelTemplateArgumentList &TemplateArgs, ExplicitSpecifier 
ES);
+
   NamedDecl *FindInstantiatedDecl(SourceLocation Loc, NamedDecl *D,
   const MultiLevelTemplateArgumentList &TemplateArgs,
   bool FindingInstantiatedContext = false);
diff --git a/clang/lib/Sema/SemaTemplateDeduction.cpp 
b/clang/lib/Sema/SemaTemplateDeduction.cpp
index 0b3f0247ea3bee3..f06332770f51d1f 100644
--- a/clang/lib/Sema/SemaTemplateDeduction.cpp
+++ b/clang/lib/Sema/SemaTemplateDeduction.cpp
@@ -3553,6 +3553,56 @@ static unsigned getPackIndexForParam(Sema &S,
   llvm_unreachable("parameter index would not be produced from template");
 }
 
+// if `Specialization` is a `CXXConstructorDecl` or `CXXConversionDecl`
+// we try to instantiate and update its explicit specifier after constraint
+// checking.
+static Sema::TemplateDeductionResult
+tryInstantiateExplicitSpecifier(Sema &S, FunctionDecl *Specialization,
+const MultiLevelTemplateArgumentList 
&SubstArgs,
+TemplateDeductionInfo &Info,
+FunctionTemplateDecl *FunctionTemplate,
+ArrayRef DeducedArgs) {
+
+  const auto TryInstantiateExplicitSpecifierForSingleDecl =
+  [&](auto *ExplicitDecl) {
+ExplicitSpecifier ExplicitSpecifier =
+ExplicitDecl->getExplicitSpecifier();
+Expr *const Expr = ExplicitSpecifier.getExpr();
+if (!Expr) {
+  return Sema::TDK_Success;
+}
+if (!Expr->isValueDependent()) {
+  return Sema::TDK_Success;
+}
+// TemplateDeclInstantiator::InitFunctionInstantiation set the
+// ActiveInstType to TemplateInstantiation, but we need
+// to enable SFINAE when instantiating explicit specifier.
+Sema::InstantiatingTemplate Inst(
+S, Info.getLocation(), FunctionTemplate, DeducedArgs,
+Sema::CodeSynthesisContext::DeducedTemplateArgumentSubstitution,
+Info);
+const auto Instantiated =
+S.instantiateExplicitSpecifier(SubstArgs, ExplicitSpecifier);
+if (Instantiated.isInvalid()) {
+  ExplicitDecl->setInvalidDecl(true);
+  return clang::Sema::TDK_SubstitutionFailure;
+}
+ExplicitDecl->setExplicitSpecifier(Instantiated);
+return clang::Sema::TDK_Success;
+  };
+  Sema::TemplateDeductionResult DeductionResult = clang::Sema::TDK_Success;
+  if (CXXConstructorDecl *ConstructorDecl =
+  dyn_cast_or_null(Specialization)) {
+DeductionResult =
+TryInstantiateExplicitSpecifierForSingleDecl(ConstructorDecl);
+  } else if (CXXConversionDecl *ConversionDecl =
+ dyn_cast_or_null(Specialization)) {
+DeductionResult =
+TryInstantiateExplicitSpecifierForSingleDecl(ConversionDecl);
+  }
+  return DeductionResult;
+}
+
 /// Finish template argument deduction for a function template,
 /// checking the deduced template arguments for completeness and forming
 /// the function template sp

[Lldb-commits] [lld] [clang] [lldb] [llvm] [Clang] Defer the instantiation of explicit-specifier until constraint checking completes (PR #70548)

[Erich Keane via lldb-commits]

https://github.com/erichkeane closed 
https://github.com/llvm/llvm-project/pull/70548
___
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)

[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/8] [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 &Init) {
   TemplateParameters, Align));
 }
 
+void CGDebugInfo::EmitGlobalVariable(const VarDecl *VD) {
+  assert(VD->hasInit());
+  assert(CGM.getCodeGenOpts().hasReducedDebugInfo());
+  if (VD->hasAttr())
+return;
+
+  auto &GV = 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][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett created 
https://github.com/llvm/llvm-project/pull/70950

This removes AArch64 specific code from the GDB* classes.

To do this I've added 2 new methods to Architecture:
* RegisterWriteCausesReconfigure to check if what you are about to do
  will trash the register info.
* ReconfigureRegisterInfo to do the reconfiguring. This tells you if
  anything changed so that we only invalidate registers when needed.

So that ProcessGDBRemote can call ReconfigureRegisterInfo in SetThreadStopInfo,
I've added forwarding calls to GDBRemoteRegisterContext and the base class
RegisterContext.

(which removes a slightly sketchy static cast as well)

RegisterContext defaults to doing nothing for both the methods
so anything other than GDBRemoteRegisterContext will do nothing.

>From f5c0e05769e4f9093d4477bec39c19afd0415604 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Tue, 31 Oct 2023 14:11:47 +
Subject: [PATCH 1/2] [lldb][AArch64] Simplify handing of scalable registers
 using vg and svg

This removes explicit invalidation of vg and svg that was done in
`GDBRemoteRegisterContext::AArch64Reconfigure`. This was in fact
covering up a bug elsehwere.

Register information says that a write to vg also invalidates svg
(it does not unless you are in streaming mode, but we decided to
keep it simple and say it always does).

This invalidation was not being applied until *after* AArch64Reconfigure
was called. This meant that without those manual invalidates this
happened:
* vg is written
* svg is not invalidated
* Reconfigure uses the written vg value
* Reconfigure uses the *old* svg value

I have moved the AArch64Reconfigure call to after we've processed
the invalidations caused by the register write, so we no longer
need the manual invalidates in AArch64Reconfigure.

In addition I have changed the order in which expedited registers
as parsed. These registers come with a stop notification and include,
amongst others, vg and svg.

So now we:
* Parse them and update register values (including vg and svg)
* AArch64Reconfigure, which uses those values, and invalidates every
  register, because offsets may have changed.
* Parse the expedited registers again, knowing that none of the
  values will have changed due to the scaling.

This means we use the expedited registers during the reconfigure,
but the invalidate does not mean we throw all of them away.

The cost is we parse them twice client side, but this is cheap
compared to a network packet, and is limited to AArch64 targets
only.

On a system with SVE and SME, these are the packets sent for a step:
```
(lldb) b-remote.async>  < 803> read packet:
$T05thread:p1f80.1f80;name:main.o;threads:1f80;thread-pcs:0040056c<...>a1:0800;d9:0400;reason:trace;#fc
intern-state <  21> send packet: $xf200,200#5e
intern-state < 516> read packet:
$e4f200<...>#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",<...>}],"signal":5,"tid":8064}]]#73
```

You can see there are no extra register reads which means we're using
the expedited registers.

For a write to vg:
```
(lldb) register write vg 4
lldb <  37> send packet:
$Pa1=0400;thread:1f80;#4a
lldb <   6> read packet: $OK#9a
lldb <  20> send packet: $pa1;thread:1f80;#29
lldb <  20> read packet: $0400#04
lldb <  20> send packet: $pd9;thread:1f80;#34
lldb <  20> read packet: $0400#04
```

There is the initial P write, and lldb correctly assumes that SVG is
invalidated by this also so we read back the new vg and svg values
afterwards.
---
 .../gdb-remote/GDBRemoteRegisterContext.cpp   | 17 ++
 .../Process/gdb-remote/ProcessGDBRemote.cpp   | 55 +--
 .../Process/gdb-remote/ProcessGDBRemote.h |  3 +
 3 files changed, 45 insertions(+), 30 deletions(-)

diff --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
index 72280927471f883..013b2bbc0e67f27 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -434,11 +434,6 @@ bool GDBRemoteRegisterContext::WriteRegisterBytes(const 
RegisterInfo *reg_info,
 } else {
   // This is an actual register, write it
   success = SetPrimordialRegister(reg_info, gdb_comm);
-
-  if (success && do_reconfigure_arm64_sve) {
-AArch64Reconfigure();
-InvalidateAllRegisters();
-  }
 }
 
 // Check if writing this register will invalidate any other register
@@ -452,6 +447,11 @@ bool GDBRemoteRegisterContext::WriteRegisterByte

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[David Spickett via lldb-commits]

DavidSpickett wrote:

The first commit here is actually 
https://github.com/llvm/llvm-project/pull/70914, so review the second one (or 
wait until the first lands and I'll rebase this).

This is to answer @medismailben 's question about why GDB classes had AArch64 
specific code in them. They don't need to with this change.

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

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)


Changes

This removes AArch64 specific code from the GDB* classes.

To do this I've added 2 new methods to Architecture:
* RegisterWriteCausesReconfigure to check if what you are about to do
  will trash the register info.
* ReconfigureRegisterInfo to do the reconfiguring. This tells you if
  anything changed so that we only invalidate registers when needed.

So that ProcessGDBRemote can call ReconfigureRegisterInfo in SetThreadStopInfo,
I've added forwarding calls to GDBRemoteRegisterContext and the base class
RegisterContext.

(which removes a slightly sketchy static cast as well)

RegisterContext defaults to doing nothing for both the methods
so anything other than GDBRemoteRegisterContext will do nothing.

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


9 Files Affected:

- (modified) lldb/include/lldb/Core/Architecture.h (+19) 
- (modified) lldb/include/lldb/Target/DynamicRegisterInfo.h (+4) 
- (modified) lldb/include/lldb/Target/RegisterContext.h (+6) 
- (modified) lldb/source/Plugins/Architecture/AArch64/ArchitectureAArch64.cpp 
(+91) 
- (modified) lldb/source/Plugins/Architecture/AArch64/ArchitectureAArch64.h 
(+10) 
- (modified) 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp (+30-96) 
- (modified) lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h 
(+3-2) 
- (modified) lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
(+27-21) 
- (modified) lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h (+3) 


``diff
diff --git a/lldb/include/lldb/Core/Architecture.h 
b/lldb/include/lldb/Core/Architecture.h
index b68bf27ae0df888..d5294197fd119ba 100644
--- a/lldb/include/lldb/Core/Architecture.h
+++ b/lldb/include/lldb/Core/Architecture.h
@@ -10,6 +10,7 @@
 #define LLDB_CORE_ARCHITECTURE_H
 
 #include "lldb/Core/PluginInterface.h"
+#include "lldb/Target/DynamicRegisterInfo.h"
 #include "lldb/Target/MemoryTagManager.h"
 
 namespace lldb_private {
@@ -109,6 +110,24 @@ class Architecture : public PluginInterface {
   virtual const MemoryTagManager *GetMemoryTagManager() const {
 return nullptr;
   }
+
+  // This returns true if a write to the named register should cause lldb to
+  // reconfigure its register information. For example on AArch64 writing to vg
+  // to change the vector length means lldb has to change the size of 
registers.
+  virtual bool RegisterWriteCausesReconfigure(const char *name) const {
+return false;
+  }
+
+  // Call this after writing a register for which 
RegisterWriteCausesReconfigure
+  // returns true. This method will update the layout of registers according to
+  // the new state e.g. the new length of scalable vector registers.
+  // Returns true if anything changed, which means existing register values 
must
+  // be invalidated.
+  virtual bool ReconfigureRegisterInfo(DynamicRegisterInfo ®_info,
+   DataExtractor ®_data,
+   RegisterContext ®_context) const {
+return false;
+  }
 };
 
 } // namespace lldb_private
diff --git a/lldb/include/lldb/Target/DynamicRegisterInfo.h 
b/lldb/include/lldb/Target/DynamicRegisterInfo.h
index fb22885e713d672..0e175a99eb7d58a 100644
--- a/lldb/include/lldb/Target/DynamicRegisterInfo.h
+++ b/lldb/include/lldb/Target/DynamicRegisterInfo.h
@@ -93,6 +93,10 @@ class DynamicRegisterInfo {
 return llvm::iterator_range(m_regs);
   }
 
+  llvm::iterator_range registers_mutable() {
+return llvm::iterator_range(m_regs);
+  }
+
   void ConfigureOffsets();
 
 protected:
diff --git a/lldb/include/lldb/Target/RegisterContext.h 
b/lldb/include/lldb/Target/RegisterContext.h
index 893569a98dbd8b3..921c25d215ade23 100644
--- a/lldb/include/lldb/Target/RegisterContext.h
+++ b/lldb/include/lldb/Target/RegisterContext.h
@@ -51,6 +51,12 @@ class RegisterContext : public 
std::enable_shared_from_this,
 return false;
   }
 
+  virtual bool RegisterWriteCausesReconfigure(const char *name) {
+return false;
+  }
+
+  virtual bool ReconfigureRegisterInfo() { return false; }
+
   // These two functions are used to implement "push" and "pop" of register
   // states.  They are used primarily for expression evaluation, where we need
   // to push a new state (storing the old one in data_sp) and then restoring
diff --git a/lldb/source/Plugins/Architecture/AArch64/ArchitectureAArch64.cpp 
b/lldb/source/Plugins/Architecture/AArch64/ArchitectureAArch64.cpp
index 1b2b41ee8758758..2954eaa2083af08 100644
--- a/lldb/source/Plugins/Architecture/AArch64/ArchitectureAArch64.cpp
+++ b/lldb/source/Plugins/Architecture/AArch64/ArchitectureAArch64.cpp
@@ -8,7 +8,10 @@
 
 #include "Plugins/Architecture/AArch64/ArchitectureAArch64.h"
 #include "lldb/Core/PluginManager.h"
+#include "lldb/Target/RegisterContext.h"
 #include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/DataBufferHeap.h"
+#include "lldb/Utility/DataExtract

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[David Spickett via lldb-commits]

DavidSpickett wrote:

Tested on AArch64 Linux without SVE, and on a Graviton 3 with SVE. Which also 
survived repeatedly running the SVE dynamic resize test. Which it should, 
nothing is changing here apart from the layout of the source code.

https://github.com/llvm/llvm-project/pull/70950
___
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)

[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 &arch = GetTarget().GetArchitecture();
+  if (arch.IsValid() && arch.GetTriple().isAArch64()) {

DavidSpickett wrote:

https://github.com/llvm/llvm-project/pull/70950

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] Add the ability to get a C++ vtable ValueObject from another ValueObj… (PR #67599)

[Daniel Chen via lldb-commits]

DanielCChen wrote:

Sorry about the noise. All the reverts are in a private branch on my fork repo. 
I didn't know it would broadcast to all the people who worked on the reverted 
commits. My apologies.

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] [PATCH] D140996: [c++20] P1907R1: Support for generalized non-type template arguments of scalar type.

[Aaron Ballman via Phabricator via lldb-commits]

aaron.ballman added a comment.

In D140996#4655288 , @bolshakov-a 
wrote:

> Sorry, but I don't know what remains to be done here. It seems that the only 
> important question is about ABI, but I've already answered that the changes 
> under discussion seem to be already fixed in the Itanium ABI document.

Oh gosh, this must have fallen through the cracks then -- I thought it was 
waiting on further changes, so I hadn't been re-reviewing it. I'm sorry about 
that! Let's get this ball rolling again to try to get this landed. CC 
@erichkeane (who may not be available for the next while due to WG21 meetings, 
FYI).




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2205-2206
   "bit-field%select{| %1}2">;
+def err_reference_bind_to_bitfield_in_cce : Error<
+  "reference cannot bind to bit-field in converted constant expression">;
 def err_reference_bind_to_vector_element : Error<

This change seems somewhat orthogonal to the rest of the patch; should this be 
split out? Also, there doesn't appear to be test coverage for the new 
diagnostic.



Comment at: clang/lib/AST/ItaniumMangle.cpp:4397
+// argument.
+// As proposed in https://github.com/itanium-cxx-abi/cxx-abi/issues/111.
+auto *SNTTPE = cast(E);

bolshakov-a wrote:
> bolshakov-a wrote:
> > efriedma wrote:
> > > bolshakov-a wrote:
> > > > erichkeane wrote:
> > > > > erichkeane wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > We should get this nailed down. It was proposed in Nov 2020 and 
> > > > > > > the issue is still open. CC @rjmccall 
> > > > > > This definitely needs to happen.  @rjmccall or @eli.friedman ^^ Any 
> > > > > > idea what the actual mangling should be?
> > > > > This is still an open, and we need @rjmccall @eli.friedman or @asl to 
> > > > > help out here.
> > > > Ping @efriedma, @rjmccall, @asl.
> > > I'm not really familiar with the mangling implications for this 
> > > particular construct, nor am I actively involved with the Itanium ABI 
> > > specification, so I'm not sure how I can help you directly.
> > > 
> > > That said, as a general opinion, I don't think it's worth waiting for 
> > > updates to the Itanuim ABI  document to be merged; such updates are 
> > > happening slowly at the moment, and having a consistent mangling is 
> > > clearly an improvement even if it's not specified.  My suggested plan of 
> > > action:
> > > 
> > > - Make sure you're satisfied the proposed mangling doesn't have any holes 
> > > you're concerned about (i.e. it produces a unique mangling for all the 
> > > relevant cases).  If you're not sure, I can try to spend some time 
> > > understanding this, but it doesn't sound like you have any concerns about 
> > > this.
> > > - Put a note on the issue in the Itanium ABI repo that you're planning to 
> > > go ahead with using this mangling in clang.  Also send an email directly 
> > > to @rjmccall and @rsmith in case they miss the notifications.
> > > - Go ahead with this.
> > > Put a note on the issue in the Itanium ABI repo that you're planning to 
> > > go ahead with using this mangling in clang. Also send an email directly 
> > > to @rjmccall and @rsmith in case they miss the notifications.
> > 
> > I'm sorry for noting one more time that Richard already pushed these 
> > changes in clang upstream, but they had been just reverted.
> > 
> > Maybe, I should make a PR into Itanium API repository, but I probably need 
> > some time to dig into the theory and all the discussions. But yes, even 
> > NTTP argument mangling rules are not still merged: 
> > https://github.com/itanium-cxx-abi/cxx-abi/pull/140
> @aaron.ballman, @erichkeane, seems like it is already fixed in the ABI 
> document:
> > Typically, only references to function template parameters occurring within 
> > the dependent signature of the template are mangled this way. In other 
> > contexts, template instantiation replaces references to template parameters 
> > with the actual template arguments, and mangling should mangle such 
> > references exactly as if they were that template argument.
> 
> https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.template-param
> 
> See also [the discussion in the 
> issue](https://github.com/itanium-cxx-abi/cxx-abi/issues/111#issuecomment-1567486892).
Okay, I think I agree that this is already addressed in the ABI document. I 
think we can drop the comment referencing the ABI issue, wdyt?



Comment at: clang/lib/AST/TemplateBase.cpp:408-409
   case Integral:
-getAsIntegral().Profile(ID);
 getIntegralType().Profile(ID);
+getAsIntegral().Profile(ID);
+break;

bolshakov-a wrote:
> aaron.ballman wrote:
> > Why did the order of these calls change?
> I don't know, it is from 9e08e51a20d0d2. I've tried to invert the order along 
> with the order for `StructuralValue`, and all tests have been passed.
I don't think the ord

[Lldb-commits] [clang] [lldb] [clang][NFC] Rename ArgPassingKind to RecordArgPassingKind (PR #70955)

[Vlad Serebrennikov via lldb-commits]

https://github.com/Endilll created 
https://github.com/llvm/llvm-project/pull/70955

During the recent refactoring (b120fe8d3288c4dca1b5427ca34839ce8833f71c) this 
enum was moved out of `RecordDecl`. During post-commit review it was found out 
that its association with `RecordDecl` should be expressed in the name.

I'm planning to land this as soon as CI passes, probably without waiting for 
Windows bot.

>From 99013f89d8a5d62828e351e49a11d04fe13645ae Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Wed, 1 Nov 2023 19:24:22 +0300
Subject: [PATCH] [clang][NFC] Rename ArgPassingKind to RecordArgPassingKind

During the recent refactoring (b120fe8d3288c4dca1b5427ca34839ce8833f71c) this 
enum was moved out of `RecordDecl`. During post-commit review it was found out 
that its association with `RecordDecl` should be expresses in the name.
---
 clang/include/clang/AST/Decl.h| 11 ++-
 clang/include/clang/AST/DeclBase.h|  2 +-
 clang/lib/AST/Decl.cpp|  2 +-
 clang/lib/AST/DeclCXX.cpp | 10 +-
 clang/lib/CodeGen/CGCall.cpp  |  3 ++-
 clang/lib/Sema/SemaDecl.cpp   |  8 +---
 clang/lib/Sema/SemaDeclCXX.cpp|  9 +
 clang/lib/Serialization/ASTReaderDecl.cpp |  4 ++--
 .../Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp  |  2 +-
 9 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index d9b00b1628ab25c..d8ea8c1dfb4f292 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -4063,7 +4063,7 @@ class EnumDecl : public TagDecl {
 /// returned from function calls. This takes into account the target-specific
 /// and version-specific rules along with the rules determined by the
 /// language.
-enum class ArgPassingKind {
+enum class RecordArgPassingKind {
   /// The argument of this type can be passed directly in registers.
   CanPassInRegs,
 
@@ -4216,14 +4216,15 @@ class RecordDecl : public TagDecl {
   /// it must have at least one trivial, non-deleted copy or move constructor.
   /// FIXME: This should be set as part of completeDefinition.
   bool canPassInRegisters() const {
-return getArgPassingRestrictions() == ArgPassingKind::CanPassInRegs;
+return getArgPassingRestrictions() == RecordArgPassingKind::CanPassInRegs;
   }
 
-  ArgPassingKind getArgPassingRestrictions() const {
-return static_cast(RecordDeclBits.ArgPassingRestrictions);
+  RecordArgPassingKind getArgPassingRestrictions() const {
+return static_cast(
+RecordDeclBits.ArgPassingRestrictions);
   }
 
-  void setArgPassingRestrictions(ArgPassingKind Kind) {
+  void setArgPassingRestrictions(RecordArgPassingKind Kind) {
 RecordDeclBits.ArgPassingRestrictions = llvm::to_underlying(Kind);
   }
 
diff --git a/clang/include/clang/AST/DeclBase.h 
b/clang/include/clang/AST/DeclBase.h
index 6704c0cd41ecd3d..df1d6e8a3b5af72 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -1399,7 +1399,7 @@ enum class DeductionCandidate : unsigned char {
   Aggregate,
 };
 
-enum class ArgPassingKind;
+enum class RecordArgPassingKind;
 enum class OMPDeclareReductionInitKind;
 enum class ObjCImplementationControl;
 enum class LinkageSpecLanguageIDs;
diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 28243a76712d63e..6efc177d61c03ba 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -4932,7 +4932,7 @@ RecordDecl::RecordDecl(Kind DK, TagKind TK, const 
ASTContext &C,
   setHasNonTrivialToPrimitiveDestructCUnion(false);
   setHasNonTrivialToPrimitiveCopyCUnion(false);
   setParamDestroyedInCallee(false);
-  setArgPassingRestrictions(ArgPassingKind::CanPassInRegs);
+  setArgPassingRestrictions(RecordArgPassingKind::CanPassInRegs);
   setIsRandomized(false);
   setODRHash(0);
 }
diff --git a/clang/lib/AST/DeclCXX.cpp b/clang/lib/AST/DeclCXX.cpp
index 066b62b7c24110d..4002c63e9f94c12 100644
--- a/clang/lib/AST/DeclCXX.cpp
+++ b/clang/lib/AST/DeclCXX.cpp
@@ -446,8 +446,8 @@ CXXRecordDecl::setBases(CXXBaseSpecifier const * const 
*Bases,
   setHasVolatileMember(true);
 
 if (BaseClassDecl->getArgPassingRestrictions() ==
-ArgPassingKind::CanNeverPassInRegs)
-  setArgPassingRestrictions(ArgPassingKind::CanNeverPassInRegs);
+RecordArgPassingKind::CanNeverPassInRegs)
+  setArgPassingRestrictions(RecordArgPassingKind::CanNeverPassInRegs);
 
 // Keep track of the presence of mutable fields.
 if (BaseClassDecl->hasMutableFields())
@@ -1032,7 +1032,7 @@ void CXXRecordDecl::addedMember(Decl *D) {
 
 // Structs with __weak fields should never be passed directly.
 if (LT == Qualifiers::OCL_Weak)
-  setArgPassingRestrictions(ArgPassingKind::CanNeverPassInRegs);
+  setArgPassingRestrictions(RecordArgPassingKind:

[Lldb-commits] [clang] [lldb] [clang][NFC] Rename ArgPassingKind to RecordArgPassingKind (PR #70955)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Vlad Serebrennikov (Endilll)


Changes

During the recent refactoring (b120fe8d3288c4dca1b5427ca34839ce8833f71c) this 
enum was moved out of `RecordDecl`. During post-commit review it was found out 
that its association with `RecordDecl` should be expressed in the name.

I'm planning to land this as soon as CI passes, probably without waiting for 
Windows bot.

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


9 Files Affected:

- (modified) clang/include/clang/AST/Decl.h (+6-5) 
- (modified) clang/include/clang/AST/DeclBase.h (+1-1) 
- (modified) clang/lib/AST/Decl.cpp (+1-1) 
- (modified) clang/lib/AST/DeclCXX.cpp (+5-5) 
- (modified) clang/lib/CodeGen/CGCall.cpp (+2-1) 
- (modified) clang/lib/Sema/SemaDecl.cpp (+5-3) 
- (modified) clang/lib/Sema/SemaDeclCXX.cpp (+5-4) 
- (modified) clang/lib/Serialization/ASTReaderDecl.cpp (+2-2) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
(+1-1) 


``diff
diff --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index d9b00b1628ab25c..d8ea8c1dfb4f292 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -4063,7 +4063,7 @@ class EnumDecl : public TagDecl {
 /// returned from function calls. This takes into account the target-specific
 /// and version-specific rules along with the rules determined by the
 /// language.
-enum class ArgPassingKind {
+enum class RecordArgPassingKind {
   /// The argument of this type can be passed directly in registers.
   CanPassInRegs,
 
@@ -4216,14 +4216,15 @@ class RecordDecl : public TagDecl {
   /// it must have at least one trivial, non-deleted copy or move constructor.
   /// FIXME: This should be set as part of completeDefinition.
   bool canPassInRegisters() const {
-return getArgPassingRestrictions() == ArgPassingKind::CanPassInRegs;
+return getArgPassingRestrictions() == RecordArgPassingKind::CanPassInRegs;
   }
 
-  ArgPassingKind getArgPassingRestrictions() const {
-return static_cast(RecordDeclBits.ArgPassingRestrictions);
+  RecordArgPassingKind getArgPassingRestrictions() const {
+return static_cast(
+RecordDeclBits.ArgPassingRestrictions);
   }
 
-  void setArgPassingRestrictions(ArgPassingKind Kind) {
+  void setArgPassingRestrictions(RecordArgPassingKind Kind) {
 RecordDeclBits.ArgPassingRestrictions = llvm::to_underlying(Kind);
   }
 
diff --git a/clang/include/clang/AST/DeclBase.h 
b/clang/include/clang/AST/DeclBase.h
index 6704c0cd41ecd3d..df1d6e8a3b5af72 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -1399,7 +1399,7 @@ enum class DeductionCandidate : unsigned char {
   Aggregate,
 };
 
-enum class ArgPassingKind;
+enum class RecordArgPassingKind;
 enum class OMPDeclareReductionInitKind;
 enum class ObjCImplementationControl;
 enum class LinkageSpecLanguageIDs;
diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 28243a76712d63e..6efc177d61c03ba 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -4932,7 +4932,7 @@ RecordDecl::RecordDecl(Kind DK, TagKind TK, const 
ASTContext &C,
   setHasNonTrivialToPrimitiveDestructCUnion(false);
   setHasNonTrivialToPrimitiveCopyCUnion(false);
   setParamDestroyedInCallee(false);
-  setArgPassingRestrictions(ArgPassingKind::CanPassInRegs);
+  setArgPassingRestrictions(RecordArgPassingKind::CanPassInRegs);
   setIsRandomized(false);
   setODRHash(0);
 }
diff --git a/clang/lib/AST/DeclCXX.cpp b/clang/lib/AST/DeclCXX.cpp
index 066b62b7c24110d..4002c63e9f94c12 100644
--- a/clang/lib/AST/DeclCXX.cpp
+++ b/clang/lib/AST/DeclCXX.cpp
@@ -446,8 +446,8 @@ CXXRecordDecl::setBases(CXXBaseSpecifier const * const 
*Bases,
   setHasVolatileMember(true);
 
 if (BaseClassDecl->getArgPassingRestrictions() ==
-ArgPassingKind::CanNeverPassInRegs)
-  setArgPassingRestrictions(ArgPassingKind::CanNeverPassInRegs);
+RecordArgPassingKind::CanNeverPassInRegs)
+  setArgPassingRestrictions(RecordArgPassingKind::CanNeverPassInRegs);
 
 // Keep track of the presence of mutable fields.
 if (BaseClassDecl->hasMutableFields())
@@ -1032,7 +1032,7 @@ void CXXRecordDecl::addedMember(Decl *D) {
 
 // Structs with __weak fields should never be passed directly.
 if (LT == Qualifiers::OCL_Weak)
-  setArgPassingRestrictions(ArgPassingKind::CanNeverPassInRegs);
+  setArgPassingRestrictions(RecordArgPassingKind::CanNeverPassInRegs);
 
 Data.HasIrrelevantDestructor = false;
 
@@ -1226,8 +1226,8 @@ void CXXRecordDecl::addedMember(Decl *D) {
 if (FieldRec->hasVolatileMember())
   setHasVolatileMember(true);
 if (FieldRec->getArgPassingRestrictions() ==
-ArgPassingKind::CanNeverPassInRegs)
-  setArgPassingRestrictions(ArgPassingKind::CanNeverPassInRegs);
+RecordArgPassingKind::CanNeverPassInRegs)
+  setArgPassingRestriction

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jonas Devlieghere via lldb-commits]

@@ -1612,6 +1612,22 @@ bool 
ProcessGDBRemote::CalculateThreadStopInfo(ThreadGDBRemote *thread) {
   return false;
 }
 
+void ProcessGDBRemote::ParseExpeditedRegisters(
+ExpeditedRegisterMap &expedited_register_map, ThreadSP thread_sp) {
+  ThreadGDBRemote *gdb_thread = static_cast(thread_sp.get());
+  RegisterContextSP gdb_reg_ctx_sp(gdb_thread->GetRegisterContext());
+
+  for (const auto &pair : expedited_register_map) {
+StringExtractor reg_value_extractor(pair.second);
+WritableDataBufferSP buffer_sp(

JDevlieghere wrote:

Orthogonal to this patch, but does this buffer need to be writable? It looks 
like it's "necessary" because `PrivateSetRegisterValue` takes a non-const 
reference to the buffer, but does it actually need to modify it?

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

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jonas Devlieghere via lldb-commits]

@@ -762,82 +756,22 @@ uint32_t 
GDBRemoteRegisterContext::ConvertRegisterKindToRegisterNumber(
   return m_reg_info_sp->ConvertRegisterKindToRegisterNumber(kind, num);
 }
 
-void GDBRemoteRegisterContext::AArch64Reconfigure() {
-  assert(m_reg_info_sp);
-
-  // Once we start to reconfigure registers, we cannot read any of them.
-  // So we must read VG and SVG up front.
-
-  const uint64_t fail_value = LLDB_INVALID_ADDRESS;
-  std::optional vg_reg_value;
-  const RegisterInfo *vg_reg_info = m_reg_info_sp->GetRegisterInfo("vg");
-  if (vg_reg_info) {
-// Make sure we get the latest value of vg from the remote.
-SetRegisterIsValid(vg_reg_info, false);
-uint32_t vg_reg_num = vg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(vg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  vg_reg_value = reg_value;
-  }
-
-  std::optional svg_reg_value;
-  const RegisterInfo *svg_reg_info = m_reg_info_sp->GetRegisterInfo("svg");
-  if (svg_reg_info) {
-// When vg is written it is automatically made invalid. Writing vg will 
also
-// change svg if we're in streaming mode but it will not be made invalid
-// so do this manually so the following read gets the latest svg value.
-SetRegisterIsValid(svg_reg_info, false);
-
-uint32_t svg_reg_num = svg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(svg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  svg_reg_value = reg_value;
-  }
-
-  if (vg_reg_value)
-m_reg_info_sp->UpdateARM64SVERegistersInfos(*vg_reg_value);
-  if (svg_reg_value)
-m_reg_info_sp->UpdateARM64SMERegistersInfos(*svg_reg_value);
-
-  // At this point if we have updated any registers, their offsets will all be
-  // invalid. If we did, we need to update them all.
-  if (vg_reg_value || svg_reg_value) {
-m_reg_info_sp->ConfigureOffsets();
-// From here we are able to read registers again.
-
-// Make a heap based buffer that is big enough to store all registers
-m_reg_data.SetData(std::make_shared(
-m_reg_info_sp->GetRegisterDataByteSize(), 0));
-m_reg_data.SetByteOrder(GetByteOrder());
-  }
-}
-
-void GDBRemoteDynamicRegisterInfo::UpdateARM64SVERegistersInfos(uint64_t vg) {
-  // SVE Z register size is vg x 8 bytes.
-  uint32_t z_reg_byte_size = vg * 8;
-
-  // SVE vector length has changed, accordingly set size of Z, P and FFR
-  // registers. Also invalidate register offsets it will be recalculated
-  // after SVE register size update.
-  for (auto ® : m_regs) {
-if (reg.value_regs == nullptr) {
-  if (reg.name[0] == 'z' && isdigit(reg.name[1]))
-reg.byte_size = z_reg_byte_size;
-  else if (reg.name[0] == 'p' && isdigit(reg.name[1]))
-reg.byte_size = vg;
-  else if (strcmp(reg.name, "ffr") == 0)
-reg.byte_size = vg;
-}
-reg.byte_offset = LLDB_INVALID_INDEX32;
-  }
+bool GDBRemoteRegisterContext::RegisterWriteCausesReconfigure(
+const char *name) {
+  ExecutionContext exe_ctx(CalculateThread());
+  Process *process = exe_ctx.GetProcessPtr();
+  const Architecture *architecture =
+  process->GetTarget().GetArchitecturePlugin();
+  return architecture && architecture->RegisterWriteCausesReconfigure(name);
 }
 
-void GDBRemoteDynamicRegisterInfo::UpdateARM64SMERegistersInfos(uint64_t svg) {
-  for (auto ® : m_regs) {
-if (strcmp(reg.name, "za") == 0) {
-  // ZA is a register with size (svg*8) * (svg*8). A square essentially.
-  reg.byte_size = (svg * 8) * (svg * 8);
-}
-reg.byte_offset = LLDB_INVALID_INDEX32;
-  }
+bool GDBRemoteRegisterContext::ReconfigureRegisterInfo() {
+  ExecutionContext exe_ctx(CalculateThread());
+  Process *process = exe_ctx.GetProcessPtr();

JDevlieghere wrote:

Are you sure this pointer is always valid? If so you should use `GetProcessRef` 
instead to convey that. Otherwise I'd do something like the snippet below which 
is a common pattern especially in LLVM. 

```
if (Process *process = exe_ctx.GetProcessPtr()) {
  if (const Architecture *architecture = 
process->GetTarget().GetArchitecturePlugin()) {
[...]
  }
}
```

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

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jonas Devlieghere via lldb-commits]

@@ -109,6 +110,24 @@ class Architecture : public PluginInterface {
   virtual const MemoryTagManager *GetMemoryTagManager() const {
 return nullptr;
   }
+
+  // This returns true if a write to the named register should cause lldb to
+  // reconfigure its register information. For example on AArch64 writing to vg
+  // to change the vector length means lldb has to change the size of 
registers.
+  virtual bool RegisterWriteCausesReconfigure(const char *name) const {

JDevlieghere wrote:

Why a `const char*` and not a `StringRef`? That would get rid of the `strcmp` 
in the AArch64 implementation. 

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

[Lldb-commits] [lldb] a8ead56 - [clang][NFC] Rename ArgPassingKind to RecordArgPassingKind (#70955)

[via lldb-commits]

Author: Vlad Serebrennikov
Date: 2023-11-01T20:38:28+04:00
New Revision: a8ead5606800261e94c2c703a366c59a12347fc4

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

LOG: [clang][NFC] Rename ArgPassingKind to RecordArgPassingKind (#70955)

During the recent refactoring (b120fe8d3288c4dca1b5427ca34839ce8833f71c) this 
enum was moved out of `RecordDecl`. During post-commit review it was found out 
that its association with `RecordDecl` should be expressed in the name.

Added: 


Modified: 
clang/include/clang/AST/Decl.h
clang/include/clang/AST/DeclBase.h
clang/lib/AST/Decl.cpp
clang/lib/AST/DeclCXX.cpp
clang/lib/CodeGen/CGCall.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclCXX.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Removed: 




diff  --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index d9b00b1628ab25c..d8ea8c1dfb4f292 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -4063,7 +4063,7 @@ class EnumDecl : public TagDecl {
 /// returned from function calls. This takes into account the target-specific
 /// and version-specific rules along with the rules determined by the
 /// language.
-enum class ArgPassingKind {
+enum class RecordArgPassingKind {
   /// The argument of this type can be passed directly in registers.
   CanPassInRegs,
 
@@ -4216,14 +4216,15 @@ class RecordDecl : public TagDecl {
   /// it must have at least one trivial, non-deleted copy or move constructor.
   /// FIXME: This should be set as part of completeDefinition.
   bool canPassInRegisters() const {
-return getArgPassingRestrictions() == ArgPassingKind::CanPassInRegs;
+return getArgPassingRestrictions() == RecordArgPassingKind::CanPassInRegs;
   }
 
-  ArgPassingKind getArgPassingRestrictions() const {
-return static_cast(RecordDeclBits.ArgPassingRestrictions);
+  RecordArgPassingKind getArgPassingRestrictions() const {
+return static_cast(
+RecordDeclBits.ArgPassingRestrictions);
   }
 
-  void setArgPassingRestrictions(ArgPassingKind Kind) {
+  void setArgPassingRestrictions(RecordArgPassingKind Kind) {
 RecordDeclBits.ArgPassingRestrictions = llvm::to_underlying(Kind);
   }
 

diff  --git a/clang/include/clang/AST/DeclBase.h 
b/clang/include/clang/AST/DeclBase.h
index 6704c0cd41ecd3d..df1d6e8a3b5af72 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -1399,7 +1399,7 @@ enum class DeductionCandidate : unsigned char {
   Aggregate,
 };
 
-enum class ArgPassingKind;
+enum class RecordArgPassingKind;
 enum class OMPDeclareReductionInitKind;
 enum class ObjCImplementationControl;
 enum class LinkageSpecLanguageIDs;

diff  --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 28243a76712d63e..6efc177d61c03ba 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -4932,7 +4932,7 @@ RecordDecl::RecordDecl(Kind DK, TagKind TK, const 
ASTContext &C,
   setHasNonTrivialToPrimitiveDestructCUnion(false);
   setHasNonTrivialToPrimitiveCopyCUnion(false);
   setParamDestroyedInCallee(false);
-  setArgPassingRestrictions(ArgPassingKind::CanPassInRegs);
+  setArgPassingRestrictions(RecordArgPassingKind::CanPassInRegs);
   setIsRandomized(false);
   setODRHash(0);
 }

diff  --git a/clang/lib/AST/DeclCXX.cpp b/clang/lib/AST/DeclCXX.cpp
index 066b62b7c24110d..4002c63e9f94c12 100644
--- a/clang/lib/AST/DeclCXX.cpp
+++ b/clang/lib/AST/DeclCXX.cpp
@@ -446,8 +446,8 @@ CXXRecordDecl::setBases(CXXBaseSpecifier const * const 
*Bases,
   setHasVolatileMember(true);
 
 if (BaseClassDecl->getArgPassingRestrictions() ==
-ArgPassingKind::CanNeverPassInRegs)
-  setArgPassingRestrictions(ArgPassingKind::CanNeverPassInRegs);
+RecordArgPassingKind::CanNeverPassInRegs)
+  setArgPassingRestrictions(RecordArgPassingKind::CanNeverPassInRegs);
 
 // Keep track of the presence of mutable fields.
 if (BaseClassDecl->hasMutableFields())
@@ -1032,7 +1032,7 @@ void CXXRecordDecl::addedMember(Decl *D) {
 
 // Structs with __weak fields should never be passed directly.
 if (LT == Qualifiers::OCL_Weak)
-  setArgPassingRestrictions(ArgPassingKind::CanNeverPassInRegs);
+  setArgPassingRestrictions(RecordArgPassingKind::CanNeverPassInRegs);
 
 Data.HasIrrelevantDestructor = false;
 
@@ -1226,8 +1226,8 @@ void CXXRecordDecl::addedMember(Decl *D) {
 if (FieldRec->hasVolatileMember())
   setHasVolatileMember(true);
 if (FieldRec->getArgPassingRestrictions() ==
-ArgPassingKind::CanNeverPassInRegs)
-  setArgPassingRestrictions(ArgPassingKind::CanNeverPassInRegs);
+RecordArgPassin

[Lldb-commits] [lldb] [clang] [clang][NFC] Rename ArgPassingKind to RecordArgPassingKind (PR #70955)

[Vlad Serebrennikov via lldb-commits]

https://github.com/Endilll closed 
https://github.com/llvm/llvm-project/pull/70955
___
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)

[via lldb-commits]

jimingham wrote:

That seems more like a GitHub problem than a you problem?  Seems weird to have 
to not touch a PR commit on a private branch lest you spam everyone with the 
notification...

Jim

> On Nov 1, 2023, at 8:49 AM, Daniel Chen ***@***.***> wrote:
> 
> 
> Sorry about the noise. All the reverts are in a private branch on my fork 
> repo. I didn't know it would broadcast to all the people who worked on the 
> reverted commits. My apologies.
> 
> —
> 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)

[Daniel Chen via lldb-commits]

DanielCChen wrote:

I think it is still my fault because it is indeed a PR branch that I did revert 
even though it is on my forked repo. I guess GitHub is doing the right thing to 
notify everyone affected as the PR could be potentially merged onto upstream 
branch by accident if it is approved. Again, my apologies to everyone who got 
distracted by this event.

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][AArch64] Read SME2's ZT0 register from Linux core files (PR #70934)

[Alex Langford via lldb-commits]

@@ -339,6 +337,18 @@ bool RegisterContextCorePOSIX_arm64::ReadRegister(const 
RegisterInfo *reg_info,
   value.SetFromMemoryData(*reg_info, src + sizeof(sve::user_za_header),
   reg_info->byte_size, lldb::eByteOrderLittle,
   error);
+} else if (m_register_info_up->IsSMERegZT(reg)) {
+  value.SetFromMemoryData(*reg_info, m_zt_data.GetDataStart(),
+  reg_info->byte_size, lldb::eByteOrderLittle,
+  error);
+} else {
+  offset = reg_info->byte_offset - m_register_info_up->GetSMEOffset();
+  assert(offset < sizeof(m_sme_pseudo_regs));

bulbazord wrote:

Since you're using an assert, I'll ask:
Is this a hard error that isn't recoverable from? Or could we do something else 
here?

https://github.com/llvm/llvm-project/pull/70934
___
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)

[David Blaikie via lldb-commits]

dwblaikie wrote:

> That's true, if defined in a header, we'll emit a DW_TAG_variable for the 
> constant in each compile unit the header is included in. GCC does do the 
> right thing and only emit the definition DIE in a single CU. We should 
> probably do the same. Though not sure at which level we want to catch that.

Which variable are you discussing here, `val1` or `val2`?

For `val1`, we could not emit the constant value and only emit the real 
definition (there's /some/ risk here - non-ODR uses (or otherwise optimized 
away uses) of the variable may mean that the object file that defines the 
variable won't be linked in - so we'd miss the constant value)
For `val2` the variable is effectively `inline` and doesn't have a home, so 
there's no one place that we can emit the `DW_TAG_variable` out-of-line 
definition... 

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)

[Michael Buch via lldb-commits]

Michael137 wrote:

> > That's true, if defined in a header, we'll emit a DW_TAG_variable for the 
> > constant in each compile unit the header is included in. GCC does do the 
> > right thing and only emit the definition DIE in a single CU. We should 
> > probably do the same. Though not sure at which level we want to catch that.
> 
> Which variable are you discussing here, `val1` or `val2`?
> 
> For `val1`, we could not emit the constant value and only emit the real 
> definition (there's /some/ risk here - non-ODR uses (or otherwise optimized 
> away uses) of the variable may mean that the object file that defines the 
> variable won't be linked in - so we'd miss the constant value) For `val2` the 
> variable is effectively `inline` and doesn't have a home, so there's no one 
> place that we can emit the `DW_TAG_variable` out-of-line definition...

Sorry for the confusion. I wasn't referring to that code snippet.

Also, I must've not looked at the GCC dwarfdump output carefully enough. 
Compiling two CUs that include a class with a `static constexpr` member will 
produce two separate definitions and two entries in `.debug_pubnames`:
```
.debug_pubnames 
   
global die-in-sect 0x0070, cu-in-sect 0x000c, die-in-cu 0x0070, 
cu-header-in-sect 0x 'Foo::val2'
   
global die-in-sect 0x007b, cu-in-sect 0x000c, die-in-cu 0x007b, 
cu-header-in-sect 0x 'main' 
  
global die-in-sect 0x0118, cu-in-sect 0x00b4, die-in-cu 0x0070, 
cu-header-in-sect 0x00a8 'Foo::val2'
   
global die-in-sect 0x0128, cu-in-sect 0x00b4, die-in-cu 0x0080, 
cu-header-in-sect 0x00a8 'Foo::func'   
```

So to answer Greg's question, yes we will potentially produce multiple variable 
definition DIEs. One for each CU that the header was included in

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] [libcxx] [clang] [compiler-rt] [clang-tools-extra] [lldb] [flang] [llvm] [openmp] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

[via lldb-commits]

https://github.com/nmustakin updated 
https://github.com/llvm/llvm-project/pull/70667

>From 153c6d812939cd23bb71e53c71378117ed5b23c7 Mon Sep 17 00:00:00 2001
From: Nafis Mustakin 
Date: Mon, 30 Oct 2023 07:50:59 -0700
Subject: [PATCH 1/4] Add memory diff dump for kernel record-replay

---
 .../PluginInterface/PluginInterface.cpp   | 65 +++
 1 file changed, 54 insertions(+), 11 deletions(-)

diff --git 
a/openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp
 
b/openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp
index 0243f0205dbf0e5..8469e8eaf1593cd 100644
--- 
a/openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp
+++ 
b/openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp
@@ -83,7 +83,7 @@ struct RecordReplayTy {
 return Plugin::success();
   }
 
-  void dumpDeviceMemory(StringRef Filename) {
+  void dumpDeviceMemory(StringRef Filename, bool saveDiff) {
 ErrorOr> DeviceMemoryMB =
 WritableMemoryBuffer::getNewUninitMemBuffer(MemorySize);
 if (!DeviceMemoryMB)
@@ -93,15 +93,58 @@ struct RecordReplayTy {
 MemoryStart, MemorySize, nullptr);
 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)
+
+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;
-OS.close();
+
+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 &value : modified)
+OS << value << " ";
+  OS << "\n"; 
+  i+=j+1; 
+}
+else i++; 
+  }
+}
+else {
+  StringRef DeviceMemory(DeviceMemoryMB.get()->getBufferStart(), 
MemorySize);
+  OS << DeviceMemory;
+}
+OS.close();  
   }
 
 public:
@@ -209,7 +252,7 @@ struct RecordReplayTy {
 JsonKernelInfo["ArgOffsets"] = json::Value(std::move(JsonArgOffsets));
 
 SmallString<128> MemoryFilename = {Name, ".memory"};
-dumpDeviceMemory(MemoryFilename);
+dumpDeviceMemory(MemoryFilename, false);
 
 SmallString<128> GlobalsFilename = {Name, ".globals"};
 dumpGlobals(GlobalsFilename, Image);
@@ -227,7 +270,7 @@ struct RecordReplayTy {
   void saveKernelOutputInfo(const char *Name) {
 SmallString<128> OutputFilename = {
 Name, (isRecording() ? ".original.output" : ".replay.output")};
-dumpDeviceMemory(OutputFilename);
+dumpDeviceMemory(OutputFilename, true);
   }
 
   void *alloc(uint64_t Size) {
@@ -1307,7 +1350,7 @@ Error GenericDeviceTy::launchKernel(void *EntryPtr, void 
**ArgPtrs,
 GenericKernel.getName(), GenericKernel.getImage(), ArgPtrs, ArgOffsets,
 KernelArgs.NumArgs, KernelArgs.NumTeams[0], KernelArgs.ThreadLimit[0],
 KernelArgs.Tripcount);
-
+   
   if (RecordReplay.isRecording())
 RecordReplay.saveImage(GenericKernel.getName(), GenericKernel.getImage());
 

>From 8daffad57074dd09287d321acd79c74a667eb65f Mon Sep 17 00:00:00 2001
From: Nafis Mustakin 
Date: Mon, 30 Oct 2023 08:39:40 -0700
Subject: [PATCH 2/4] Fix clang-formatting issues, accept reviewed suggestions

---
 .../PluginInterface/PluginInterface.cpp   | 78 

[Lldb-commits] [lld] [lldb] [flang] [libcxx] [compiler-rt] [clang-tools-extra] [llvm] [clang] [YAMLParser] Unfold multi-line scalar values (PR #70898)

[Igor Kudrin via lldb-commits]

https://github.com/igorkudrin updated 
https://github.com/llvm/llvm-project/pull/70898

>From 113c03bbf773c71d329ab2afd063753365e4ac68 Mon Sep 17 00:00:00 2001
From: Igor Kudrin 
Date: Thu, 26 Oct 2023 13:19:08 -0700
Subject: [PATCH] [YAMLParser] Unfold multi-line scalar values

Long scalar values can be split into multiple lines to improve
readability. The rules are described in Section 6.5. "Line Folding",
https://yaml.org/spec/1.2.2/#65-line-folding. In addition, for flow
scalar styles, the Spec states that "All leading and trailing white
space characters on each line are excluded from the content",
https://yaml.org/spec/1.2.2/#73-flow-scalar-styles.

The patch implements these unfolding rules for double-quoted,
single-quoted, and plain scalars.
---
 llvm/include/llvm/Support/YAMLParser.h  |   9 +-
 llvm/lib/Support/YAMLParser.cpp | 364 +---
 llvm/test/YAMLParser/spec-09-01.test|  11 +-
 llvm/test/YAMLParser/spec-09-02.test|  31 +-
 llvm/test/YAMLParser/spec-09-03.test|   7 +-
 llvm/test/YAMLParser/spec-09-04.test|   3 +-
 llvm/test/YAMLParser/spec-09-05.test|   7 +-
 llvm/test/YAMLParser/spec-09-06.test|   3 +-
 llvm/test/YAMLParser/spec-09-07.test|  11 +-
 llvm/test/YAMLParser/spec-09-08.test|  15 +-
 llvm/test/YAMLParser/spec-09-09.test|   7 +-
 llvm/test/YAMLParser/spec-09-10.test|   3 +-
 llvm/test/YAMLParser/spec-09-11.test|   6 +-
 llvm/test/YAMLParser/spec-09-13.test|  11 +-
 llvm/test/YAMLParser/spec-09-16.test|  17 +-
 llvm/test/YAMLParser/spec-09-17.test|   3 +-
 llvm/test/YAMLParser/spec1.2-07-05.test |   8 +
 llvm/test/YAMLParser/spec1.2-07-06.test |   7 +
 llvm/test/YAMLParser/spec1.2-07-09.test |   7 +
 llvm/test/YAMLParser/spec1.2-07-12.test |   7 +
 llvm/test/YAMLParser/spec1.2-07-14.test |  23 ++
 21 files changed, 367 insertions(+), 193 deletions(-)
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-05.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-06.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-09.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-12.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-14.test

diff --git a/llvm/include/llvm/Support/YAMLParser.h 
b/llvm/include/llvm/Support/YAMLParser.h
index f4767641647c217..9d95a1e13a0dff4 100644
--- a/llvm/include/llvm/Support/YAMLParser.h
+++ b/llvm/include/llvm/Support/YAMLParser.h
@@ -240,9 +240,14 @@ class ScalarNode final : public Node {
 private:
   StringRef Value;
 
-  StringRef unescapeDoubleQuoted(StringRef UnquotedValue,
- StringRef::size_type Start,
+  StringRef getDoubleQuotedValue(StringRef UnquotedValue,
  SmallVectorImpl &Storage) const;
+
+  static StringRef getSingleQuotedValue(StringRef RawValue,
+SmallVectorImpl &Storage);
+
+  static StringRef getPlainValue(StringRef RawValue,
+ SmallVectorImpl &Storage);
 };
 
 /// A block scalar node is an opaque datum that can be presented as a
diff --git a/llvm/lib/Support/YAMLParser.cpp b/llvm/lib/Support/YAMLParser.cpp
index 1422e40f91944ae..96b9aa95a96b3a6 100644
--- a/llvm/lib/Support/YAMLParser.cpp
+++ b/llvm/lib/Support/YAMLParser.cpp
@@ -2030,187 +2030,219 @@ bool Node::failed() const {
 }
 
 StringRef ScalarNode::getValue(SmallVectorImpl &Storage) const {
-  // TODO: Handle newlines properly. We need to remove leading whitespace.
-  if (Value[0] == '"') { // Double quoted.
-// Pull off the leading and trailing "s.
-StringRef UnquotedValue = Value.substr(1, Value.size() - 2);
-// Search for characters that would require unescaping the value.
-StringRef::size_type i = UnquotedValue.find_first_of("\\\r\n");
-if (i != StringRef::npos)
-  return unescapeDoubleQuoted(UnquotedValue, i, Storage);
+  if (Value[0] == '"')
+return getDoubleQuotedValue(Value, Storage);
+  if (Value[0] == '\'')
+return getSingleQuotedValue(Value, Storage);
+  return getPlainValue(Value, Storage);
+}
+
+static StringRef
+parseScalarValue(StringRef UnquotedValue, SmallVectorImpl &Storage,
+ StringRef LookupChars,
+ std::function &)>
+ UnescapeCallback) {
+  size_t I = UnquotedValue.find_first_of(LookupChars);
+  if (I == StringRef::npos)
 return UnquotedValue;
-  } else if (Value[0] == '\'') { // Single quoted.
-// Pull off the leading and trailing 's.
-StringRef UnquotedValue = Value.substr(1, Value.size() - 2);
-StringRef::size_type i = UnquotedValue.find('\'');
-if (i != StringRef::npos) {
-  // We're going to need Storage.
-  Storage.clear();
-  Storage.reserve(UnquotedValue.size());
-  for (; i != StringRef::npos; i = UnquotedValue.find('\'')) {
-StringRef Valid(UnquotedValue.begin(), i);
-llvm::append_range(Storage, Valid);
-Storage.push_back('\'');
-UnquotedValue = UnquotedValue.substr(i + 2

[Lldb-commits] [clang-tools-extra] [llvm] [clang] [compiler-rt] [flang] [lldb] [lld] [libcxx] [YAMLParser] Unfold multi-line scalar values (PR #70898)

[Igor Kudrin via lldb-commits]

https://github.com/igorkudrin updated 
https://github.com/llvm/llvm-project/pull/70898

>From 113c03bbf773c71d329ab2afd063753365e4ac68 Mon Sep 17 00:00:00 2001
From: Igor Kudrin 
Date: Thu, 26 Oct 2023 13:19:08 -0700
Subject: [PATCH] [YAMLParser] Unfold multi-line scalar values

Long scalar values can be split into multiple lines to improve
readability. The rules are described in Section 6.5. "Line Folding",
https://yaml.org/spec/1.2.2/#65-line-folding. In addition, for flow
scalar styles, the Spec states that "All leading and trailing white
space characters on each line are excluded from the content",
https://yaml.org/spec/1.2.2/#73-flow-scalar-styles.

The patch implements these unfolding rules for double-quoted,
single-quoted, and plain scalars.
---
 llvm/include/llvm/Support/YAMLParser.h  |   9 +-
 llvm/lib/Support/YAMLParser.cpp | 364 +---
 llvm/test/YAMLParser/spec-09-01.test|  11 +-
 llvm/test/YAMLParser/spec-09-02.test|  31 +-
 llvm/test/YAMLParser/spec-09-03.test|   7 +-
 llvm/test/YAMLParser/spec-09-04.test|   3 +-
 llvm/test/YAMLParser/spec-09-05.test|   7 +-
 llvm/test/YAMLParser/spec-09-06.test|   3 +-
 llvm/test/YAMLParser/spec-09-07.test|  11 +-
 llvm/test/YAMLParser/spec-09-08.test|  15 +-
 llvm/test/YAMLParser/spec-09-09.test|   7 +-
 llvm/test/YAMLParser/spec-09-10.test|   3 +-
 llvm/test/YAMLParser/spec-09-11.test|   6 +-
 llvm/test/YAMLParser/spec-09-13.test|  11 +-
 llvm/test/YAMLParser/spec-09-16.test|  17 +-
 llvm/test/YAMLParser/spec-09-17.test|   3 +-
 llvm/test/YAMLParser/spec1.2-07-05.test |   8 +
 llvm/test/YAMLParser/spec1.2-07-06.test |   7 +
 llvm/test/YAMLParser/spec1.2-07-09.test |   7 +
 llvm/test/YAMLParser/spec1.2-07-12.test |   7 +
 llvm/test/YAMLParser/spec1.2-07-14.test |  23 ++
 21 files changed, 367 insertions(+), 193 deletions(-)
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-05.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-06.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-09.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-12.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-14.test

diff --git a/llvm/include/llvm/Support/YAMLParser.h 
b/llvm/include/llvm/Support/YAMLParser.h
index f4767641647c217..9d95a1e13a0dff4 100644
--- a/llvm/include/llvm/Support/YAMLParser.h
+++ b/llvm/include/llvm/Support/YAMLParser.h
@@ -240,9 +240,14 @@ class ScalarNode final : public Node {
 private:
   StringRef Value;
 
-  StringRef unescapeDoubleQuoted(StringRef UnquotedValue,
- StringRef::size_type Start,
+  StringRef getDoubleQuotedValue(StringRef UnquotedValue,
  SmallVectorImpl &Storage) const;
+
+  static StringRef getSingleQuotedValue(StringRef RawValue,
+SmallVectorImpl &Storage);
+
+  static StringRef getPlainValue(StringRef RawValue,
+ SmallVectorImpl &Storage);
 };
 
 /// A block scalar node is an opaque datum that can be presented as a
diff --git a/llvm/lib/Support/YAMLParser.cpp b/llvm/lib/Support/YAMLParser.cpp
index 1422e40f91944ae..96b9aa95a96b3a6 100644
--- a/llvm/lib/Support/YAMLParser.cpp
+++ b/llvm/lib/Support/YAMLParser.cpp
@@ -2030,187 +2030,219 @@ bool Node::failed() const {
 }
 
 StringRef ScalarNode::getValue(SmallVectorImpl &Storage) const {
-  // TODO: Handle newlines properly. We need to remove leading whitespace.
-  if (Value[0] == '"') { // Double quoted.
-// Pull off the leading and trailing "s.
-StringRef UnquotedValue = Value.substr(1, Value.size() - 2);
-// Search for characters that would require unescaping the value.
-StringRef::size_type i = UnquotedValue.find_first_of("\\\r\n");
-if (i != StringRef::npos)
-  return unescapeDoubleQuoted(UnquotedValue, i, Storage);
+  if (Value[0] == '"')
+return getDoubleQuotedValue(Value, Storage);
+  if (Value[0] == '\'')
+return getSingleQuotedValue(Value, Storage);
+  return getPlainValue(Value, Storage);
+}
+
+static StringRef
+parseScalarValue(StringRef UnquotedValue, SmallVectorImpl &Storage,
+ StringRef LookupChars,
+ std::function &)>
+ UnescapeCallback) {
+  size_t I = UnquotedValue.find_first_of(LookupChars);
+  if (I == StringRef::npos)
 return UnquotedValue;
-  } else if (Value[0] == '\'') { // Single quoted.
-// Pull off the leading and trailing 's.
-StringRef UnquotedValue = Value.substr(1, Value.size() - 2);
-StringRef::size_type i = UnquotedValue.find('\'');
-if (i != StringRef::npos) {
-  // We're going to need Storage.
-  Storage.clear();
-  Storage.reserve(UnquotedValue.size());
-  for (; i != StringRef::npos; i = UnquotedValue.find('\'')) {
-StringRef Valid(UnquotedValue.begin(), i);
-llvm::append_range(Storage, Valid);
-Storage.push_back('\'');
-UnquotedValue = UnquotedValue.substr(i + 2

[Lldb-commits] [lldb] [lldb][AArch64] Simplify handing of scalable registers using vg and svg (PR #70914)

[Jason Molenda via lldb-commits]

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

This looks good to me, but this is at least partially overlapping with the 
change in https://github.com/llvm/llvm-project/pull/70950 right? 

https://github.com/llvm/llvm-project/pull/70914
___
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)

[Greg Clayton via lldb-commits]

clayborg 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`, we could try to 
> look for the definition and take the constant off of that.
> 
> What's interesting is that with this patch, the expression evaluator 
> successfully finds the `DW_TAG_variable`s 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

The DWARFASTParserClang, with the current state of things, will automatically 
add the const value initializer to the clang AST field. See 
`DWARFASTParserClang::ParseSingleMember(...)` around the `// Handle static 
members` around 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2882. The code 
extracts the `llvm::Expected const_value_or_err` and then calls 
`TypeSystemClang::SetIntegerInitializerForVariable(v, *const_value_or_err);` to 
set the constant value of the static member. 

I think the expression parser knows how to grab this value if it is in a static 
member variable. If this isn't there, it assumes there is a global variable 
that backs it and that we will be able to find the location of this variable in 
memory. The expression parser will ask for the address of this value during 
expression evaluation when it resolves the symbols.

> 
> > 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)

It would be nice to add this as a way to indicate this is a constexpr and that 
we need to do something special with it.

Is there anyway we can just leave the `DW_AT_const_value` in the 
`DW_TAG_member` and then have the `DW_TAG_variable` point to the 
`DW_TAG_member` using a `DW_AT_specification` or `DW_AT_abstract_origin`? My 
guess this isn't great DWARF where we have a `DW_TAG_variable` have a 
specification or abstract origin that points to a different DWARF tag.

Or maybe we can include the DW_AT_const_value in both places?

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] Add the ability to get a C++ vtable ValueObject from another ValueObj… (PR #67599)

[Greg Clayton via lldb-commits]

clayborg wrote:

> Sorry about the noise. All the reverts are in a private branch on my fork 
> repo. I didn't know it would broadcast to all the people who worked on the 
> reverted commits. My apologies.

No worries! I am getting used to the new github workflow. I will watch the 
revert messages more closely to make sure they aren't on upstream. Sorry for 
the noise from me!

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][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Med Ismail Bennani via lldb-commits]

@@ -109,6 +110,24 @@ class Architecture : public PluginInterface {
   virtual const MemoryTagManager *GetMemoryTagManager() const {
 return nullptr;
   }
+
+  // This returns true if a write to the named register should cause lldb to
+  // reconfigure its register information. For example on AArch64 writing to vg
+  // to change the vector length means lldb has to change the size of 
registers.
+  virtual bool RegisterWriteCausesReconfigure(const char *name) const {

medismailben wrote:

+1

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

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Med Ismail Bennani via lldb-commits]

@@ -762,82 +756,22 @@ uint32_t 
GDBRemoteRegisterContext::ConvertRegisterKindToRegisterNumber(
   return m_reg_info_sp->ConvertRegisterKindToRegisterNumber(kind, num);
 }
 
-void GDBRemoteRegisterContext::AArch64Reconfigure() {
-  assert(m_reg_info_sp);
-
-  // Once we start to reconfigure registers, we cannot read any of them.
-  // So we must read VG and SVG up front.
-
-  const uint64_t fail_value = LLDB_INVALID_ADDRESS;
-  std::optional vg_reg_value;
-  const RegisterInfo *vg_reg_info = m_reg_info_sp->GetRegisterInfo("vg");
-  if (vg_reg_info) {
-// Make sure we get the latest value of vg from the remote.
-SetRegisterIsValid(vg_reg_info, false);
-uint32_t vg_reg_num = vg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(vg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  vg_reg_value = reg_value;
-  }
-
-  std::optional svg_reg_value;
-  const RegisterInfo *svg_reg_info = m_reg_info_sp->GetRegisterInfo("svg");
-  if (svg_reg_info) {
-// When vg is written it is automatically made invalid. Writing vg will 
also
-// change svg if we're in streaming mode but it will not be made invalid
-// so do this manually so the following read gets the latest svg value.
-SetRegisterIsValid(svg_reg_info, false);
-
-uint32_t svg_reg_num = svg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(svg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  svg_reg_value = reg_value;
-  }
-
-  if (vg_reg_value)
-m_reg_info_sp->UpdateARM64SVERegistersInfos(*vg_reg_value);
-  if (svg_reg_value)
-m_reg_info_sp->UpdateARM64SMERegistersInfos(*svg_reg_value);
-
-  // At this point if we have updated any registers, their offsets will all be
-  // invalid. If we did, we need to update them all.
-  if (vg_reg_value || svg_reg_value) {
-m_reg_info_sp->ConfigureOffsets();
-// From here we are able to read registers again.
-
-// Make a heap based buffer that is big enough to store all registers
-m_reg_data.SetData(std::make_shared(
-m_reg_info_sp->GetRegisterDataByteSize(), 0));
-m_reg_data.SetByteOrder(GetByteOrder());
-  }
-}
-
-void GDBRemoteDynamicRegisterInfo::UpdateARM64SVERegistersInfos(uint64_t vg) {
-  // SVE Z register size is vg x 8 bytes.
-  uint32_t z_reg_byte_size = vg * 8;
-
-  // SVE vector length has changed, accordingly set size of Z, P and FFR
-  // registers. Also invalidate register offsets it will be recalculated
-  // after SVE register size update.
-  for (auto ® : m_regs) {
-if (reg.value_regs == nullptr) {
-  if (reg.name[0] == 'z' && isdigit(reg.name[1]))
-reg.byte_size = z_reg_byte_size;
-  else if (reg.name[0] == 'p' && isdigit(reg.name[1]))
-reg.byte_size = vg;
-  else if (strcmp(reg.name, "ffr") == 0)
-reg.byte_size = vg;
-}
-reg.byte_offset = LLDB_INVALID_INDEX32;
-  }
+bool GDBRemoteRegisterContext::RegisterWriteCausesReconfigure(
+const char *name) {
+  ExecutionContext exe_ctx(CalculateThread());
+  Process *process = exe_ctx.GetProcessPtr();
+  const Architecture *architecture =
+  process->GetTarget().GetArchitecturePlugin();
+  return architecture && architecture->RegisterWriteCausesReconfigure(name);

medismailben wrote:

Nice!

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

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Med Ismail Bennani via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Med Ismail Bennani via lldb-commits]

@@ -93,6 +93,10 @@ class DynamicRegisterInfo {
 return llvm::iterator_range(m_regs);
   }
 
+  llvm::iterator_range registers_mutable() {

medismailben wrote:

Can't this be just an overload of the `registers()` method above ? 

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

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Med Ismail Bennani via lldb-commits]

https://github.com/medismailben commented:

Thanks for taking care of this. LGTM with some comments.

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

[Lldb-commits] [lldb] [lldb] [debugserver] Shut down the exception thread when clearing (PR #70979)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda created 
https://github.com/llvm/llvm-project/pull/70979

MachProcess has a MachTask as an ivar.  In the MachProcess dtor, we call 
MachTask::Clear() to clear its state, before running the dtor of all our ivars, 
including the MachTask one.

When we attach on darwin, MachProcess calls MachTask::StartExceptionThread 
which does the task_for_pid and then starts a thread to listen for mach 
messages.  Then MachProcess calls ptrace(PT_ATTACHEXC).  If that ptrace() 
fails, MachProcess will call MachTask::Clear.  But the exception thread is now 
up & running and is not stopped; its ivars will be reset by the Clear() method, 
and its object will be freed after the dtor runs.

Actually eliciting a crash in this scenario is very timing sensitive; I 
hand-modified debugserver to fail to PT_ATTACHEXC trying to simulate it on my 
desktop and was unable.  But looking at the source, and an occasional crash 
report we've received, it's clear that this is possible.

rdar://117521198

>From 027e2ce8fcad6f1d6f5776033a938e34156cfaa7 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Wed, 1 Nov 2023 13:25:55 -0700
Subject: [PATCH] [lldb] [debugserver] Shut down the exception thread when
 clearing

MachProcess has a MachTask as an ivar.  In the MachProcess dtor,
we call MachTask::Clear() to clear its state, before running the
dtor of all our ivars, including the MachTask one.

When we attach on darwin, MachProcess calls MachTask::StartExceptionThread
which does the task_for_pid and then starts a thread to listen for
mach messages.  Then MachProcess calls ptrace(PT_ATTACHEXC).  If
that ptrace() fails, MachProcess will call MachTask::Clear.  But
the exception thread is now up & running and is not stopped; its
ivars will be reset by the Clear() method, and its object will be
freed after the dtor runs.

Actually eliciting a crash in this scenario is very timing sensitive;
I hand-modified debugserver to fail to PT_ATTACHEXC trying to simulate
it on my desktop and was unable.  But looking at the source, and an
occasional crash report we've received, it's clear that this is
possible.

rdar://117521198
---
 lldb/tools/debugserver/source/MacOSX/MachTask.mm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lldb/tools/debugserver/source/MacOSX/MachTask.mm 
b/lldb/tools/debugserver/source/MacOSX/MachTask.mm
index 4f5b4039243f662..fd2ac64ac6cf79c 100644
--- a/lldb/tools/debugserver/source/MacOSX/MachTask.mm
+++ b/lldb/tools/debugserver/source/MacOSX/MachTask.mm
@@ -145,6 +145,8 @@
 //--
 void MachTask::Clear() {
   // Do any cleanup needed for this task
+  if (m_exception_thread)
+ShutDownExcecptionThread();
   m_task = TASK_NULL;
   m_exception_thread = 0;
   m_exception_port = MACH_PORT_NULL;

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

[Lldb-commits] [lldb] [lldb] [debugserver] Shut down the exception thread when clearing (PR #70979)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jason Molenda (jasonmolenda)


Changes

MachProcess has a MachTask as an ivar.  In the MachProcess dtor, we call 
MachTask::Clear() to clear its state, before running the dtor of all our ivars, 
including the MachTask one.

When we attach on darwin, MachProcess calls MachTask::StartExceptionThread 
which does the task_for_pid and then starts a thread to listen for mach 
messages.  Then MachProcess calls ptrace(PT_ATTACHEXC).  If that ptrace() 
fails, MachProcess will call MachTask::Clear.  But the exception thread is now 
up & running and is not stopped; its ivars will be reset by the Clear() 
method, and its object will be freed after the dtor runs.

Actually eliciting a crash in this scenario is very timing sensitive; I 
hand-modified debugserver to fail to PT_ATTACHEXC trying to simulate it on my 
desktop and was unable.  But looking at the source, and an occasional crash 
report we've received, it's clear that this is possible.

rdar://117521198

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


1 Files Affected:

- (modified) lldb/tools/debugserver/source/MacOSX/MachTask.mm (+2) 


``diff
diff --git a/lldb/tools/debugserver/source/MacOSX/MachTask.mm 
b/lldb/tools/debugserver/source/MacOSX/MachTask.mm
index 4f5b4039243f662..fd2ac64ac6cf79c 100644
--- a/lldb/tools/debugserver/source/MacOSX/MachTask.mm
+++ b/lldb/tools/debugserver/source/MacOSX/MachTask.mm
@@ -145,6 +145,8 @@
 //--
 void MachTask::Clear() {
   // Do any cleanup needed for this task
+  if (m_exception_thread)
+ShutDownExcecptionThread();
   m_task = TASK_NULL;
   m_exception_thread = 0;
   m_exception_port = MACH_PORT_NULL;

``




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

[Lldb-commits] [lldb] [lldb] [debugserver] Shut down the exception thread when clearing (PR #70979)

[Med Ismail Bennani via lldb-commits]

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

Makes sense. LGTM!

https://github.com/llvm/llvm-project/pull/70979
___
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)

[Michael Buch via lldb-commits]

Michael137 wrote:

> The DWARFASTParserClang, with the current state of things, will automatically 
> add the const value initializer to the clang AST field. See 
> `DWARFASTParserClang::ParseSingleMember(...)` around the `// Handle static 
> members` around 
> lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2882. The code 
> extracts the `llvm::Expected const_value_or_err` and then calls 
> `TypeSystemClang::SetIntegerInitializerForVariable(v, *const_value_or_err);` 
> to set the constant value of the static member. 
> 
> 
> 
> I think the expression parser knows how to grab this value if it is in a 
> static member variable. If this isn't there, it assumes there is a global 
> variable that backs it and that we will be able to find the location of this 
> variable in memory. The expression parser will ask for the address of this 
> value during expression evaluation when it resolves the symbols.

Yup, what i was trying to explain is that with the current patch this will 
break because the expression evaluator neither finds the constant on the 
declaration (since we removed it) nor via symbol resolution (since they just 
won't exist for constants).

My point was just that if we are to drop the constant from the declaration, 
we'll have to amend that DWARFASTParserClang logic that you linked so it finds 
the correct variable definition and take the constant off of that.

> It would be nice to add this as a way to indicate this is a constexpr and 
> that we need to do something special with it.

I agree, though i think that can be done in isolation as a follow-up PR.

> Is there anyway we can just leave the `DW_AT_const_value` in the 
> `DW_TAG_member` and then have the `DW_TAG_variable` point to the 
> `DW_TAG_member` using a `DW_AT_specification` or `DW_AT_abstract_origin`? My 
> guess this isn't great DWARF where we have a `DW_TAG_variable` have a 
> specification or abstract origin that points to a different DWARF tag.

The variable definition *will* have a specification back to the declaration.

> Or maybe we can include the DW_AT_const_value in both places?

The ask to drop the constant off of the declaration comes from the 
DWARFParallelLinker work where it was causing non-deterministic output. But 
@dwblaikie @avl-llvm will know more about that



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)

[via lldb-commits]

avl-llvm wrote:

> > Or maybe we can include the DW_AT_const_value in both places?
> 
> The ask to drop the constant off of the declaration comes from the 
> DWARFParallelLinker work where it was causing non-deterministic output. But 
> @dwblaikie @avl-llvm will know more about that

I do not have a strong opinion which variant is better : 1) remove 
DW_AT_const_value from DW_TAG_member and put DW_AT_const_value into newly 
created DW_TAG_variable(which does not have a location). or 2) always put  
DW_AT_const_value in DW_TAG_member.

The problem which parallel DWARFLinker met is that DW_TAG_member from one 
compilation unit has DW_AT_const_value while the same DW_TAG_member from 
another compilation unit does not have DW_AT_const_value - 
https://github.com/llvm/llvm-project/pull/68721#issuecomment-1763409701.

If there is a solution when we could always put DW_AT_const_value into the 
DW_TAG_member (so that DW_TAG_member from different compile units have 
DW_AT_const_value) - then that would be also a good solution(and we would not 
need to create additional variable.)

Both solutions 1) and 2) are good for parallel DWARFLinker if they result in 
equal DWARF in different compile units.

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] [flang] [compiler-rt] [llvm] [openmp] [clang] [libcxx] [lldb] [lld] [mlir] [clang-tools-extra] [AMDGPU] GCNRegPressure printing pass for testing. (PR #70031)

[Valery Pykhtin via lldb-commits]

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

[Lldb-commits] [flang] [compiler-rt] [llvm] [openmp] [clang] [libcxx] [lldb] [lld] [mlir] [clang-tools-extra] [AMDGPU] GCNRegPressure printing pass for testing. (PR #70031)

[Valery Pykhtin via lldb-commits]

vpykhtin wrote:

I've removed live-through registers printing from this PR and will submit it 
separately.

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

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Kevin Frei via lldb-commits]

https://github.com/kevinfrei created 
https://github.com/llvm/llvm-project/pull/70996

I've plumbed the LLVM DebugInfoD client into LLDB, and added automatic 
downloading of DWP files to the SymbolFileDWARF.cpp plugin. If you have 
DEBUGINFOD_URLS set to a space delimited set of web servers, LLDB will try to 
use them as a last resort when searching for DWP files. If you do *not* have 
that environment variable set, nothing should be changed. There's also a 
setting, per @clayborg 's suggestion, that will override the environment 
variable, or can be used instead of the environment variable. The setting is 
why I also needed to add an API to the llvm-debuginfod library

### Test Plan:

Suggestions are welcome here. I should probably have some positive and negative 
tests, but I wanted to get the diff up for people who have a clue what they're 
doing to rip it to pieces before spending too much time validating the initial 
implementation.

>From 6454d4fb652f61a20850c75f0e69759dffe28511 Mon Sep 17 00:00:00 2001
From: Kevin Frei 
Date: Wed, 18 Oct 2023 14:37:34 -0700
Subject: [PATCH] DEBUGINFOD based DWP acquisition for LLDB

Summary:
I've plumbed the LLVM DebugInfoD client into LLDB, and added automatic 
downloading of
DWP files to the SymbolFileDWARF.cpp plugin. If you have `DEBUGINFOD_URLS` set 
to a
space delimited set of web servers, LLDB will try to use them as a last resort 
when
searching for DWP files. If you do *not* have that environment variable set, 
nothing
should be changed. There's also a setting, per Greg Clayton's request, that will
override the env variable, or can be used instead of the env var. This setting 
is the
reason for the additional API added to the llvm's Debuginfod library.

Test Plan:
Suggestions are welcome here. I should probably have some positive and negative 
tests,
but I wanted to get the diff up for people who have a clue what they're doing 
to rip it
to pieces before spending too much time validating my implementation.
---
 lldb/include/lldb/Target/Target.h |  3 +++
 lldb/source/Core/CoreProperties.td|  2 +-
 lldb/source/Core/Debugger.cpp |  5 
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  |  1 +
 lldb/source/Symbol/CMakeLists.txt |  1 +
 lldb/source/Symbol/LocateSymbolFile.cpp   | 20 --
 lldb/source/Target/Target.cpp | 19 +-
 lldb/source/Target/TargetProperties.td|  4 +++
 llvm/include/llvm/Debuginfod/Debuginfod.h |  4 +++
 llvm/lib/Debuginfod/Debuginfod.cpp| 26 ++-
 10 files changed, 75 insertions(+), 10 deletions(-)

diff --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index 82045988018b606..cd5c88767c900d1 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -258,6 +258,8 @@ class TargetProperties : public Properties {
 
   bool GetDebugUtilityExpression() const;
 
+  Args GetDebugInfoDURLs() const;
+
 private:
   // Callbacks for m_launch_info.
   void Arg0ValueChangedCallback();
@@ -270,6 +272,7 @@ class TargetProperties : public Properties {
   void DisableASLRValueChangedCallback();
   void InheritTCCValueChangedCallback();
   void DisableSTDIOValueChangedCallback();
+  void DebugInfoDURLsChangedCallback();
 
   // Settings checker for target.jit-save-objects-dir:
   void CheckJITObjectsDir();
diff --git a/lldb/source/Core/CoreProperties.td 
b/lldb/source/Core/CoreProperties.td
index 92884258347e9be..865030b0133bbb2 100644
--- a/lldb/source/Core/CoreProperties.td
+++ b/lldb/source/Core/CoreProperties.td
@@ -4,7 +4,7 @@ let Definition = "modulelist" in {
   def EnableExternalLookup: Property<"enable-external-lookup", "Boolean">,
 Global,
 DefaultTrue,
-Desc<"Control the use of external tools and repositories to locate symbol 
files. Directories listed in target.debug-file-search-paths and directory of 
the executable are always checked first for separate debug info files. Then 
depending on this setting: On macOS, Spotlight would be also used to locate a 
matching .dSYM bundle based on the UUID of the executable. On NetBSD, directory 
/usr/libdata/debug would be also searched. On platforms other than NetBSD 
directory /usr/lib/debug would be also searched.">;
+Desc<"Control the use of external tools and repositories to locate symbol 
files. Directories listed in target.debug-file-search-paths and directory of 
the executable are always checked first for separate debug info files. Then 
depending on this setting: On macOS, Spotlight would be also used to locate a 
matching .dSYM bundle based on the UUID of the executable. On NetBSD, directory 
/usr/libdata/debug would be also searched. On platforms other than NetBSD 
directory /usr/lib/debug would be also searched. If all other methods fail, and 
the DEBUGINFOD_URLS environment variable is specified, the Debuginfod protocol 
is used to acquire symbols from a compatible Debuginfod service.">;

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-debuginfo

Author: Kevin Frei (kevinfrei)


Changes

I've plumbed the LLVM DebugInfoD client into LLDB, and added automatic 
downloading of DWP files to the SymbolFileDWARF.cpp plugin. If you have 
DEBUGINFOD_URLS set to a space delimited set of web servers, LLDB will try to 
use them as a last resort when searching for DWP files. If you do *not* have 
that environment variable set, nothing should be changed. There's also a 
setting, per @clayborg 's suggestion, that will override the 
environment variable, or can be used instead of the environment variable. The 
setting is why I also needed to add an API to the llvm-debuginfod library

### Test Plan:

Suggestions are welcome here. I should probably have some positive and negative 
tests, but I wanted to get the diff up for people who have a clue what they're 
doing to rip it to pieces before spending too much time validating the initial 
implementation.

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


10 Files Affected:

- (modified) lldb/include/lldb/Target/Target.h (+3) 
- (modified) lldb/source/Core/CoreProperties.td (+1-1) 
- (modified) lldb/source/Core/Debugger.cpp (+5) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+1) 
- (modified) lldb/source/Symbol/CMakeLists.txt (+1) 
- (modified) lldb/source/Symbol/LocateSymbolFile.cpp (+18-2) 
- (modified) lldb/source/Target/Target.cpp (+18-1) 
- (modified) lldb/source/Target/TargetProperties.td (+4) 
- (modified) llvm/include/llvm/Debuginfod/Debuginfod.h (+4) 
- (modified) llvm/lib/Debuginfod/Debuginfod.cpp (+20-6) 


``diff
diff --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index 82045988018b606..cd5c88767c900d1 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -258,6 +258,8 @@ class TargetProperties : public Properties {
 
   bool GetDebugUtilityExpression() const;
 
+  Args GetDebugInfoDURLs() const;
+
 private:
   // Callbacks for m_launch_info.
   void Arg0ValueChangedCallback();
@@ -270,6 +272,7 @@ class TargetProperties : public Properties {
   void DisableASLRValueChangedCallback();
   void InheritTCCValueChangedCallback();
   void DisableSTDIOValueChangedCallback();
+  void DebugInfoDURLsChangedCallback();
 
   // Settings checker for target.jit-save-objects-dir:
   void CheckJITObjectsDir();
diff --git a/lldb/source/Core/CoreProperties.td 
b/lldb/source/Core/CoreProperties.td
index 92884258347e9be..865030b0133bbb2 100644
--- a/lldb/source/Core/CoreProperties.td
+++ b/lldb/source/Core/CoreProperties.td
@@ -4,7 +4,7 @@ let Definition = "modulelist" in {
   def EnableExternalLookup: Property<"enable-external-lookup", "Boolean">,
 Global,
 DefaultTrue,
-Desc<"Control the use of external tools and repositories to locate symbol 
files. Directories listed in target.debug-file-search-paths and directory of 
the executable are always checked first for separate debug info files. Then 
depending on this setting: On macOS, Spotlight would be also used to locate a 
matching .dSYM bundle based on the UUID of the executable. On NetBSD, directory 
/usr/libdata/debug would be also searched. On platforms other than NetBSD 
directory /usr/lib/debug would be also searched.">;
+Desc<"Control the use of external tools and repositories to locate symbol 
files. Directories listed in target.debug-file-search-paths and directory of 
the executable are always checked first for separate debug info files. Then 
depending on this setting: On macOS, Spotlight would be also used to locate a 
matching .dSYM bundle based on the UUID of the executable. On NetBSD, directory 
/usr/libdata/debug would be also searched. On platforms other than NetBSD 
directory /usr/lib/debug would be also searched. If all other methods fail, and 
the DEBUGINFOD_URLS environment variable is specified, the Debuginfod protocol 
is used to acquire symbols from a compatible Debuginfod service.">;
   def EnableBackgroundLookup: Property<"enable-background-lookup", "Boolean">,
 Global,
 DefaultFalse,
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 21f71e449ca5ed0..9a3e82f3e6a2adf 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -61,6 +61,8 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/iterator.h"
+#include "llvm/Debuginfod/Debuginfod.h"
+#include "llvm/Debuginfod/HTTPClient.h"
 #include "llvm/Support/DynamicLibrary.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Process.h"
@@ -594,6 +596,9 @@ lldb::DWIMPrintVerbosity Debugger::GetDWIMPrintVerbosity() 
const {
 void Debugger::Initialize(LoadPluginCallbackType load_plugin_callback) {
   assert(g_debugger_list_ptr == nullptr &&
  "Debugger::Initialize called more than once!");
+  // We might be using the Debuginfod service, so we have to initialize the
+  // HTTPClient *before* any new thread

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[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 801c78d5b474c2319aa8ead44db7ba8cacac4714 
6454d4fb652f61a20850c75f0e69759dffe28511 -- lldb/include/lldb/Target/Target.h 
lldb/source/Core/Debugger.cpp 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
lldb/source/Symbol/LocateSymbolFile.cpp lldb/source/Target/Target.cpp 
llvm/include/llvm/Debuginfod/Debuginfod.h llvm/lib/Debuginfod/Debuginfod.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index 1c0ead3677ea..06862ad2c2c8 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -4908,7 +4908,6 @@ void TargetProperties::DebugInfoDURLsChangedCallback() {
   llvm::setDefaultDebuginfodUrls(dbginfod_urls);
 }
 
-
 // Target::TargetEventData
 
 Target::TargetEventData::TargetEventData(const lldb::TargetSP &target_sp)

``




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

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Walter Erquinigo via lldb-commits]

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

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Walter Erquinigo via lldb-commits]

@@ -396,8 +398,22 @@ Symbols::LocateExecutableSymbolFile(const ModuleSpec 
&module_spec,
   }
 }
   }
-
-  return LocateExecutableSymbolFileDsym(module_spec);
+  FileSpec dsym_bundle = LocateExecutableSymbolFileDsym(module_spec);
+  if (dsym_bundle)
+return dsym_bundle;
+
+  // If we didn't find anything by looking locally, let's try Debuginfod.
+  if (module_uuid.IsValid() && llvm::canUseDebuginfod()) {
+llvm::object::BuildID build_id(module_uuid.GetBytes());
+llvm::Expected result =
+llvm::getCachedOrDownloadDebuginfo(build_id);
+if (result)
+  return FileSpec(*result);
+// An error is just fine, here...
+consumeError(result.takeError());
+  }
+  // Just return the empty FileSpec if nothing was found.
+  return dsym_bundle;

walter-erquinigo wrote:

better return `{}`. It's more readable.

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

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Walter Erquinigo via lldb-commits]

@@ -396,8 +398,22 @@ Symbols::LocateExecutableSymbolFile(const ModuleSpec 
&module_spec,
   }
 }
   }
-
-  return LocateExecutableSymbolFileDsym(module_spec);
+  FileSpec dsym_bundle = LocateExecutableSymbolFileDsym(module_spec);
+  if (dsym_bundle)
+return dsym_bundle;
+
+  // If we didn't find anything by looking locally, let's try Debuginfod.
+  if (module_uuid.IsValid() && llvm::canUseDebuginfod()) {
+llvm::object::BuildID build_id(module_uuid.GetBytes());
+llvm::Expected result =
+llvm::getCachedOrDownloadDebuginfo(build_id);
+if (result)
+  return FileSpec(*result);
+// An error is just fine, here...
+consumeError(result.takeError());

walter-erquinigo wrote:

log this to some log channel instead of consuming it

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

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo commented:

pretty nice feature!

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

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jason Molenda via lldb-commits]

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

LGTM.

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

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jason Molenda via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jason Molenda via lldb-commits]

@@ -1612,6 +1612,22 @@ bool 
ProcessGDBRemote::CalculateThreadStopInfo(ThreadGDBRemote *thread) {
   return false;
 }
 
+void ProcessGDBRemote::ParseExpeditedRegisters(
+ExpeditedRegisterMap &expedited_register_map, ThreadSP thread_sp) {
+  ThreadGDBRemote *gdb_thread = static_cast(thread_sp.get());
+  RegisterContextSP gdb_reg_ctx_sp(gdb_thread->GetRegisterContext());
+
+  for (const auto &pair : expedited_register_map) {
+StringExtractor reg_value_extractor(pair.second);
+WritableDataBufferSP buffer_sp(

jasonmolenda wrote:

We're decoding the asciihex register values into a byte buffer, this is the 
byte buffer.  

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

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jason Molenda via lldb-commits]

@@ -762,82 +756,22 @@ uint32_t 
GDBRemoteRegisterContext::ConvertRegisterKindToRegisterNumber(
   return m_reg_info_sp->ConvertRegisterKindToRegisterNumber(kind, num);
 }
 
-void GDBRemoteRegisterContext::AArch64Reconfigure() {
-  assert(m_reg_info_sp);
-
-  // Once we start to reconfigure registers, we cannot read any of them.
-  // So we must read VG and SVG up front.
-
-  const uint64_t fail_value = LLDB_INVALID_ADDRESS;
-  std::optional vg_reg_value;
-  const RegisterInfo *vg_reg_info = m_reg_info_sp->GetRegisterInfo("vg");
-  if (vg_reg_info) {
-// Make sure we get the latest value of vg from the remote.
-SetRegisterIsValid(vg_reg_info, false);
-uint32_t vg_reg_num = vg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(vg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  vg_reg_value = reg_value;
-  }
-
-  std::optional svg_reg_value;
-  const RegisterInfo *svg_reg_info = m_reg_info_sp->GetRegisterInfo("svg");
-  if (svg_reg_info) {
-// When vg is written it is automatically made invalid. Writing vg will 
also
-// change svg if we're in streaming mode but it will not be made invalid
-// so do this manually so the following read gets the latest svg value.
-SetRegisterIsValid(svg_reg_info, false);
-
-uint32_t svg_reg_num = svg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(svg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  svg_reg_value = reg_value;
-  }
-
-  if (vg_reg_value)
-m_reg_info_sp->UpdateARM64SVERegistersInfos(*vg_reg_value);
-  if (svg_reg_value)
-m_reg_info_sp->UpdateARM64SMERegistersInfos(*svg_reg_value);
-
-  // At this point if we have updated any registers, their offsets will all be
-  // invalid. If we did, we need to update them all.
-  if (vg_reg_value || svg_reg_value) {
-m_reg_info_sp->ConfigureOffsets();
-// From here we are able to read registers again.
-
-// Make a heap based buffer that is big enough to store all registers
-m_reg_data.SetData(std::make_shared(
-m_reg_info_sp->GetRegisterDataByteSize(), 0));
-m_reg_data.SetByteOrder(GetByteOrder());
-  }
-}
-
-void GDBRemoteDynamicRegisterInfo::UpdateARM64SVERegistersInfos(uint64_t vg) {
-  // SVE Z register size is vg x 8 bytes.
-  uint32_t z_reg_byte_size = vg * 8;
-
-  // SVE vector length has changed, accordingly set size of Z, P and FFR
-  // registers. Also invalidate register offsets it will be recalculated
-  // after SVE register size update.
-  for (auto ® : m_regs) {
-if (reg.value_regs == nullptr) {
-  if (reg.name[0] == 'z' && isdigit(reg.name[1]))
-reg.byte_size = z_reg_byte_size;
-  else if (reg.name[0] == 'p' && isdigit(reg.name[1]))
-reg.byte_size = vg;
-  else if (strcmp(reg.name, "ffr") == 0)
-reg.byte_size = vg;
-}
-reg.byte_offset = LLDB_INVALID_INDEX32;
-  }
+bool GDBRemoteRegisterContext::RegisterWriteCausesReconfigure(
+const char *name) {
+  ExecutionContext exe_ctx(CalculateThread());
+  Process *process = exe_ctx.GetProcessPtr();
+  const Architecture *architecture =
+  process->GetTarget().GetArchitecturePlugin();
+  return architecture && architecture->RegisterWriteCausesReconfigure(name);
 }
 
-void GDBRemoteDynamicRegisterInfo::UpdateARM64SMERegistersInfos(uint64_t svg) {
-  for (auto ® : m_regs) {
-if (strcmp(reg.name, "za") == 0) {
-  // ZA is a register with size (svg*8) * (svg*8). A square essentially.
-  reg.byte_size = (svg * 8) * (svg * 8);
-}
-reg.byte_offset = LLDB_INVALID_INDEX32;
-  }
+bool GDBRemoteRegisterContext::ReconfigureRegisterInfo() {
+  ExecutionContext exe_ctx(CalculateThread());
+  Process *process = exe_ctx.GetProcessPtr();

jasonmolenda wrote:

A RegisterContext is associated with a StackFrame which is in a Thread which is 
in a Process.  

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

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jonas Devlieghere via lldb-commits]

@@ -762,82 +756,22 @@ uint32_t 
GDBRemoteRegisterContext::ConvertRegisterKindToRegisterNumber(
   return m_reg_info_sp->ConvertRegisterKindToRegisterNumber(kind, num);
 }
 
-void GDBRemoteRegisterContext::AArch64Reconfigure() {
-  assert(m_reg_info_sp);
-
-  // Once we start to reconfigure registers, we cannot read any of them.
-  // So we must read VG and SVG up front.
-
-  const uint64_t fail_value = LLDB_INVALID_ADDRESS;
-  std::optional vg_reg_value;
-  const RegisterInfo *vg_reg_info = m_reg_info_sp->GetRegisterInfo("vg");
-  if (vg_reg_info) {
-// Make sure we get the latest value of vg from the remote.
-SetRegisterIsValid(vg_reg_info, false);
-uint32_t vg_reg_num = vg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(vg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  vg_reg_value = reg_value;
-  }
-
-  std::optional svg_reg_value;
-  const RegisterInfo *svg_reg_info = m_reg_info_sp->GetRegisterInfo("svg");
-  if (svg_reg_info) {
-// When vg is written it is automatically made invalid. Writing vg will 
also
-// change svg if we're in streaming mode but it will not be made invalid
-// so do this manually so the following read gets the latest svg value.
-SetRegisterIsValid(svg_reg_info, false);
-
-uint32_t svg_reg_num = svg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(svg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  svg_reg_value = reg_value;
-  }
-
-  if (vg_reg_value)
-m_reg_info_sp->UpdateARM64SVERegistersInfos(*vg_reg_value);
-  if (svg_reg_value)
-m_reg_info_sp->UpdateARM64SMERegistersInfos(*svg_reg_value);
-
-  // At this point if we have updated any registers, their offsets will all be
-  // invalid. If we did, we need to update them all.
-  if (vg_reg_value || svg_reg_value) {
-m_reg_info_sp->ConfigureOffsets();
-// From here we are able to read registers again.
-
-// Make a heap based buffer that is big enough to store all registers
-m_reg_data.SetData(std::make_shared(
-m_reg_info_sp->GetRegisterDataByteSize(), 0));
-m_reg_data.SetByteOrder(GetByteOrder());
-  }
-}
-
-void GDBRemoteDynamicRegisterInfo::UpdateARM64SVERegistersInfos(uint64_t vg) {
-  // SVE Z register size is vg x 8 bytes.
-  uint32_t z_reg_byte_size = vg * 8;
-
-  // SVE vector length has changed, accordingly set size of Z, P and FFR
-  // registers. Also invalidate register offsets it will be recalculated
-  // after SVE register size update.
-  for (auto ® : m_regs) {
-if (reg.value_regs == nullptr) {
-  if (reg.name[0] == 'z' && isdigit(reg.name[1]))
-reg.byte_size = z_reg_byte_size;
-  else if (reg.name[0] == 'p' && isdigit(reg.name[1]))
-reg.byte_size = vg;
-  else if (strcmp(reg.name, "ffr") == 0)
-reg.byte_size = vg;
-}
-reg.byte_offset = LLDB_INVALID_INDEX32;
-  }
+bool GDBRemoteRegisterContext::RegisterWriteCausesReconfigure(
+const char *name) {
+  ExecutionContext exe_ctx(CalculateThread());
+  Process *process = exe_ctx.GetProcessPtr();
+  const Architecture *architecture =
+  process->GetTarget().GetArchitecturePlugin();
+  return architecture && architecture->RegisterWriteCausesReconfigure(name);
 }
 
-void GDBRemoteDynamicRegisterInfo::UpdateARM64SMERegistersInfos(uint64_t svg) {
-  for (auto ® : m_regs) {
-if (strcmp(reg.name, "za") == 0) {
-  // ZA is a register with size (svg*8) * (svg*8). A square essentially.
-  reg.byte_size = (svg * 8) * (svg * 8);
-}
-reg.byte_offset = LLDB_INVALID_INDEX32;
-  }
+bool GDBRemoteRegisterContext::ReconfigureRegisterInfo() {
+  ExecutionContext exe_ctx(CalculateThread());
+  Process *process = exe_ctx.GetProcessPtr();

JDevlieghere wrote:

I figured, in which case it should use `GetProcessRef`. 

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

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jonas Devlieghere via lldb-commits]

@@ -1612,6 +1612,22 @@ bool 
ProcessGDBRemote::CalculateThreadStopInfo(ThreadGDBRemote *thread) {
   return false;
 }
 
+void ProcessGDBRemote::ParseExpeditedRegisters(
+ExpeditedRegisterMap &expedited_register_map, ThreadSP thread_sp) {
+  ThreadGDBRemote *gdb_thread = static_cast(thread_sp.get());
+  RegisterContextSP gdb_reg_ctx_sp(gdb_thread->GetRegisterContext());
+
+  for (const auto &pair : expedited_register_map) {
+StringExtractor reg_value_extractor(pair.second);
+WritableDataBufferSP buffer_sp(

JDevlieghere wrote:

Ah, makes sense. I was focussed on `PrivateSetRegisterValue` and missed the 
extraction bit. Thanks!

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

[Lldb-commits] [lldb] [lldb][split-dwarf] Add --errors-only argument separate-debug-info list (PR #71000)

[Tom Yang via lldb-commits]

https://github.com/zhyty created https://github.com/llvm/llvm-project/pull/71000

Often, we only care about the split-dwarf files that have failed to load. This 
can be useful when diagnosing binaries with many separate debug info files 
where only some have errors. 

```
(lldb) help image dump separate-debug-info
List the separate debug info symbol files for one or more target modules.

Syntax: target modules dump separate-debug-info  [ 
[ [...]]]

Command Options Usage:
  target modules dump separate-debug-info [-ej] [ [ [...]]]

   -e ( --errors-only )
Filter to show only debug info files with errors.

   -j ( --json )
Output the details in JSON format.

 This command takes options and free-form arguments.  If your arguments
 resemble option specifiers (i.e., they start with a - or --), you must use
 ' -- ' between the end of the command options and the beginning of the
 arguments.

'image' is an abbreviation for 'target modules'
```

I updated the following tests
```
# on Linux
bin/lldb-dotest -p TestDumpDwo

# on Mac
bin/lldb-dotest -p TestDumpOso
```

This change applies to both the table and JSON outputs.

>From c6900333c54d1c3f5dd3e6a88f0627b65ff0efca Mon Sep 17 00:00:00 2001
From: Tom Yang 
Date: Wed, 1 Nov 2023 00:53:19 -0700
Subject: [PATCH] [lldb] Add --errors-only argument separate-debug-info list

---
 lldb/include/lldb/Symbol/SymbolFile.h |  6 +-
 lldb/source/Commands/CommandObjectTarget.cpp  | 20 +--
 lldb/source/Commands/Options.td   |  4 +++-
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  |  6 --
 .../SymbolFile/DWARF/SymbolFileDWARF.h|  3 ++-
 .../DWARF/SymbolFileDWARFDebugMap.cpp |  5 +++--
 .../DWARF/SymbolFileDWARFDebugMap.h   |  3 ++-
 .../dwo/TestDumpDwo.py| 20 ---
 .../oso/TestDumpOso.py| 18 -
 9 files changed, 59 insertions(+), 26 deletions(-)

diff --git a/lldb/include/lldb/Symbol/SymbolFile.h 
b/lldb/include/lldb/Symbol/SymbolFile.h
index b40d0f03b6e0130..9fc90ad49361be8 100644
--- a/lldb/include/lldb/Symbol/SymbolFile.h
+++ b/lldb/include/lldb/Symbol/SymbolFile.h
@@ -445,7 +445,11 @@ class SymbolFile : public PluginInterface {
   /// contains the keys "type", "symfile", and "separate-debug-info-files".
   /// "type" can be used to assume the structure of each object in
   /// "separate-debug-info-files".
-  virtual bool GetSeparateDebugInfo(StructuredData::Dictionary &d) {
+  /// \param errors_only
+  /// If true, then only return separate debug info files that encountered
+  /// errors during loading.
+  virtual bool GetSeparateDebugInfo(StructuredData::Dictionary &d,
+bool errors_only) {
 return false;
   };
 
diff --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index c84a6550d6c75cc..ca8484cc79d4054 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -1452,11 +1452,11 @@ static bool DumpModuleSymbolFile(Stream &strm, Module 
*module) {
 }
 
 static bool GetSeparateDebugInfoList(StructuredData::Array &list,
- Module *module) {
+ Module *module, bool errors_only) {
   if (module) {
 if (SymbolFile *symbol_file = module->GetSymbolFile(/*can_create=*/true)) {
   StructuredData::Dictionary d;
-  if (symbol_file->GetSeparateDebugInfo(d)) {
+  if (symbol_file->GetSeparateDebugInfo(d, errors_only)) {
 list.AddItem(
 std::make_shared(std::move(d)));
 return true;
@@ -2561,7 +2561,10 @@ class 
CommandObjectTargetModulesDumpSeparateDebugInfoFiles
 m_json.SetCurrentValue(true);
 m_json.SetOptionWasSet();
 break;
-
+  case 'e':
+m_errors_only.SetCurrentValue(true);
+m_errors_only.SetOptionWasSet();
+break;
   default:
 llvm_unreachable("Unimplemented option");
   }
@@ -2570,6 +2573,7 @@ class CommandObjectTargetModulesDumpSeparateDebugInfoFiles
 
 void OptionParsingStarting(ExecutionContext *execution_context) override {
   m_json.Clear();
+  m_errors_only.Clear();
 }
 
 llvm::ArrayRef GetDefinitions() override {
@@ -2577,6 +2581,7 @@ class CommandObjectTargetModulesDumpSeparateDebugInfoFiles
 }
 
 OptionValueBoolean m_json = false;
+OptionValueBoolean m_errors_only = false;
   };
 
 protected:
@@ -2607,7 +2612,8 @@ class CommandObjectTargetModulesDumpSeparateDebugInfoFiles
   break;
 
 if (GetSeparateDebugInfoList(separate_debug_info_lists_by_module,
- module_sp.get()))
+ module_sp.get(),
+ bool(m_options.m_errors_only)))
   num_dumped++;
   }
 } else {
@@ -2628,7 +2634,7 @@

[Lldb-commits] [lldb] [lldb][split-dwarf] Add --errors-only argument separate-debug-info list (PR #71000)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Tom Yang (zhyty)


Changes

Often, we only care about the split-dwarf files that have failed to load. This 
can be useful when diagnosing binaries with many separate debug info files 
where only some have errors. 

```
(lldb) help image dump separate-debug-info
List the separate debug info symbol files for one or more target modules.

Syntax: target modules dump separate-debug-info  
[ [ [...]]]

Command Options Usage:
  target modules dump separate-debug-info [-ej] [ 
[ [...]]]

   -e ( --errors-only )
Filter to show only debug info files with errors.

   -j ( --json )
Output the details in JSON format.

 This command takes options and free-form arguments.  If your arguments
 resemble option specifiers (i.e., they start with a - or --), you must use
 ' -- ' between the end of the command options and the beginning of the
 arguments.

'image' is an abbreviation for 'target modules'
```

I updated the following tests
```
# on Linux
bin/lldb-dotest -p TestDumpDwo

# on Mac
bin/lldb-dotest -p TestDumpOso
```

This change applies to both the table and JSON outputs.

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


9 Files Affected:

- (modified) lldb/include/lldb/Symbol/SymbolFile.h (+5-1) 
- (modified) lldb/source/Commands/CommandObjectTarget.cpp (+14-6) 
- (modified) lldb/source/Commands/Options.td (+3-1) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+4-2) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h (+2-1) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp 
(+3-2) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h 
(+2-1) 
- (modified) 
lldb/test/API/commands/target/dump-separate-debug-info/dwo/TestDumpDwo.py 
(+13-7) 
- (modified) 
lldb/test/API/commands/target/dump-separate-debug-info/oso/TestDumpOso.py 
(+13-5) 


``diff
diff --git a/lldb/include/lldb/Symbol/SymbolFile.h 
b/lldb/include/lldb/Symbol/SymbolFile.h
index b40d0f03b6e0130..9fc90ad49361be8 100644
--- a/lldb/include/lldb/Symbol/SymbolFile.h
+++ b/lldb/include/lldb/Symbol/SymbolFile.h
@@ -445,7 +445,11 @@ class SymbolFile : public PluginInterface {
   /// contains the keys "type", "symfile", and "separate-debug-info-files".
   /// "type" can be used to assume the structure of each object in
   /// "separate-debug-info-files".
-  virtual bool GetSeparateDebugInfo(StructuredData::Dictionary &d) {
+  /// \param errors_only
+  /// If true, then only return separate debug info files that encountered
+  /// errors during loading.
+  virtual bool GetSeparateDebugInfo(StructuredData::Dictionary &d,
+bool errors_only) {
 return false;
   };
 
diff --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index c84a6550d6c75cc..ca8484cc79d4054 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -1452,11 +1452,11 @@ static bool DumpModuleSymbolFile(Stream &strm, Module 
*module) {
 }
 
 static bool GetSeparateDebugInfoList(StructuredData::Array &list,
- Module *module) {
+ Module *module, bool errors_only) {
   if (module) {
 if (SymbolFile *symbol_file = module->GetSymbolFile(/*can_create=*/true)) {
   StructuredData::Dictionary d;
-  if (symbol_file->GetSeparateDebugInfo(d)) {
+  if (symbol_file->GetSeparateDebugInfo(d, errors_only)) {
 list.AddItem(
 std::make_shared(std::move(d)));
 return true;
@@ -2561,7 +2561,10 @@ class 
CommandObjectTargetModulesDumpSeparateDebugInfoFiles
 m_json.SetCurrentValue(true);
 m_json.SetOptionWasSet();
 break;
-
+  case 'e':
+m_errors_only.SetCurrentValue(true);
+m_errors_only.SetOptionWasSet();
+break;
   default:
 llvm_unreachable("Unimplemented option");
   }
@@ -2570,6 +2573,7 @@ class CommandObjectTargetModulesDumpSeparateDebugInfoFiles
 
 void OptionParsingStarting(ExecutionContext *execution_context) override {
   m_json.Clear();
+  m_errors_only.Clear();
 }
 
 llvm::ArrayRef GetDefinitions() override {
@@ -2577,6 +2581,7 @@ class CommandObjectTargetModulesDumpSeparateDebugInfoFiles
 }
 
 OptionValueBoolean m_json = false;
+OptionValueBoolean m_errors_only = false;
   };
 
 protected:
@@ -2607,7 +2612,8 @@ class CommandObjectTargetModulesDumpSeparateDebugInfoFiles
   break;
 
 if (GetSeparateDebugInfoList(separate_debug_info_lists_by_module,
- module_sp.get()))
+ module_sp.get(),
+ bool(m_options.m_errors_only)))
   num_dumped++;
 

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

[David Blaikie via lldb-commits]

dwblaikie wrote:

> 2) always put DW_AT_const_value in DW_TAG_member.

My understanding is that this is not possible. Dependent initializer 
expressions can't be evaluated in all cases - we're only allowed to evaluate 
them in the places the language allows us to, otherwise we might produce the 
wrong answer.

For non-dependent initializer expressions I think we could produce the answer 
in all cases.

And if we want type descriptions that are consistent (valuable for use with 
Type Units, and with @avl-llvm's DWARFLinker work) and we want to include 
static member variables in those descriptions, then we could put the constant 
value in the declaration of the member in cases where the initializer is 
non-dependent. But we'd still have to put it out in a definition in the 
dependent cases (if we want consistency).

And if we have to put it out in a separate definition DIE anyway - probably 
good to do that consistently so there's fewer special cases?

Admittedly there are other reasons type definitions are inconsistent (eg: 
implicit special members, nested types, and member function template 
specializations (& I guess static member variable template specializations)) - 
and we could move static variables out of the authoritative type definitions 
the same way we do for those cases. We can see this in type units (the type 
unit never has these entities in it, but the skeleton unit that references the 
type unit does have these features) - I'd expect something like that to be what 
@avl-llvm will want to do with DWARFLinker - though without type units in 
input, I'm not sure how easily it'll be to determine that those are the variant 
parts that shouldn't go in the canonical type definition... 

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] [debugserver] Shut down the exception thread when clearing (PR #70979)

[Jonas Devlieghere via lldb-commits]

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


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

[Lldb-commits] [lldb] [lldb] [debugserver] Shut down the exception thread when clearing (PR #70979)

[Jason Molenda via lldb-commits]

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

[Lldb-commits] [lldb] 66b9283 - [lldb] [debugserver] Shut down the exception thread when clearing (#70979)

[via lldb-commits]

Author: Jason Molenda
Date: 2023-11-01T16:14:36-07:00
New Revision: 66b92830c963158c9f74dd5533265c28d60cc265

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

LOG: [lldb] [debugserver] Shut down the exception thread when clearing (#70979)

MachProcess has a MachTask as an ivar. In the MachProcess dtor, we call
MachTask::Clear() to clear its state, before running the dtor of all our
ivars, including the MachTask one.

When we attach on darwin, MachProcess calls
MachTask::StartExceptionThread which does the task_for_pid and then
starts a thread to listen for mach messages. Then MachProcess calls
ptrace(PT_ATTACHEXC). If that ptrace() fails, MachProcess will call
MachTask::Clear. But the exception thread is now up & running and is not
stopped; its ivars will be reset by the Clear() method, and its object
will be freed after the dtor runs.

Actually eliciting a crash in this scenario is very timing sensitive; I
hand-modified debugserver to fail to PT_ATTACHEXC trying to simulate it
on my desktop and was unable. But looking at the source, and an
occasional crash report we've received, it's clear that this is
possible.

rdar://117521198

Added: 


Modified: 
lldb/tools/debugserver/source/MacOSX/MachTask.mm

Removed: 




diff  --git a/lldb/tools/debugserver/source/MacOSX/MachTask.mm 
b/lldb/tools/debugserver/source/MacOSX/MachTask.mm
index 4f5b4039243f662..fd2ac64ac6cf79c 100644
--- a/lldb/tools/debugserver/source/MacOSX/MachTask.mm
+++ b/lldb/tools/debugserver/source/MacOSX/MachTask.mm
@@ -145,6 +145,8 @@
 //--
 void MachTask::Clear() {
   // Do any cleanup needed for this task
+  if (m_exception_thread)
+ShutDownExcecptionThread();
   m_task = TASK_NULL;
   m_exception_thread = 0;
   m_exception_port = MACH_PORT_NULL;



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

[Lldb-commits] [lldb] [lldb][split-dwarf] Add --errors-only argument separate-debug-info list (PR #71000)

[via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][split-dwarf] Add --errors-only argument separate-debug-info list (PR #71000)

[via lldb-commits]

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


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

[Lldb-commits] [lldb] [lldb][split-dwarf] Add --errors-only argument separate-debug-info list (PR #71000)

[via lldb-commits]

@@ -4296,7 +4297,8 @@ bool 
SymbolFileDWARF::GetSeparateDebugInfo(StructuredData::Dictionary &d) {
   dwarf_cu->GetDwoError().AsCString("unknown"));
 }
 dwo_data->AddBooleanItem("loaded", dwo_symfile != nullptr);
-separate_debug_info_files.AddItem(dwo_data);
+if (!errors_only || (errors_only && dwo_data->HasKey("error")))

jeffreytan81 wrote:

You do not need the second `errors_only` check. Simply use:
```
!errors_only || dwo_data->HasKey("error")
```

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

[Lldb-commits] [lldb] [lldb][AArch64] Read SME2's ZT0 register from Linux core files (PR #70934)

[Jason Molenda via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][AArch64] Read SME2's ZT0 register from Linux core files (PR #70934)

[Jason Molenda via lldb-commits]

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

LGTM.

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

[Lldb-commits] [lldb] [lldb][AArch64] Read SME2's ZT0 register from Linux core files (PR #70934)

[Jason Molenda via lldb-commits]

@@ -339,6 +337,18 @@ bool RegisterContextCorePOSIX_arm64::ReadRegister(const 
RegisterInfo *reg_info,
   value.SetFromMemoryData(*reg_info, src + sizeof(sve::user_za_header),
   reg_info->byte_size, lldb::eByteOrderLittle,
   error);
+} else if (m_register_info_up->IsSMERegZT(reg)) {
+  value.SetFromMemoryData(*reg_info, m_zt_data.GetDataStart(),
+  reg_info->byte_size, lldb::eByteOrderLittle,
+  error);
+} else {
+  offset = reg_info->byte_offset - m_register_info_up->GetSMEOffset();
+  assert(offset < sizeof(m_sme_pseudo_regs));

jasonmolenda wrote:

This would be someone trying to fetch a register that is at a greater offset 
than the register context buffer has.  My worry about the assert is more that 
in a non-debug/release build, there's no error checking, we'll read from past 
the end of the m_sme_psueo_regs buffer and copy it into value.
On the other hand, this does fall in to "this shouldn't ever happen", but maybe 
returning false here instead of filling in value would be the best choice.

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

[Lldb-commits] [libc] [clang] [lld] [llvm] [lldb] [libcxx] [clang-tools-extra] [flang] [OpenACC] Initial commits to support OpenACC (PR #70234)

[Bruno Cardoso Lopes via lldb-commits]

@@ -1342,6 +1342,15 @@ def err_opencl_logical_exclusive_or : Error<
 def err_openclcxx_virtual_function : Error<
   "virtual functions are not supported in C++ for OpenCL">;
 
+// OpenACC Support.
+def warn_pragma_acc_ignored : Warning<
+  "unexpected '#pragma acc ...' in program">, InGroup, 
DefaultIgnore;
+def err_acc_unexpected_directive : Error<
+  "unexpected OpenACC directive %select{|'#pragma acc %1'}0">;
+def warn_pragma_acc_unimplemented
+: Warning<"OpenACC Directives not yet implemented, pragma ignored">,

bcardosolopes wrote:

Does `Directives` need to be capitalized?

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

[Lldb-commits] [libcxx] [llvm] [lld] [clang] [libc] [flang] [lldb] [clang-tools-extra] [OpenACC] Initial commits to support OpenACC (PR #70234)

[Bruno Cardoso Lopes via lldb-commits]

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

[Lldb-commits] [libcxx] [lld] [flang] [clang] [llvm] [lldb] [clang-tools-extra] [libc] [OpenACC] Initial commits to support OpenACC (PR #70234)

[Bruno Cardoso Lopes via lldb-commits]

https://github.com/bcardosolopes commented:

The changes in this patch looks pretty straightforward! Left some inline 
comments.

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