[Lldb-commits] [PATCH] D98197: [lldb] Fix DWARF-5 DW_FORM_implicit_const (used by GCC)

2021-03-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Could you simplify the test case? It sounds like all you need is a single 
global variable (`int foo = 47;`), without any functions or that stuff. I guess 
we should also delete `test/Shell/Breakpoint/implicit_const_form_support.test`, 
as it's not very useful (the numbers it checks come from the line table, not 
from the implicit constants).  Other than that, this seems fine.




Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.cpp:30
+ dw_offset_t attr_die_offset, dw_attr_t attr) {
+  AttributeValue attr_value = {const_cast(form_value.GetUnit()),
+   attr_die_offset,

jankratochvil wrote:
> This `const_cast` is not nice. For its removal one can do either of:
>   - Just pass the `DWARFUnit *cu` additional parameter like there was before 
> (but it is a duplication of data)
>   - de-const `DWARFUnit *` in a lot of code around: 
> https://people.redhat.com/jkratoch/lldb-deconst.patch
> 
this is not the first const_cast of DWARFUnits, so, while definitely not ideal, 
I'm not particularly worried about it.



Comment at: lldb/test/Shell/SymbolFile/DWARF/dwarf5-implicit-const.s:3
+
+# UNSUPPORTED: system-darwin, system-windows
+# REQUIRES: x86

I hope these are not necessary, since you don't run the code here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98197

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


[Lldb-commits] [PATCH] D96458: [LLDB] Add support for Arm64/Linux dynamic register sets

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 329232.
omjavaid added a comment.

This update fixes review comments highlighted by @rovka


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

https://reviews.llvm.org/D96458

Files:
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
  lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp

Index: lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
===
--- lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
+++ lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
@@ -57,6 +57,7 @@
 }
 
 void RegisterContextCorePOSIX_arm64::ConfigureRegisterContext() {
+  Flags opt_regsets = RegisterInfoPOSIX_arm64::eRegsetMaskDefault;
   if (m_sveregset.GetByteSize() > sizeof(sve::user_sve_header)) {
 uint64_t sve_header_field_offset = 8;
 m_sve_vector_length = m_sveregset.GetU16(&sve_header_field_offset);
@@ -70,15 +71,18 @@
  sve::ptrace_regs_sve)
   m_sve_state = SVEState::Full;
 
-if (sve::vl_valid(m_sve_vector_length))
-  m_register_info_up->ConfigureVectorRegisterInfos(
-  sve::vq_from_vl(m_sve_vector_length));
-else {
+if (!sve::vl_valid(m_sve_vector_length)) {
   m_sve_state = SVEState::Disabled;
   m_sve_vector_length = 0;
 }
+opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskSVE);
   } else
 m_sve_state = SVEState::Disabled;
+
+  m_register_info_up->ConfigureRegisterInfos(opt_regsets);
+  if (m_sve_state != SVEState::Disabled)
+m_register_info_up->ConfigureVectorLength(
+sve::vq_from_vl(m_sve_vector_length));
 }
 
 uint32_t RegisterContextCorePOSIX_arm64::CalculateSVEOffset(
Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
@@ -19,7 +19,14 @@
 class RegisterInfoPOSIX_arm64
 : public lldb_private::RegisterInfoAndSetInterface {
 public:
-  enum { GPRegSet = 0, FPRegSet, SVERegSet };
+  enum { GPRegSet = 0, FPRegSet };
+
+  // AArch64 register set mask value
+  enum {
+eRegsetMaskDefault = 0,
+eRegsetMaskSVE = (1 << 0),
+eRegsetMaskDynamic = (~0u << 2),
+  };
 
   // AArch64 Register set FP/SIMD feature configuration
   enum {
@@ -85,7 +92,9 @@
 
   size_t GetRegisterSetFromRegisterIndex(uint32_t reg_index) const override;
 
-  uint32_t ConfigureVectorRegisterInfos(uint32_t sve_vq);
+  void ConfigureRegisterInfos(lldb_private::Flags &opt_regsets);
+
+  uint32_t ConfigureVectorLength(uint32_t sve_vq);
 
   bool VectorSizeIsValid(uint32_t vq) {
 if (vq >= eVectorQuadwordAArch64 && vq <= eVectorQuadwordAArch64SVEMax)
@@ -95,6 +104,7 @@
 
   bool IsSVEEnabled() const { return m_vector_reg_vq > eVectorQuadwordAArch64; }
 
+  bool IsSVEReg(unsigned reg) const;
   bool IsSVEZReg(unsigned reg) const;
   bool IsSVEPReg(unsigned reg) const;
   bool IsSVERegVG(unsigned reg) const;
@@ -115,6 +125,18 @@
 
   const lldb_private::RegisterInfo *m_register_info_p;
   uint32_t m_register_info_count;
+
+  const lldb_private::RegisterSet *m_register_set_p;
+  uint32_t m_register_set_count;
+
+  // Contains pair of [start, end] register numbers of a register set with start
+  // and end included.
+  std::map> m_per_regset_regnum_range;
+
+  bool m_reg_infos_is_dynamic = false;
+
+  std::vector m_dynamic_reg_infos;
+  std::vector m_dynamic_reg_sets;
 };
 
 #endif
Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
@@ -10,6 +10,7 @@
 #include 
 #include 
 
+#include "lldb/Utility/Flags.h"
 #include "lldb/lldb-defines.h"
 #include "llvm/Support/Compiler.h"
 
@@ -203,10 +204,17 @@
 const lldb_private::ArchSpec &target_arch)
 : lldb_private::RegisterInfoAndSetInterface(target_arch),
   m_register_info_p(GetRegisterInfoPtr(target_arch)),
-  m_register_info_count(GetRegisterInfoCount(target_arch)) {
+  m_register_info_count(GetRegisterInfoCount(target_arch)),
+  m_register_set_p(g_reg_sets_arm64),
+  m_register_set_count(k_num_register_sets - 1) {
+  m_per_regset_regnum_range[GPRegSet] = std::make_pair(gpr_x0, gpr_w28);
+  m_per_regset_regnum_range[FPRegSet] = std::make_pair(fpu_v0, fpu_fpcr);
 }
 
 uint32_t RegisterInfoPOSIX_arm64::GetRegisterCount() const {
+  if (m_reg_infos_is_dynamic)
+return m_register_info_count;
+
   if (IsSVEEnabled())
 return k_num_gpr_regi

[Lldb-commits] [PATCH] D96766: [lldb] [Process/FreeBSD] Introduce mips64 FPU reg support

2021-03-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D96766#2599440 , @nitesh.jain wrote:

> In D96766#2596701 , @labath wrote:
>
>> Hm I'm very tempted to delete the linux mips implementation -- it uses 
>> several techniques which are getting in the way of this patch (and also some 
>> others in the past), for a lot of those, we now have different/better ways 
>> of doing it. On top of that, it's completely unmaintained (last non-nfc 
>> change to the file was in 2017, and the author (@nitesh.jain) does not 
>> appear to be active anymore.
>
> Hi Labath,
>
> As you notice, we no longer work for MIPS and not sure who is the current 
> maintainer for the same.

Thanks for chiming in, Nitesh.

Email for linux/mips removal is here 
.


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

https://reviews.llvm.org/D96766

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


[Lldb-commits] [PATCH] D96459: [LLDB] Pull AuxVec info into NativeRegisterContextLinux_arm64

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 329235.
omjavaid added a comment.

Rebased after changes in parent.


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

https://reviews.llvm.org/D96459

Files:
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h


Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
@@ -166,6 +166,8 @@
 
   Status ReadHardwareDebugInfo();
 
+  void QueryAuxvForOptionalRegset(Flags &opt_regsets);
+
   Status WriteHardwareDebugRegs(int hwbType);
 
   uint32_t CalculateFprOffset(const RegisterInfo *reg_info) const;
Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -21,6 +21,7 @@
 #include "Plugins/Process/Linux/NativeProcessLinux.h"
 #include "Plugins/Process/Linux/Procfs.h"
 #include "Plugins/Process/POSIX/ProcessPOSIXLog.h"
+#include "Plugins/Process/Utility/AuxVector.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
 
 // System includes - They have to be included after framework includes because
@@ -98,6 +99,9 @@
   return static_cast(*m_register_info_interface_up);
 }
 
+void NativeRegisterContextLinux_arm64::QueryAuxvForOptionalRegset(
+Flags &opt_regset) {}
+
 uint32_t NativeRegisterContextLinux_arm64::GetRegisterSetCount() const {
   return GetRegisterInfo().GetRegisterSetCount();
 }
Index: lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
===
--- lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
+++ lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
@@ -156,6 +156,8 @@
 
   static Status SetDefaultPtraceOpts(const lldb::pid_t);
 
+  llvm::Optional GetAuxValue(enum AuxVector::EntryType type);
+
   void MonitorCallback(lldb::pid_t pid, bool exited, WaitStatus status);
 
   void WaitForNewThread(::pid_t tid);
Index: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
===
--- lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -2021,3 +2021,18 @@
 
   return error;
 }
+
+llvm::Optional
+NativeProcessLinux::GetAuxValue(enum AuxVector::EntryType type) {
+  if (m_aux_vector == nullptr) {
+auto buffer_or_error = GetAuxvData();
+if (!buffer_or_error)
+  return llvm::None;
+DataExtractor auxv_data(buffer_or_error.get()->getBufferStart(),
+buffer_or_error.get()->getBufferSize(),
+GetByteOrder(), GetAddressByteSize());
+m_aux_vector = std::make_unique(auxv_data);
+  }
+
+  return m_aux_vector->GetAuxValue(type);
+}


Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
@@ -166,6 +166,8 @@
 
   Status ReadHardwareDebugInfo();
 
+  void QueryAuxvForOptionalRegset(Flags &opt_regsets);
+
   Status WriteHardwareDebugRegs(int hwbType);
 
   uint32_t CalculateFprOffset(const RegisterInfo *reg_info) const;
Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -21,6 +21,7 @@
 #include "Plugins/Process/Linux/NativeProcessLinux.h"
 #include "Plugins/Process/Linux/Procfs.h"
 #include "Plugins/Process/POSIX/ProcessPOSIXLog.h"
+#include "Plugins/Process/Utility/AuxVector.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
 
 // System includes - They have to be included after framework includes because
@@ -98,6 +99,9 @@
   return static_cast(*m_register_info_interface_up);
 }
 
+void NativeRegisterContextLinux_arm64::QueryAuxvForOptionalRegset(
+Flags &opt_regset) {}
+
 uint32_t NativeRegisterContextLinux_arm64::GetRegisterSetCount() const {
   return GetRegisterInfo().GetRegisterSetCount();
 }
Index: lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
===
--- lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
+++ lldb/source/Plugins/Process/Li

[Lldb-commits] [PATCH] D96460: [LLDB] Arm64/Linux Add MTE and Pointer Authentication registers

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 329239.
omjavaid added a comment.

Rebased after changes to parent.


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

https://reviews.llvm.org/D96460

Files:
  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/Utility/RegisterInfos_arm64.h

Index: lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h
===
--- lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h
+++ lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h
@@ -470,6 +470,13 @@
 LLDB_INVALID_REGNUM, lldb_kind \
   }
 
+// Generates register kinds array for registers with only lldb kind
+#define KIND_ALL_INVALID   \
+  {\
+LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM, \
+LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM   \
+  }
+
 // Generates register kinds array for vector registers
 #define GPR64_KIND(reg, generic_kind) MISC_KIND(reg, gpr, generic_kind)
 #define VREG_KIND(reg) MISC_KIND(reg, fpu, LLDB_INVALID_REGNUM)
@@ -526,6 +533,13 @@
 nullptr, 0 \
   }
 
+// Defines pointer authentication mask registers
+#define DEFINE_EXTENSION_REG(reg)  \
+  {\
+#reg, nullptr, 8, 0, lldb::eEncodingUint, lldb::eFormatHex,\
+KIND_ALL_INVALID, nullptr, nullptr, nullptr, 0 \
+  }
+
 static lldb_private::RegisterInfo g_register_infos_arm64_le[] = {
 // DEFINE_GPR64(name, GENERIC KIND)
 DEFINE_GPR64(x0, LLDB_REGNUM_GENERIC_ARG1),
@@ -772,7 +786,12 @@
 {DEFINE_DBG(wcr, 13)},
 {DEFINE_DBG(wcr, 14)},
 {DEFINE_DBG(wcr, 15)}
-// clang-format on
 };
+// clang-format on
+static lldb_private::RegisterInfo g_register_infos_pauth[] = {
+DEFINE_EXTENSION_REG(data_mask), DEFINE_EXTENSION_REG(code_mask)};
+
+static lldb_private::RegisterInfo g_register_infos_mte[] = {
+DEFINE_EXTENSION_REG(mte_ctrl)};
 
 #endif // DECLARE_REGISTER_INFOS_ARM64_STRUCT
Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
@@ -25,6 +25,8 @@
   enum {
 eRegsetMaskDefault = 0,
 eRegsetMaskSVE = (1 << 0),
+eRegsetMaskPAuth = (1 << 1),
+eRegsetMaskMTE = (1 << 2),
 eRegsetMaskDynamic = (~0u << 2),
   };
 
@@ -94,6 +96,10 @@
 
   void ConfigureRegisterInfos(lldb_private::Flags &opt_regsets);
 
+  void AddRegSetPAuth();
+
+  void AddRegSetMTE();
+
   uint32_t ConfigureVectorLength(uint32_t sve_vq);
 
   bool VectorSizeIsValid(uint32_t vq) {
@@ -108,12 +114,16 @@
   bool IsSVEZReg(unsigned reg) const;
   bool IsSVEPReg(unsigned reg) const;
   bool IsSVERegVG(unsigned reg) const;
+  bool IsPAuthReg(unsigned reg) const;
+  bool IsMTEReg(unsigned reg) const;
 
   uint32_t GetRegNumSVEZ0() const;
   uint32_t GetRegNumSVEFFR() const;
   uint32_t GetRegNumFPCR() const;
   uint32_t GetRegNumFPSR() const;
   uint32_t GetRegNumSVEVG() const;
+  uint32_t GetPAuthOffset() const;
+  uint32_t GetMTEOffset() const;
 
 private:
   typedef std::map>
@@ -133,10 +143,15 @@
   // and end included.
   std::map> m_per_regset_regnum_range;
 
+  bool m_mte_regset_enabled = false;
+  bool m_pauth_regset_enabled = false;
   bool m_reg_infos_is_dynamic = false;
 
   std::vector m_dynamic_reg_infos;
   std::vector m_dynamic_reg_sets;
+
+  std::vector pauth_regnum_collection;
+  std::vector m_mte_regnum_collection;
 };
 
 #endif
Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
@@ -90,6 +90,8 @@
   k_num_gpr_registers = gpr_w28 - gpr_x0 + 1,
   k_num_fpr_registers = fpu_fpcr - fpu_v0 + 1,
   k_num_sve_registers = sve_ffr - sve_vg + 1,
+  k_num_mte_register = 1,
+  k_num_pauth_register = 2,
   k_num_register_sets = 3
 };
 
@@ -187,6 +189,12 @@
 {"Scalable Vector Extension Registers", "sve", k_num_sve_registers,
  g_sve_regnums_arm64}};
 
+static const lldb_private::RegisterSet g_reg_set_pauth_arm64 = {
+"Pointer Authentication Registers", "pauth", k_num_pauth_register, NULL};
+
+static cons

[Lldb-commits] [PATCH] D96463: [LLDB] Arm64/Linux test case for MTE and Pointer Authentication regset

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 329240.
omjavaid added a comment.

Minor fix to write unique value to all z/p registers when writing them using 
register write command.


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

https://reviews.llvm.org/D96463

Files:
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/test/API/commands/register/register/aarch64_dynamic_regset/Makefile
  
lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
  lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c

Index: lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c
===
--- /dev/null
+++ lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c
@@ -0,0 +1,88 @@
+#include 
+#include 
+
+#ifndef HWCAP2_MTE
+#define HWCAP2_MTE (1 << 18)
+#endif
+
+#ifndef HWCAP_PACA
+#define HWCAP_PACA (1 << 30)
+#endif
+
+void set_sve_registers() {
+  // AArch64 SVE extension ISA adds a new set of vector and predicate registers:
+  // 32 Z registers, 16 P registers, and 1 FFR register.
+  // Code below populates SVE registers to be read back by the debugger via
+  // ptrace interface at runtime.
+  // The P registers are predicate registers and hold one bit for each byte
+  // available in a Z vector register. For example, an SVE implementation with
+  // 1024-bit Z registers has 128-bit predicate registers.
+  // ptrue/pfalse instruction is used to set a predicate lane with a pattern.
+  // pattern is decided based on size specifier, b, h, s and d. if size
+  // specified is b all lanes will be set to 1. which is needed to set all bytes
+  // in a Z registers to the specified value.
+  asm volatile("setffr\n\t");
+  asm volatile("ptrue p0.b\n\t");
+  asm volatile("ptrue p1.h\n\t");
+  asm volatile("ptrue p2.s\n\t");
+  asm volatile("ptrue p3.d\n\t");
+  asm volatile("pfalse p4.b\n\t");
+  asm volatile("ptrue p5.b\n\t");
+  asm volatile("ptrue p6.h\n\t");
+  asm volatile("ptrue p7.s\n\t");
+  asm volatile("ptrue p8.d\n\t");
+  asm volatile("pfalse p9.b\n\t");
+  asm volatile("ptrue p10.b\n\t");
+  asm volatile("ptrue p11.h\n\t");
+  asm volatile("ptrue p12.s\n\t");
+  asm volatile("ptrue p13.d\n\t");
+  asm volatile("pfalse p14.b\n\t");
+  asm volatile("ptrue p15.b\n\t");
+
+  asm volatile("cpy  z0.b, p0/z, #1\n\t");
+  asm volatile("cpy  z1.b, p5/z, #2\n\t");
+  asm volatile("cpy  z2.b, p10/z, #3\n\t");
+  asm volatile("cpy  z3.b, p15/z, #4\n\t");
+  asm volatile("cpy  z4.b, p0/z, #5\n\t");
+  asm volatile("cpy  z5.b, p5/z, #6\n\t");
+  asm volatile("cpy  z6.b, p10/z, #7\n\t");
+  asm volatile("cpy  z7.b, p15/z, #8\n\t");
+  asm volatile("cpy  z8.b, p0/z, #9\n\t");
+  asm volatile("cpy  z9.b, p5/z, #10\n\t");
+  asm volatile("cpy  z10.b, p10/z, #11\n\t");
+  asm volatile("cpy  z11.b, p15/z, #12\n\t");
+  asm volatile("cpy  z12.b, p0/z, #13\n\t");
+  asm volatile("cpy  z13.b, p5/z, #14\n\t");
+  asm volatile("cpy  z14.b, p10/z, #15\n\t");
+  asm volatile("cpy  z15.b, p15/z, #16\n\t");
+  asm volatile("cpy  z16.b, p0/z, #17\n\t");
+  asm volatile("cpy  z17.b, p5/z, #18\n\t");
+  asm volatile("cpy  z18.b, p10/z, #19\n\t");
+  asm volatile("cpy  z19.b, p15/z, #20\n\t");
+  asm volatile("cpy  z20.b, p0/z, #21\n\t");
+  asm volatile("cpy  z21.b, p5/z, #22\n\t");
+  asm volatile("cpy  z22.b, p10/z, #23\n\t");
+  asm volatile("cpy  z23.b, p15/z, #24\n\t");
+  asm volatile("cpy  z24.b, p0/z, #25\n\t");
+  asm volatile("cpy  z25.b, p5/z, #26\n\t");
+  asm volatile("cpy  z26.b, p10/z, #27\n\t");
+  asm volatile("cpy  z27.b, p15/z, #28\n\t");
+  asm volatile("cpy  z28.b, p0/z, #29\n\t");
+  asm volatile("cpy  z29.b, p5/z, #30\n\t");
+  asm volatile("cpy  z30.b, p10/z, #31\n\t");
+  asm volatile("cpy  z31.b, p15/z, #32\n\t");
+}
+
+int main() {
+  unsigned long hwcap = getauxval(AT_HWCAP);
+  unsigned long hwcap2 = getauxval(AT_HWCAP2);
+
+  unsigned int sve_is_enabled = hwcap & HWCAP_SVE;
+  unsigned int pauth_is_enabled = hwcap & HWCAP_PACA;
+  unsigned int mte_is_enabled = hwcap2 & HWCAP2_MTE;
+
+  if (sve_is_enabled) // check if SVE is present
+set_sve_registers();
+
+  return 0; // Set a break point here.
+}
Index: lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
===
--- /dev/null
+++ lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
@@ -0,0 +1,111 @@
+"""
+Test AArch64 dynamic register sets
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class RegisterCommandsTestCase(TestBase):
+
+def check_sve_register_size(self, set, name, expected):
+reg_value = set.GetChildMemberWithName(name)
+self.assertTrue(reg_value.IsValid(),
+'Expected a register named %s' % (name))
+self.assertEqual(reg_v

[Lldb-commits] [PATCH] D96463: [LLDB] Arm64/Linux test case for MTE and Pointer Authentication regset

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added inline comments.



Comment at: 
lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py:45
+
+self.expect("register read ffr", substrs=[p_regs_value])
+

DavidSpickett wrote:
> omjavaid wrote:
> > DavidSpickett wrote:
> > > Do we need an ffr read if we have a read/write below?
> > Yes.
> > There are two values which are being verified:
> > First we verify value that was written by our assembly code.
> > After that we use debugger to write and read back values.
> Ok but then should the second r/w be of a different value?
> 
> program writes A - we read A, so the read works
> we write A - we read A, was that our A or the program's A?
Second read/write was different value but a fixed value was being used for 
testing all z/p registers. I have updated this rev to add unique values which 
are still different from what is written by the main.c


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

https://reviews.llvm.org/D96463

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


[Lldb-commits] [PATCH] D98197: [lldb] Fix DWARF-5 DW_FORM_implicit_const (used by GCC)

2021-03-09 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil updated this revision to Diff 329243.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98197

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFAbbreviationDeclaration.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.h
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
  lldb/test/Shell/SymbolFile/DWARF/dwarf5-implicit-const.s

Index: lldb/test/Shell/SymbolFile/DWARF/dwarf5-implicit-const.s
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/dwarf5-implicit-const.s
@@ -0,0 +1,85 @@
+# Test handling of DWARF5 DW_FORM_implicit_const as used by GCC.
+
+# RUN: llvm-mc -filetype=obj -o %t -triple x86_64-pc-linux %s
+# RUN: %lldb %t -o "expression -T -- variable_implicit_const" \
+# RUN:   -o exit | FileCheck %s
+
+# Failing case was:
+# error: need to add support for DW_TAG_base_type 'int' encoded with DW_ATE = 0x5, bit_size = 0
+# CHECK: (int) $0 = 0
+
+	.bss
+	.globl	variable_implicit_const
+	.type	variable_implicit_const, @object
+	.size	variable_implicit_const, 4
+variable_implicit_const:
+	.long	0
+.Lvariable_implicit_const_end:
+	.section	.debug_info,"",@progbits
+.Ldebug_info0:
+	.long	.Ldebug_info0_end - .Ldebug_info0_start	# Length of Compilation Unit Info
+.Ldebug_info0_start:
+	.value	0x5	# DWARF version number
+	.byte	0x1	# DW_UT_compile
+	.byte	0x8	# Pointer Size (in bytes)
+	.long	.Ldebug_abbrev0	# Offset Into Abbrev. Section
+	.uleb128 0x1	# (DIE DW_TAG_compile_unit)
+			# DW_AT_producer
+	.string	"GNU C17 11.0.0 20210210 (Red Hat 11.0.0-0) -mtune=generic -march=x86-64 -g"
+	.byte	0x1d	# DW_AT_language
+			# DW_AT_name
+	.string	"var4.c"
+	.uleb128 0x2	# (DIE DW_TAG_variable)
+			# DW_AT_name
+	.string	"variable_implicit_const"
+	.long	.Ltype_int - .Ldebug_info0	# DW_AT_type
+			# DW_AT_external
+	.uleb128 0x9	# DW_AT_location
+	.byte	0x3	# DW_OP_addr
+	.quad	variable_implicit_const
+.Ltype_int:
+	.uleb128 0x3	# (DIE DW_TAG_base_type)
+			# DW_AT_byte_size
+	.byte	0x5	# DW_AT_encoding
+	.ascii "int\0"	# DW_AT_name
+	.byte	0	# end of children of DIE DW_TAG_compile_unit
+.Ldebug_info0_end:
+	.section	.debug_abbrev,"",@progbits
+.Ldebug_abbrev0:
+	.uleb128 0x1	# (abbrev code)
+	.uleb128 0x11	# (TAG: DW_TAG_compile_unit)
+	.byte	0x1	# DW_children_yes
+	.uleb128 0x25	# (DW_AT_producer)
+	.uleb128 0x8	# (DW_FORM_string)
+	.uleb128 0x13	# (DW_AT_language)
+	.uleb128 0xb	# (DW_FORM_data1)
+	.uleb128 0x3	# (DW_AT_name)
+	.uleb128 0x8	# (DW_FORM_string)
+	.byte	0
+	.byte	0
+	.uleb128 0x2	# (abbrev code)
+	.uleb128 0x34	# (TAG: DW_TAG_variable)
+	.byte	0	# DW_children_no
+	.uleb128 0x3	# (DW_AT_name)
+	.uleb128 0x8	# (DW_FORM_string)
+	.uleb128 0x49	# (DW_AT_type)
+	.uleb128 0x13	# (DW_FORM_ref4)
+	.uleb128 0x3f	# (DW_AT_external)
+	.uleb128 0x19	# (DW_FORM_flag_present)
+	.uleb128 0x2	# (DW_AT_location)
+	.uleb128 0x18	# (DW_FORM_exprloc)
+	.byte	0
+	.byte	0
+	.uleb128 0x3	# (abbrev code)
+	.uleb128 0x24	# (TAG: DW_TAG_base_type)
+	.byte	0	# DW_children_no
+	.uleb128 0xb	# (DW_AT_byte_size)
+	.uleb128 0x21	# (DW_FORM_implicit_const)
+	.sleb128 .Lvariable_implicit_const_end - variable_implicit_const
+	.uleb128 0x3e	# (DW_AT_encoding)
+	.uleb128 0xb	# (DW_FORM_data1)
+	.uleb128 0x3	# (DW_AT_name)
+	.uleb128 0x8	# (DW_FORM_string)
+	.byte	0
+	.byte	0
+	.byte	0
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
@@ -432,7 +432,7 @@
 }
 LLVM_FALLTHROUGH;
   default:
-attributes.Append(cu, offset, attr, form);
+attributes.Append(form_value, offset, attr);
 break;
   }
 
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.h
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.h
@@ -24,6 +24,7 @@
 
   dw_attr_t get_attr() const { return m_attr; }
   dw_form_t get_form() const { return m_form; }
+  DWARFFormValue::ValueType get_value() const { return m_value; }
   void get(dw_attr_t &attr, dw_form_t &form,
DWARFFormValue::ValueType &val) const {
 attr = m_attr;
@@ -45,8 +46,8 @@
   DWARFAttributes();
   ~DWARFAttributes();
 
-  void Append(DWARFUnit *cu, dw_offset_t attr_die_offset, dw_attr_t attr,
-  dw_form_t form);
+  void Append(const DWARFFormValue &form_value, dw_offset_t attr_die_offset,
+  dw_attr_t attr);
   DWARFUnit *CompileUnitAtIndex(uint32_t i) const { return m_infos[i].cu; }
   dw_offset_t DIEOffsetAtIndex(uint32_t i) const {
 return m_infos[i].die_offset;
@@ -55,6 +56,9 @@
 return m_infos[i].attr.get_attr();
   }
   dw_att

[Lldb-commits] [PATCH] D98197: [lldb] Fix DWARF-5 DW_FORM_implicit_const (used by GCC)

2021-03-09 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil marked 2 inline comments as done.
jankratochvil added a comment.

In D98197#2613149 , @labath wrote:

> Could you simplify the test case?

done

> I guess we should also delete 
> `test/Shell/Breakpoint/implicit_const_form_support.test`, as it's not very 
> useful (the numbers it checks come from the line table, not from the implicit 
> constants).

I have not deleted it myself; I find non-racy simple tests to be always good as 
they may catch some completely unrelated regression in the future.




Comment at: lldb/test/Shell/SymbolFile/DWARF/dwarf5-implicit-const.s:3
+
+# UNSUPPORTED: system-darwin, system-windows
+# REQUIRES: x86

labath wrote:
> I hope these are not necessary, since you don't run the code here.
OK, removed:
```
-# UNSUPPORTED: system-darwin, system-windows
-# REQUIRES: x86
```
We will see after all the bots run again.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98197

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


[Lldb-commits] [PATCH] D96458: [LLDB] Add support for Arm64/Linux dynamic register sets

2021-03-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D96458#2578760 , @omjavaid wrote:

> In D96458#2566347 , @labath wrote:
>
>> I'm sorry, my response times are pretty slow these days.
>>
>> I'm thinking about this `ConfigureRegisterInfos` business. I get that the 
>> vector length is variable, and so we need to refresh it after every stop. 
>> However, the set of enabled extensions seems more static.
>>
>> Is it possible for that to change during the lifetime of the process? I'd 
>> guess not, because otherwise we'd have to also resend the register lists 
>> after every stop. And, if that's the case, I'm wondering if there's a way to 
>> reflect this static-ness in the code. For example, by doing this setup in 
>> the constructor, instead of a late `ConfigureRegisterInfos` call. IIRC, the 
>> register contexts are created when the thread is stopped, so it should be 
>> possible to fetch the information about supported registers quite early.
>>
>> What do you think?
>
> Yes that is doable. I ll move ConfigureRegisterInfos part into constructor.

There's still one `ConfigureRegisterInfos` call in the 
`RegisterContextCorePOSIX_arm64::ConfigureRegisterContext` function. Is that an 
omission, or is it intentional (i.e., needed to support some arm feature)? 
Because, if that's intentional, then the moving the setup to the constructor 
does not achieve what I wanted, as the set of registers can be overridden 
afterwards. It also means we need to have a bigger discussion about how to 
communicate the changed registers between the client and server. OTOH, if it's 
not intentional, then I'd like to remove that call, to make it obvious that the 
set of registers cannot change (only their length, for sve registers and such).

So, let me try to ask a direct question: Is there any situation in which the 
set of registers accessible to the inferior (and lldb-server) can change during 
the lifetime of a single process. If so, what is it?




Comment at: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp:259
+void RegisterInfoPOSIX_arm64::ConfigureRegisterInfos(
+lldb_private::Flags &opt_regsets) {
+  // Configures register sets supported by current target. If we have a dynamic

This should a const reference or just a plain value.



Comment at: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp:266
+m_reg_infos_is_dynamic = true;
+  }
+

We generally don't use braces around simple statements like this.



Comment at: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h:28
+eRegsetMaskSVE = (1 << 0),
+eRegsetMaskDynamic = (~0u << 2),
+  };

mixing signed and unsigned constants looks weird. Maybe just use `~3`?


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

https://reviews.llvm.org/D96458

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


[Lldb-commits] [PATCH] D98197: [lldb] Fix DWARF-5 DW_FORM_implicit_const (used by GCC)

2021-03-09 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

In D98197#2613227 , @jankratochvil 
wrote:

>> I guess we should also delete 
>> `test/Shell/Breakpoint/implicit_const_form_support.test`, as it's not very 
>> useful (the numbers it checks come from the line table, not from the 
>> implicit constants).
>
> I have not deleted it myself; I find non-racy simple tests to be always good 
> as they may catch some completely unrelated regression in the future.

Fine, I'll do it afterwards. :) If it was at least testing what it claims it's 
testing, I might keep it. However, judging by the need to re-fix implicit const 
support, it's not doing a good job at even that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98197

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


[Lldb-commits] [PATCH] D98197: [lldb] Fix DWARF-5 DW_FORM_implicit_const (used by GCC)

2021-03-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: lldb/test/Shell/SymbolFile/DWARF/dwarf5-implicit-const.s:3
+
+# UNSUPPORTED: system-darwin, system-windows
+# REQUIRES: x86

jankratochvil wrote:
> labath wrote:
> > I hope these are not necessary, since you don't run the code here.
> OK, removed:
> ```
> -# UNSUPPORTED: system-darwin, system-windows
> -# REQUIRES: x86
> ```
> We will see after all the bots run again.
Sorry, I only meant the system-*** thingies. The `REQUIRES: x86` thingy was 
correct, as it will cause the test to be skipped if someone completely disables 
x86 support (via LLVM_TARGETS_TO_BUILD).

That said, no bot actually builds lldb in that way, so I'm sure we have a lot 
of tests which are missing this clause.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98197

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


[Lldb-commits] [lldb] cf806d9 - [lldb] Fix DWARF-5 DW_FORM_implicit_const (used by GCC)

2021-03-09 Thread Jan Kratochvil via lldb-commits

Author: Jan Kratochvil
Date: 2021-03-09T10:23:05+01:00
New Revision: cf806d91d562736192f91478eb47daa29c2230bf

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

LOG: [lldb] Fix DWARF-5 DW_FORM_implicit_const (used by GCC)

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

Added: 
lldb/test/Shell/SymbolFile/DWARF/dwarf5-implicit-const.s

Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFAbbreviationDeclaration.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.h
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/SymbolFile/DWARF/DWARFAbbreviationDeclaration.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFAbbreviationDeclaration.cpp
index d53d882075f2..6a952ff88772 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFAbbreviationDeclaration.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFAbbreviationDeclaration.cpp
@@ -58,7 +58,7 @@ DWARFAbbreviationDeclaration::extract(const 
DWARFDataExtractor &data,
 DWARFFormValue::ValueType val;
 
 if (form == DW_FORM_implicit_const)
-  val.value.sval = data.GetULEB128(offset_ptr);
+  val.value.sval = data.GetSLEB128(offset_ptr);
 
 m_attributes.push_back(DWARFAttribute(attr, form, val));
   }

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.cpp
index ef98d7e33a90..ce95e3b91c77 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.cpp
@@ -25,10 +25,11 @@ uint32_t DWARFAttributes::FindAttributeIndex(dw_attr_t 
attr) const {
   return UINT32_MAX;
 }
 
-void DWARFAttributes::Append(DWARFUnit *cu, dw_offset_t attr_die_offset,
- dw_attr_t attr, dw_form_t form) {
-  AttributeValue attr_value = {
-  cu, attr_die_offset, {attr, form, DWARFFormValue::ValueType()}};
+void DWARFAttributes::Append(const DWARFFormValue &form_value,
+ dw_offset_t attr_die_offset, dw_attr_t attr) {
+  AttributeValue attr_value = {const_cast(form_value.GetUnit()),
+   attr_die_offset,
+   {attr, form_value.Form(), form_value.Value()}};
   m_infos.push_back(attr_value);
 }
 
@@ -37,6 +38,10 @@ bool DWARFAttributes::ExtractFormValueAtIndex(
   const DWARFUnit *cu = CompileUnitAtIndex(i);
   form_value.SetUnit(cu);
   form_value.SetForm(FormAtIndex(i));
+  if (form_value.Form() == DW_FORM_implicit_const) {
+form_value.SetValue(ValueAtIndex(i));
+return true;
+  }
   lldb::offset_t offset = DIEOffsetAtIndex(i);
   return form_value.ExtractValue(cu->GetData(), &offset);
 }

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.h
index 4c78b766a124..a31ee861179c 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.h
@@ -24,6 +24,7 @@ class DWARFAttribute {
 
   dw_attr_t get_attr() const { return m_attr; }
   dw_form_t get_form() const { return m_form; }
+  DWARFFormValue::ValueType get_value() const { return m_value; }
   void get(dw_attr_t &attr, dw_form_t &form,
DWARFFormValue::ValueType &val) const {
 attr = m_attr;
@@ -45,8 +46,8 @@ class DWARFAttributes {
   DWARFAttributes();
   ~DWARFAttributes();
 
-  void Append(DWARFUnit *cu, dw_offset_t attr_die_offset, dw_attr_t attr,
-  dw_form_t form);
+  void Append(const DWARFFormValue &form_value, dw_offset_t attr_die_offset,
+  dw_attr_t attr);
   DWARFUnit *CompileUnitAtIndex(uint32_t i) const { return m_infos[i].cu; }
   dw_offset_t DIEOffsetAtIndex(uint32_t i) const {
 return m_infos[i].die_offset;
@@ -55,6 +56,9 @@ class DWARFAttributes {
 return m_infos[i].attr.get_attr();
   }
   dw_attr_t FormAtIndex(uint32_t i) const { return m_infos[i].attr.get_form(); 
}
+  DWARFFormValue::ValueType ValueAtIndex(uint32_t i) const {
+return m_infos[i].attr.get_value();
+  }
   bool ExtractFormValueAtIndex(uint32_t i, DWARFFormValue &form_value) const;
   DWARFDIE FormValueAsReferenceAtIndex(uint32_t i) const;
   DWARFDIE FormValueAsReference(dw_attr_t attr) const;

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
index 29f60367999d..9fdd95b45bc7 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
@@ -432,7 +432,7 @@ size_t DWARFDebugInfoEntry::GetAttributes(DWARFUnit *cu,
 }
 LLVM_FALLTHROUGH;
   default:
-att

[Lldb-commits] [PATCH] D98197: [lldb] Fix DWARF-5 DW_FORM_implicit_const (used by GCC)

2021-03-09 Thread Jan Kratochvil via Phabricator via lldb-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcf806d91d562: [lldb] Fix DWARF-5 DW_FORM_implicit_const 
(used by GCC) (authored by jankratochvil).

Changed prior to commit:
  https://reviews.llvm.org/D98197?vs=329243&id=329250#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98197

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFAbbreviationDeclaration.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.h
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
  lldb/test/Shell/SymbolFile/DWARF/dwarf5-implicit-const.s

Index: lldb/test/Shell/SymbolFile/DWARF/dwarf5-implicit-const.s
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/dwarf5-implicit-const.s
@@ -0,0 +1,87 @@
+# Test handling of DWARF5 DW_FORM_implicit_const as used by GCC.
+
+# REQUIRES: x86
+
+# RUN: llvm-mc -filetype=obj -o %t -triple x86_64-pc-linux %s
+# RUN: %lldb %t -o "expression -T -- variable_implicit_const" \
+# RUN:   -o exit | FileCheck %s
+
+# Failing case was:
+# error: need to add support for DW_TAG_base_type 'int' encoded with DW_ATE = 0x5, bit_size = 0
+# CHECK: (int) $0 = 0
+
+	.bss
+	.globl	variable_implicit_const
+	.type	variable_implicit_const, @object
+	.size	variable_implicit_const, 4
+variable_implicit_const:
+	.long	0
+.Lvariable_implicit_const_end:
+	.section	.debug_info,"",@progbits
+.Ldebug_info0:
+	.long	.Ldebug_info0_end - .Ldebug_info0_start	# Length of Compilation Unit Info
+.Ldebug_info0_start:
+	.value	0x5	# DWARF version number
+	.byte	0x1	# DW_UT_compile
+	.byte	0x8	# Pointer Size (in bytes)
+	.long	.Ldebug_abbrev0	# Offset Into Abbrev. Section
+	.uleb128 0x1	# (DIE DW_TAG_compile_unit)
+			# DW_AT_producer
+	.string	"GNU C17 11.0.0 20210210 (Red Hat 11.0.0-0) -mtune=generic -march=x86-64 -g"
+	.byte	0x1d	# DW_AT_language
+			# DW_AT_name
+	.string	"var4.c"
+	.uleb128 0x2	# (DIE DW_TAG_variable)
+			# DW_AT_name
+	.string	"variable_implicit_const"
+	.long	.Ltype_int - .Ldebug_info0	# DW_AT_type
+			# DW_AT_external
+	.uleb128 0x9	# DW_AT_location
+	.byte	0x3	# DW_OP_addr
+	.quad	variable_implicit_const
+.Ltype_int:
+	.uleb128 0x3	# (DIE DW_TAG_base_type)
+			# DW_AT_byte_size
+	.byte	0x5	# DW_AT_encoding
+	.ascii "int\0"	# DW_AT_name
+	.byte	0	# end of children of DIE DW_TAG_compile_unit
+.Ldebug_info0_end:
+	.section	.debug_abbrev,"",@progbits
+.Ldebug_abbrev0:
+	.uleb128 0x1	# (abbrev code)
+	.uleb128 0x11	# (TAG: DW_TAG_compile_unit)
+	.byte	0x1	# DW_children_yes
+	.uleb128 0x25	# (DW_AT_producer)
+	.uleb128 0x8	# (DW_FORM_string)
+	.uleb128 0x13	# (DW_AT_language)
+	.uleb128 0xb	# (DW_FORM_data1)
+	.uleb128 0x3	# (DW_AT_name)
+	.uleb128 0x8	# (DW_FORM_string)
+	.byte	0
+	.byte	0
+	.uleb128 0x2	# (abbrev code)
+	.uleb128 0x34	# (TAG: DW_TAG_variable)
+	.byte	0	# DW_children_no
+	.uleb128 0x3	# (DW_AT_name)
+	.uleb128 0x8	# (DW_FORM_string)
+	.uleb128 0x49	# (DW_AT_type)
+	.uleb128 0x13	# (DW_FORM_ref4)
+	.uleb128 0x3f	# (DW_AT_external)
+	.uleb128 0x19	# (DW_FORM_flag_present)
+	.uleb128 0x2	# (DW_AT_location)
+	.uleb128 0x18	# (DW_FORM_exprloc)
+	.byte	0
+	.byte	0
+	.uleb128 0x3	# (abbrev code)
+	.uleb128 0x24	# (TAG: DW_TAG_base_type)
+	.byte	0	# DW_children_no
+	.uleb128 0xb	# (DW_AT_byte_size)
+	.uleb128 0x21	# (DW_FORM_implicit_const)
+	.sleb128 .Lvariable_implicit_const_end - variable_implicit_const
+	.uleb128 0x3e	# (DW_AT_encoding)
+	.uleb128 0xb	# (DW_FORM_data1)
+	.uleb128 0x3	# (DW_AT_name)
+	.uleb128 0x8	# (DW_FORM_string)
+	.byte	0
+	.byte	0
+	.byte	0
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
@@ -432,7 +432,7 @@
 }
 LLVM_FALLTHROUGH;
   default:
-attributes.Append(cu, offset, attr, form);
+attributes.Append(form_value, offset, attr);
 break;
   }
 
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.h
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFAttribute.h
@@ -24,6 +24,7 @@
 
   dw_attr_t get_attr() const { return m_attr; }
   dw_form_t get_form() const { return m_form; }
+  DWARFFormValue::ValueType get_value() const { return m_value; }
   void get(dw_attr_t &attr, dw_form_t &form,
DWARFFormValue::ValueType &val) const {
 attr = m_attr;
@@ -45,8 +46,8 @@
   DWARFAttributes();
   ~DWARFAttributes();
 
-  void Append(DWARFUnit *cu, dw_offset_t attr_die_offset, dw_attr_t attr,
-  dw_form_t form);
+  void Append(const DWARFFormValue &form_valu

[Lldb-commits] [PATCH] D96463: [LLDB] Arm64/Linux test case for MTE and Pointer Authentication regset

2021-03-09 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett added inline comments.



Comment at: 
lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py:96
+if 'Scalable Vector Extension Registers' in registerSet.GetName():
+self.assertTrue(self.isAArch64SVE(
+), 'LLDB enabled AArch64 SVE register set when it was disabled 
by target.')

Move the closing `)` onto the first line. Also I'd indent the line below like:
```
self.assertTrue(self.isAArch64SVE(), 
'LLDB enabled AArch64 SVE register set when it was disabled by target.')
self.
```

(applies to the next two as well)



Comment at: 
lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py:106
+if 'Pointer Authentication Registers' in registerSet.GetName():
+self.assertTrue(self.isAArch64MTE(
+), 'LLDB enabled AArch64 Pointer Authentication register set 
when it was disabled by target.')

Should be `isAArch64PAuth`



Comment at: 
lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c:81-82
+  unsigned int sve_is_enabled = hwcap & HWCAP_SVE;
+  unsigned int pauth_is_enabled = hwcap & HWCAP_PACA;
+  unsigned int mte_is_enabled = hwcap2 & HWCAP2_MTE;
+

These are unused since we get it from the cpuinfo, then you can inline the sve 
check in the if below.


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

https://reviews.llvm.org/D96463

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


[Lldb-commits] [PATCH] D98153: Some FormatEntity.cpp cleanup and unit testing

2021-03-09 Thread Neal via Phabricator via lldb-commits
nealsid updated this revision to Diff 329266.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98153

Files:
  lldb/include/lldb/Core/FormatEntity.h
  lldb/source/Core/FormatEntity.cpp
  lldb/unittests/Core/CMakeLists.txt
  lldb/unittests/Core/FormatEntityTest.cpp

Index: lldb/unittests/Core/FormatEntityTest.cpp
===
--- /dev/null
+++ lldb/unittests/Core/FormatEntityTest.cpp
@@ -0,0 +1,172 @@
+//===-- FormatEntityTest.cpp -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/Core/FormatEntity.h"
+#include "lldb/Utility/Status.h"
+
+#include "llvm/ADT/StringRef.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+
+using Definition = FormatEntity::Entry::Definition;
+using Entry = FormatEntity::Entry;
+
+TEST(FormatEntityTest, DefinitionConstructionAllParameters) {
+  Definition d("foo", "bar", FormatEntity::Entry::Type::Invalid, 0, 0, nullptr,
+   false);
+
+  ASSERT_EQ(d.name, "foo");
+  ASSERT_EQ(d.string, "bar");
+  ASSERT_EQ(d.type, FormatEntity::Entry::Type::Invalid);
+  ASSERT_EQ(d.data, 0UL);
+  ASSERT_EQ(d.num_children, 0UL);
+  ASSERT_EQ(d.children, nullptr);
+  ASSERT_FALSE(d.keep_separator);
+}
+
+TEST(FormatEntityTest, DefinitionConstructionNameAndType) {
+  Definition d("foo", FormatEntity::Entry::Type::Invalid);
+
+  ASSERT_EQ(d.name, "foo");
+  ASSERT_EQ(d.string, nullptr);
+  ASSERT_EQ(d.type, FormatEntity::Entry::Type::Invalid);
+  ASSERT_EQ(d.data, 0UL);
+  ASSERT_EQ(d.num_children, 0UL);
+  ASSERT_EQ(d.children, nullptr);
+  ASSERT_FALSE(d.keep_separator);
+}
+
+TEST(FormatEntityTest, DefinitionConstructionNameAndString) {
+  Definition d("foo", "string");
+
+  ASSERT_EQ(d.name, "foo");
+  ASSERT_EQ(d.string, "string");
+  ASSERT_EQ(d.type, FormatEntity::Entry::Type::EscapeCode);
+  ASSERT_EQ(d.data, 0UL);
+  ASSERT_EQ(d.num_children, 0UL);
+  ASSERT_EQ(d.children, nullptr);
+  ASSERT_FALSE(d.keep_separator);
+}
+
+TEST(FormatEntityTest, DefinitionConstructionNameTypeData) {
+  Definition d("foo", FormatEntity::Entry::Type::Invalid, 33);
+
+  ASSERT_EQ(d.name, "foo");
+  ASSERT_EQ(d.string, nullptr);
+  ASSERT_EQ(d.type, FormatEntity::Entry::Type::Invalid);
+  ASSERT_EQ(d.data, 33UL);
+  ASSERT_EQ(d.num_children, 0UL);
+  ASSERT_EQ(d.children, nullptr);
+  ASSERT_FALSE(d.keep_separator);
+}
+
+TEST(FormatEntityTest, DefinitionConstructionNameTypeChildren) {
+  Definition d("foo", FormatEntity::Entry::Type::Invalid, 33);
+  Definition parent("parent", FormatEntity::Entry::Type::Invalid, 1, &d);
+  ASSERT_EQ(parent.name, "parent");
+  ASSERT_EQ(parent.string, nullptr);
+  ASSERT_EQ(parent.type, FormatEntity::Entry::Type::Invalid);
+  ASSERT_EQ(parent.num_children, 1UL);
+  ASSERT_EQ(parent.children, &d);
+  ASSERT_FALSE(parent.keep_separator);
+
+  ASSERT_EQ(parent.children[0].name, "foo");
+  ASSERT_EQ(parent.children[0].string, nullptr);
+  ASSERT_EQ(parent.children[0].type, FormatEntity::Entry::Type::Invalid);
+  ASSERT_EQ(parent.children[0].data, 33UL);
+  ASSERT_EQ(parent.children[0].num_children, 0UL);
+  ASSERT_EQ(parent.children[0].children, nullptr);
+  ASSERT_FALSE(d.keep_separator);
+}
+
+constexpr llvm::StringRef lookupStrings[] = {
+"${addr.load}",
+"${addr.file}",
+"${ansi.fg.black}",
+"${ansi.fg.red}",
+"${ansi.fg.green}",
+"${ansi.fg.yellow}",
+"${ansi.fg.blue}",
+"${ansi.fg.purple}",
+"${ansi.fg.cyan}",
+"${ansi.fg.white}",
+"${ansi.bg.black}",
+"${ansi.bg.red}",
+"${ansi.bg.green}",
+"${ansi.bg.yellow}",
+"${ansi.bg.blue}",
+"${ansi.bg.purple}",
+"${ansi.bg.cyan}",
+"${ansi.bg.white}",
+"${file.basename}",
+"${file.dirname}",
+"${file.fullpath}",
+"${frame.index}",
+"${frame.pc}",
+"${frame.fp}",
+"${frame.sp}",
+"${frame.flags}",
+"${frame.no-debug}",
+"${frame.reg.*}",
+"${frame.is-artificial}",
+"${function.id}",
+"${function.name}",
+"${function.name-without-args}",
+"${function.name-with-args}",
+"${function.mangled-name}",
+"${function.addr-offset}",
+"${function.concrete-only-addr-offset-no-padding}",
+"${function.line-offset}",
+"${function.pc-offset}",
+"${function.initial-function}",
+"${function.changed}",
+"${function.is-optimized}",
+"${line.file.basename}",
+"${line.file.dirname}",
+"${line.file.fullpath}",
+"${line.number}",
+"${line.column}",
+"${line.start-addr}",
+"${line.end-addr}",
+"${module.file.basename}",
+"${module.file.dirname}",
+"${module.file.fullpath}",
+"${process.id}",

[Lldb-commits] [PATCH] D98153: Some FormatEntity.cpp cleanup and unit testing

2021-03-09 Thread Neal via Phabricator via lldb-commits
nealsid marked 3 inline comments as done.
nealsid added inline comments.



Comment at: lldb/include/lldb/Core/FormatEntity.h:144
+num_children(num_children), children(children),
+keep_separator(keep_separator) {}
 };

teemperor wrote:
> I believe you could make this far less verbose with delegating constructors 
> and using C++11 default member initializers.
Makes sense - I used default member initializers but once I did that, 
delegating constructors seemed to add more code back in :) So I just stuck with 
the member initializers.  



Comment at: lldb/source/Core/FormatEntity.cpp:1759
+  return false;
+}
 const char *name = nullptr;

teemperor wrote:
> One-line if's don't have `{}` around the body according to LLVM code style (I 
> know this is wrong in a lot of LLDB code, but newer code should follow that 
> style). Just commenting this once but the same thing is happening above/below 
> this change too.
Done, here and in other spots I noticed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98153

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


[Lldb-commits] [PATCH] D96463: [LLDB] Arm64/Linux test case for MTE and Pointer Authentication regset

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 329269.
omjavaid added a comment.

fixes review comments.


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

https://reviews.llvm.org/D96463

Files:
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/test/API/commands/register/register/aarch64_dynamic_regset/Makefile
  
lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
  lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c

Index: lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c
===
--- /dev/null
+++ lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c
@@ -0,0 +1,88 @@
+#include 
+#include 
+
+#ifndef HWCAP2_MTE
+#define HWCAP2_MTE (1 << 18)
+#endif
+
+#ifndef HWCAP_PACA
+#define HWCAP_PACA (1 << 30)
+#endif
+
+void set_sve_registers() {
+  // AArch64 SVE extension ISA adds a new set of vector and predicate registers:
+  // 32 Z registers, 16 P registers, and 1 FFR register.
+  // Code below populates SVE registers to be read back by the debugger via
+  // ptrace interface at runtime.
+  // The P registers are predicate registers and hold one bit for each byte
+  // available in a Z vector register. For example, an SVE implementation with
+  // 1024-bit Z registers has 128-bit predicate registers.
+  // ptrue/pfalse instruction is used to set a predicate lane with a pattern.
+  // pattern is decided based on size specifier, b, h, s and d. if size
+  // specified is b all lanes will be set to 1. which is needed to set all bytes
+  // in a Z registers to the specified value.
+  asm volatile("setffr\n\t");
+  asm volatile("ptrue p0.b\n\t");
+  asm volatile("ptrue p1.h\n\t");
+  asm volatile("ptrue p2.s\n\t");
+  asm volatile("ptrue p3.d\n\t");
+  asm volatile("pfalse p4.b\n\t");
+  asm volatile("ptrue p5.b\n\t");
+  asm volatile("ptrue p6.h\n\t");
+  asm volatile("ptrue p7.s\n\t");
+  asm volatile("ptrue p8.d\n\t");
+  asm volatile("pfalse p9.b\n\t");
+  asm volatile("ptrue p10.b\n\t");
+  asm volatile("ptrue p11.h\n\t");
+  asm volatile("ptrue p12.s\n\t");
+  asm volatile("ptrue p13.d\n\t");
+  asm volatile("pfalse p14.b\n\t");
+  asm volatile("ptrue p15.b\n\t");
+
+  asm volatile("cpy  z0.b, p0/z, #1\n\t");
+  asm volatile("cpy  z1.b, p5/z, #2\n\t");
+  asm volatile("cpy  z2.b, p10/z, #3\n\t");
+  asm volatile("cpy  z3.b, p15/z, #4\n\t");
+  asm volatile("cpy  z4.b, p0/z, #5\n\t");
+  asm volatile("cpy  z5.b, p5/z, #6\n\t");
+  asm volatile("cpy  z6.b, p10/z, #7\n\t");
+  asm volatile("cpy  z7.b, p15/z, #8\n\t");
+  asm volatile("cpy  z8.b, p0/z, #9\n\t");
+  asm volatile("cpy  z9.b, p5/z, #10\n\t");
+  asm volatile("cpy  z10.b, p10/z, #11\n\t");
+  asm volatile("cpy  z11.b, p15/z, #12\n\t");
+  asm volatile("cpy  z12.b, p0/z, #13\n\t");
+  asm volatile("cpy  z13.b, p5/z, #14\n\t");
+  asm volatile("cpy  z14.b, p10/z, #15\n\t");
+  asm volatile("cpy  z15.b, p15/z, #16\n\t");
+  asm volatile("cpy  z16.b, p0/z, #17\n\t");
+  asm volatile("cpy  z17.b, p5/z, #18\n\t");
+  asm volatile("cpy  z18.b, p10/z, #19\n\t");
+  asm volatile("cpy  z19.b, p15/z, #20\n\t");
+  asm volatile("cpy  z20.b, p0/z, #21\n\t");
+  asm volatile("cpy  z21.b, p5/z, #22\n\t");
+  asm volatile("cpy  z22.b, p10/z, #23\n\t");
+  asm volatile("cpy  z23.b, p15/z, #24\n\t");
+  asm volatile("cpy  z24.b, p0/z, #25\n\t");
+  asm volatile("cpy  z25.b, p5/z, #26\n\t");
+  asm volatile("cpy  z26.b, p10/z, #27\n\t");
+  asm volatile("cpy  z27.b, p15/z, #28\n\t");
+  asm volatile("cpy  z28.b, p0/z, #29\n\t");
+  asm volatile("cpy  z29.b, p5/z, #30\n\t");
+  asm volatile("cpy  z30.b, p10/z, #31\n\t");
+  asm volatile("cpy  z31.b, p15/z, #32\n\t");
+}
+
+int main() {
+  unsigned long hwcap = getauxval(AT_HWCAP);
+  unsigned long hwcap2 = getauxval(AT_HWCAP2);
+
+  unsigned int sve_is_enabled = hwcap & HWCAP_SVE;
+  unsigned int pauth_is_enabled = hwcap & HWCAP_PACA;
+  unsigned int mte_is_enabled = hwcap2 & HWCAP2_MTE;
+
+  if (sve_is_enabled) // check if SVE is present
+set_sve_registers();
+
+  return 0; // Set a break point here.
+}
Index: lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
===
--- /dev/null
+++ lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
@@ -0,0 +1,111 @@
+"""
+Test AArch64 dynamic register sets
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class RegisterCommandsTestCase(TestBase):
+
+def check_sve_register_size(self, set, name, expected):
+reg_value = set.GetChildMemberWithName(name)
+self.assertTrue(reg_value.IsValid(),
+'Expected a register named %s' % (name))
+self.assertEqual(reg_value.GetByteSize(), expected,
+ 'Expected a register %s

[Lldb-commits] [PATCH] D96463: [LLDB] Arm64/Linux test case for MTE and Pointer Authentication regset

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added inline comments.



Comment at: 
lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py:96
+if 'Scalable Vector Extension Registers' in registerSet.GetName():
+self.assertTrue(self.isAArch64SVE(
+), 'LLDB enabled AArch64 SVE register set when it was disabled 
by target.')

DavidSpickett wrote:
> Move the closing `)` onto the first line. Also I'd indent the line below like:
> ```
> self.assertTrue(self.isAArch64SVE(), 
> 'LLDB enabled AArch64 SVE register set when it was disabled by target.')
> self.
> ```
> 
> (applies to the next two as well)
Ack.



Comment at: 
lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py:106
+if 'Pointer Authentication Registers' in registerSet.GetName():
+self.assertTrue(self.isAArch64MTE(
+), 'LLDB enabled AArch64 Pointer Authentication register set 
when it was disabled by target.')

DavidSpickett wrote:
> Should be `isAArch64PAuth`
Ack.



Comment at: 
lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c:81-82
+  unsigned int sve_is_enabled = hwcap & HWCAP_SVE;
+  unsigned int pauth_is_enabled = hwcap & HWCAP_PACA;
+  unsigned int mte_is_enabled = hwcap2 & HWCAP2_MTE;
+

DavidSpickett wrote:
> These are unused since we get it from the cpuinfo, then you can inline the 
> sve check in the if below.
Ack.


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

https://reviews.llvm.org/D96463

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


[Lldb-commits] [PATCH] D96463: [LLDB] Arm64/Linux test case for MTE and Pointer Authentication regset

2021-03-09 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett added a comment.

Did you forget to add the changes? I don't see any diff for the last update.


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

https://reviews.llvm.org/D96463

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


[Lldb-commits] [PATCH] D96463: [LLDB] Arm64/Linux test case for MTE and Pointer Authentication regset

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 329273.
omjavaid added a comment.

FIxes stale diff uploaded by mistake.


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

https://reviews.llvm.org/D96463

Files:
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/test/API/commands/register/register/aarch64_dynamic_regset/Makefile
  
lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
  lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c

Index: lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c
===
--- /dev/null
+++ lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c
@@ -0,0 +1,81 @@
+#include 
+#include 
+
+#ifndef HWCAP2_MTE
+#define HWCAP2_MTE (1 << 18)
+#endif
+
+#ifndef HWCAP_PACA
+#define HWCAP_PACA (1 << 30)
+#endif
+
+void set_sve_registers() {
+  // AArch64 SVE extension ISA adds a new set of vector and predicate registers:
+  // 32 Z registers, 16 P registers, and 1 FFR register.
+  // Code below populates SVE registers to be read back by the debugger via
+  // ptrace interface at runtime.
+  // The P registers are predicate registers and hold one bit for each byte
+  // available in a Z vector register. For example, an SVE implementation with
+  // 1024-bit Z registers has 128-bit predicate registers.
+  // ptrue/pfalse instruction is used to set a predicate lane with a pattern.
+  // pattern is decided based on size specifier, b, h, s and d. if size
+  // specified is b all lanes will be set to 1. which is needed to set all bytes
+  // in a Z registers to the specified value.
+  asm volatile("setffr\n\t");
+  asm volatile("ptrue p0.b\n\t");
+  asm volatile("ptrue p1.h\n\t");
+  asm volatile("ptrue p2.s\n\t");
+  asm volatile("ptrue p3.d\n\t");
+  asm volatile("pfalse p4.b\n\t");
+  asm volatile("ptrue p5.b\n\t");
+  asm volatile("ptrue p6.h\n\t");
+  asm volatile("ptrue p7.s\n\t");
+  asm volatile("ptrue p8.d\n\t");
+  asm volatile("pfalse p9.b\n\t");
+  asm volatile("ptrue p10.b\n\t");
+  asm volatile("ptrue p11.h\n\t");
+  asm volatile("ptrue p12.s\n\t");
+  asm volatile("ptrue p13.d\n\t");
+  asm volatile("pfalse p14.b\n\t");
+  asm volatile("ptrue p15.b\n\t");
+
+  asm volatile("cpy  z0.b, p0/z, #1\n\t");
+  asm volatile("cpy  z1.b, p5/z, #2\n\t");
+  asm volatile("cpy  z2.b, p10/z, #3\n\t");
+  asm volatile("cpy  z3.b, p15/z, #4\n\t");
+  asm volatile("cpy  z4.b, p0/z, #5\n\t");
+  asm volatile("cpy  z5.b, p5/z, #6\n\t");
+  asm volatile("cpy  z6.b, p10/z, #7\n\t");
+  asm volatile("cpy  z7.b, p15/z, #8\n\t");
+  asm volatile("cpy  z8.b, p0/z, #9\n\t");
+  asm volatile("cpy  z9.b, p5/z, #10\n\t");
+  asm volatile("cpy  z10.b, p10/z, #11\n\t");
+  asm volatile("cpy  z11.b, p15/z, #12\n\t");
+  asm volatile("cpy  z12.b, p0/z, #13\n\t");
+  asm volatile("cpy  z13.b, p5/z, #14\n\t");
+  asm volatile("cpy  z14.b, p10/z, #15\n\t");
+  asm volatile("cpy  z15.b, p15/z, #16\n\t");
+  asm volatile("cpy  z16.b, p0/z, #17\n\t");
+  asm volatile("cpy  z17.b, p5/z, #18\n\t");
+  asm volatile("cpy  z18.b, p10/z, #19\n\t");
+  asm volatile("cpy  z19.b, p15/z, #20\n\t");
+  asm volatile("cpy  z20.b, p0/z, #21\n\t");
+  asm volatile("cpy  z21.b, p5/z, #22\n\t");
+  asm volatile("cpy  z22.b, p10/z, #23\n\t");
+  asm volatile("cpy  z23.b, p15/z, #24\n\t");
+  asm volatile("cpy  z24.b, p0/z, #25\n\t");
+  asm volatile("cpy  z25.b, p5/z, #26\n\t");
+  asm volatile("cpy  z26.b, p10/z, #27\n\t");
+  asm volatile("cpy  z27.b, p15/z, #28\n\t");
+  asm volatile("cpy  z28.b, p0/z, #29\n\t");
+  asm volatile("cpy  z29.b, p5/z, #30\n\t");
+  asm volatile("cpy  z30.b, p10/z, #31\n\t");
+  asm volatile("cpy  z31.b, p15/z, #32\n\t");
+}
+
+int main() {
+  if (getauxval(AT_HWCAP) & HWCAP_SVE) // check if SVE is present
+set_sve_registers();
+
+  return 0; // Set a break point here.
+}
Index: lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
===
--- /dev/null
+++ lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
@@ -0,0 +1,111 @@
+"""
+Test AArch64 dynamic register sets
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class RegisterCommandsTestCase(TestBase):
+
+def check_sve_register_size(self, set, name, expected):
+reg_value = set.GetChildMemberWithName(name)
+self.assertTrue(reg_value.IsValid(),
+'Expected a register named %s' % (name))
+self.assertEqual(reg_value.GetByteSize(), expected,
+ 'Expected a register %s size == %i bytes' % (name, expected))
+
+def sve_regs_read_dynamic(self, sve_registers):
+vg_reg = sve_registers.GetChildMemberWithName("vg")
+vg_reg_value = sve_registers.GetChildMemberWithName(
+ 

[Lldb-commits] [PATCH] D96463: [LLDB] Arm64/Linux test case for MTE and Pointer Authentication regset

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added a comment.

In D96463#2613498 , @DavidSpickett 
wrote:

> Did you forget to add the changes? I don't see any diff for the last update.

Sorry about that. Check the latest diff should be fixed now.


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

https://reviews.llvm.org/D96463

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


[Lldb-commits] [PATCH] D96463: [LLDB] Arm64/Linux test case for MTE and Pointer Authentication regset

2021-03-09 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett accepted this revision.
DavidSpickett added a comment.
This revision is now accepted and ready to land.

LGTM with that one thing fixed.




Comment at: 
lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c:4-10
+#ifndef HWCAP2_MTE
+#define HWCAP2_MTE (1 << 18)
+#endif
+
+#ifndef HWCAP_PACA
+#define HWCAP_PACA (1 << 30)
+#endif

These can go too.


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

https://reviews.llvm.org/D96463

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


[Lldb-commits] [PATCH] D96459: [LLDB] Pull AuxVec info into NativeRegisterContextLinux_arm64

2021-03-09 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett accepted this revision.
DavidSpickett added a comment.
This revision is now accepted and ready to land.

LGTM


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

https://reviews.llvm.org/D96459

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


[Lldb-commits] [PATCH] D96463: [LLDB] Arm64/Linux test case for MTE and Pointer Authentication regset

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 329280.

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

https://reviews.llvm.org/D96463

Files:
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/test/API/commands/register/register/aarch64_dynamic_regset/Makefile
  
lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
  lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c

Index: lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c
===
--- /dev/null
+++ lldb/test/API/commands/register/register/aarch64_dynamic_regset/main.c
@@ -0,0 +1,72 @@
+#include 
+
+void set_sve_registers() {
+  // AArch64 SVE extension ISA adds a new set of vector and predicate registers:
+  // 32 Z registers, 16 P registers, and 1 FFR register.
+  // Code below populates SVE registers to be read back by the debugger via
+  // ptrace interface at runtime.
+  // The P registers are predicate registers and hold one bit for each byte
+  // available in a Z vector register. For example, an SVE implementation with
+  // 1024-bit Z registers has 128-bit predicate registers.
+  // ptrue/pfalse instruction is used to set a predicate lane with a pattern.
+  // pattern is decided based on size specifier, b, h, s and d. if size
+  // specified is b all lanes will be set to 1. which is needed to set all bytes
+  // in a Z registers to the specified value.
+  asm volatile("setffr\n\t");
+  asm volatile("ptrue p0.b\n\t");
+  asm volatile("ptrue p1.h\n\t");
+  asm volatile("ptrue p2.s\n\t");
+  asm volatile("ptrue p3.d\n\t");
+  asm volatile("pfalse p4.b\n\t");
+  asm volatile("ptrue p5.b\n\t");
+  asm volatile("ptrue p6.h\n\t");
+  asm volatile("ptrue p7.s\n\t");
+  asm volatile("ptrue p8.d\n\t");
+  asm volatile("pfalse p9.b\n\t");
+  asm volatile("ptrue p10.b\n\t");
+  asm volatile("ptrue p11.h\n\t");
+  asm volatile("ptrue p12.s\n\t");
+  asm volatile("ptrue p13.d\n\t");
+  asm volatile("pfalse p14.b\n\t");
+  asm volatile("ptrue p15.b\n\t");
+
+  asm volatile("cpy  z0.b, p0/z, #1\n\t");
+  asm volatile("cpy  z1.b, p5/z, #2\n\t");
+  asm volatile("cpy  z2.b, p10/z, #3\n\t");
+  asm volatile("cpy  z3.b, p15/z, #4\n\t");
+  asm volatile("cpy  z4.b, p0/z, #5\n\t");
+  asm volatile("cpy  z5.b, p5/z, #6\n\t");
+  asm volatile("cpy  z6.b, p10/z, #7\n\t");
+  asm volatile("cpy  z7.b, p15/z, #8\n\t");
+  asm volatile("cpy  z8.b, p0/z, #9\n\t");
+  asm volatile("cpy  z9.b, p5/z, #10\n\t");
+  asm volatile("cpy  z10.b, p10/z, #11\n\t");
+  asm volatile("cpy  z11.b, p15/z, #12\n\t");
+  asm volatile("cpy  z12.b, p0/z, #13\n\t");
+  asm volatile("cpy  z13.b, p5/z, #14\n\t");
+  asm volatile("cpy  z14.b, p10/z, #15\n\t");
+  asm volatile("cpy  z15.b, p15/z, #16\n\t");
+  asm volatile("cpy  z16.b, p0/z, #17\n\t");
+  asm volatile("cpy  z17.b, p5/z, #18\n\t");
+  asm volatile("cpy  z18.b, p10/z, #19\n\t");
+  asm volatile("cpy  z19.b, p15/z, #20\n\t");
+  asm volatile("cpy  z20.b, p0/z, #21\n\t");
+  asm volatile("cpy  z21.b, p5/z, #22\n\t");
+  asm volatile("cpy  z22.b, p10/z, #23\n\t");
+  asm volatile("cpy  z23.b, p15/z, #24\n\t");
+  asm volatile("cpy  z24.b, p0/z, #25\n\t");
+  asm volatile("cpy  z25.b, p5/z, #26\n\t");
+  asm volatile("cpy  z26.b, p10/z, #27\n\t");
+  asm volatile("cpy  z27.b, p15/z, #28\n\t");
+  asm volatile("cpy  z28.b, p0/z, #29\n\t");
+  asm volatile("cpy  z29.b, p5/z, #30\n\t");
+  asm volatile("cpy  z30.b, p10/z, #31\n\t");
+  asm volatile("cpy  z31.b, p15/z, #32\n\t");
+}
+
+int main() {
+  if (getauxval(AT_HWCAP) & HWCAP_SVE) // check if SVE is present
+set_sve_registers();
+
+  return 0; // Set a break point here.
+}
Index: lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
===
--- /dev/null
+++ lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
@@ -0,0 +1,111 @@
+"""
+Test AArch64 dynamic register sets
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class RegisterCommandsTestCase(TestBase):
+
+def check_sve_register_size(self, set, name, expected):
+reg_value = set.GetChildMemberWithName(name)
+self.assertTrue(reg_value.IsValid(),
+'Expected a register named %s' % (name))
+self.assertEqual(reg_value.GetByteSize(), expected,
+ 'Expected a register %s size == %i bytes' % (name, expected))
+
+def sve_regs_read_dynamic(self, sve_registers):
+vg_reg = sve_registers.GetChildMemberWithName("vg")
+vg_reg_value = sve_registers.GetChildMemberWithName(
+"vg").GetValueAsUnsigned()
+
+z_reg_size = vg_reg_value * 8
+p_reg_size = int(z_reg_size / 8)
+
+for i in range(32):
+z_regs_value = '{' + \
+

[Lldb-commits] [PATCH] D96634: [lldb][JITLoaderGDB] Test debug support in llvm-jitlink

2021-03-09 Thread Stefan Gränitz via Phabricator via lldb-commits
sgraenitz updated this revision to Diff 329301.
sgraenitz added a comment.

For the entry point, prefer lli over llvm-jitlink. D97339 
 added debug support for JITLink in lli.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96634

Files:
  lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
  lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
  lldb/test/Shell/Breakpoint/jitbp_elf.test


Index: lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
===
--- lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
+++ lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
@@ -1,11 +1,21 @@
 # REQUIRES: target-x86_64
 # XFAIL: system-windows
 
-# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll 
%p/Inputs/jitbp.cpp
-# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
-o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s
+# RuntimeDyld can be used to link and load emitted code for both, MCJIT and 
Orc.
+#
+# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf \
+# RUN:-o %t.ll %p/Inputs/jitbp.cpp
+#
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
\
+# RUN:  -o 'run --jit-kind=mcjit %t.ll' \
+# RUN:  lli | FileCheck %s
+#
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
\
+# RUN:  -o 'run --jit-kind=orc-lazy --per-module-lazy 
--jit-linker=rtdyld %t.ll' \
+# RUN:  lli | FileCheck %s
 
 # CHECK: Breakpoint 1: no locations (pending).
-# CHECK: (lldb) run -jit-kind=mcjit {{.*}}/jitbp_elf.test.tmp.ll
+# CHECK: (lldb) run {{.*}}
 # CHECK: Process {{.*}} stopped
 # CHECK: JIT(0x{{.*}})`jitbp() at jitbp.cpp:1:15
 # CHECK: -> 1int jitbp() { return 0; }
Index: lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
===
--- lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
+++ lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
@@ -1,11 +1,16 @@
 # REQUIRES: target-x86_64
 # XFAIL: system-windows
 
-# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll 
%p/Inputs/jitbp.cpp
-# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
-o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s
+# JITLink is the Orc-specific JIT linker implementation.
+#
+# RUN: %clang -g -S -emit-llvm -fPIC --target=x86_64-unknown-unknown-elf \
+# RUN:-o %t.ll %p/Inputs/jitbp.cpp
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
\
+# RUN:  -o 'run --jit-kind=orc-lazy --per-module-lazy 
--jit-linker=jitlink %t.ll' \
+# RUN:  lli | FileCheck %s
 
 # CHECK: Breakpoint 1: no locations (pending).
-# CHECK: (lldb) run -jit-kind=mcjit {{.*}}/jitbp_elf.test.tmp.ll
+# CHECK: (lldb) run {{.*}}
 # CHECK: Process {{.*}} stopped
 # CHECK: JIT(0x{{.*}})`jitbp() at jitbp.cpp:1:15
 # CHECK: -> 1int jitbp() { return 0; }


Index: lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
===
--- lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
+++ lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
@@ -1,11 +1,21 @@
 # REQUIRES: target-x86_64
 # XFAIL: system-windows
 
-# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll %p/Inputs/jitbp.cpp
-# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' -o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s
+# RuntimeDyld can be used to link and load emitted code for both, MCJIT and Orc.
+#
+# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf \
+# RUN:-o %t.ll %p/Inputs/jitbp.cpp
+#
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' \
+# RUN:  -o 'run --jit-kind=mcjit %t.ll' \
+# RUN:  lli | FileCheck %s
+#
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' \
+# RUN:  -o 'run --jit-kind=orc-lazy --per-module-lazy --jit-linker=rtdyld %t.ll' \
+# RUN:  lli | FileCheck %s
 
 # CHECK: Breakpoint 1: no locations (pending).
-# CHECK: (lldb) run -jit-kind=mcjit {{.*}}/jitbp_elf.test.tmp.ll
+# CHECK: (lldb) run {{.*}}
 # CHECK: Process {{.*}} stopped
 # CHECK: JIT(0x{{.*}})`jitbp() at jitbp.cpp:1:15
 # CHECK: -> 1int jitbp() { return 0; }
Index: lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
===
--- lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
+++ lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
@@ -1,11 +1,16 @@
 # REQUIRES: target-x86_64
 # XFAIL: system-windows
 
-# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll %p/Inputs/jitbp.cpp
-# RUN: %lldb -b -o 'settings set plugin.jit-lo

[Lldb-commits] [lldb] 2ff533c - [lldb][JITLoaderGDB] Test debug support in JITLink

2021-03-09 Thread Stefan Gränitz via lldb-commits

Author: Stefan Gränitz
Date: 2021-03-09T14:10:52+01:00
New Revision: 2ff533cba18af853fa0688c101f7ac7e7b594db7

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

LOG: [lldb][JITLoaderGDB] Test debug support in JITLink

LLVM OrcJIT is shifting from RuntimeDyld to JITLink. Starting with D96627 I am 
planning to add debug support. It would be great to have test coverage for it 
in LLDB early on.

Reviewed By: labath

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

Added: 
lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test

Modified: 


Removed: 
lldb/test/Shell/Breakpoint/jitbp_elf.test



diff  --git a/lldb/test/Shell/Breakpoint/jitbp_elf.test 
b/lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
similarity index 54%
rename from lldb/test/Shell/Breakpoint/jitbp_elf.test
rename to lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
index c637dba75b05..ccaf9d4b96c2 100644
--- a/lldb/test/Shell/Breakpoint/jitbp_elf.test
+++ b/lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
@@ -1,11 +1,16 @@
 # REQUIRES: target-x86_64
 # XFAIL: system-windows
 
-# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll 
%p/Inputs/jitbp.cpp
-# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
-o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s
+# JITLink is the Orc-specific JIT linker implementation.
+#
+# RUN: %clang -g -S -emit-llvm -fPIC --target=x86_64-unknown-unknown-elf \
+# RUN:-o %t.ll %p/Inputs/jitbp.cpp
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
\
+# RUN:  -o 'run --jit-kind=orc-lazy --per-module-lazy 
--jit-linker=jitlink %t.ll' \
+# RUN:  lli | FileCheck %s
 
 # CHECK: Breakpoint 1: no locations (pending).
-# CHECK: (lldb) run -jit-kind=mcjit {{.*}}/jitbp_elf.test.tmp.ll
+# CHECK: (lldb) run {{.*}}
 # CHECK: Process {{.*}} stopped
 # CHECK: JIT(0x{{.*}})`jitbp() at jitbp.cpp:1:15
 # CHECK: -> 1int jitbp() { return 0; }

diff  --git a/lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test 
b/lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
new file mode 100644
index ..7f1bd9dadbdc
--- /dev/null
+++ b/lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
@@ -0,0 +1,24 @@
+# REQUIRES: target-x86_64
+# XFAIL: system-windows
+
+# RuntimeDyld can be used to link and load emitted code for both, MCJIT and 
Orc.
+#
+# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf \
+# RUN:-o %t.ll %p/Inputs/jitbp.cpp
+#
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
\
+# RUN:  -o 'run --jit-kind=mcjit %t.ll' \
+# RUN:  lli | FileCheck %s
+#
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
\
+# RUN:  -o 'run --jit-kind=orc-lazy --per-module-lazy 
--jit-linker=rtdyld %t.ll' \
+# RUN:  lli | FileCheck %s
+
+# CHECK: Breakpoint 1: no locations (pending).
+# CHECK: (lldb) run {{.*}}
+# CHECK: Process {{.*}} stopped
+# CHECK: JIT(0x{{.*}})`jitbp() at jitbp.cpp:1:15
+# CHECK: -> 1int jitbp() { return 0; }
+# CHECK:   ^
+# CHECK:2int main() { return jitbp(); }
+# CHECK: Process {{.*}} launched: {{.*}}



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


[Lldb-commits] [PATCH] D96634: [lldb][JITLoaderGDB] Test debug support in llvm-jitlink

2021-03-09 Thread Stefan Gränitz via Phabricator via lldb-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2ff533cba18a: [lldb][JITLoaderGDB] Test debug support in 
JITLink (authored by sgraenitz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96634

Files:
  lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
  lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
  lldb/test/Shell/Breakpoint/jitbp_elf.test


Index: lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
===
--- lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
+++ lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
@@ -1,11 +1,21 @@
 # REQUIRES: target-x86_64
 # XFAIL: system-windows
 
-# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll 
%p/Inputs/jitbp.cpp
-# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
-o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s
+# RuntimeDyld can be used to link and load emitted code for both, MCJIT and 
Orc.
+#
+# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf \
+# RUN:-o %t.ll %p/Inputs/jitbp.cpp
+#
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
\
+# RUN:  -o 'run --jit-kind=mcjit %t.ll' \
+# RUN:  lli | FileCheck %s
+#
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
\
+# RUN:  -o 'run --jit-kind=orc-lazy --per-module-lazy 
--jit-linker=rtdyld %t.ll' \
+# RUN:  lli | FileCheck %s
 
 # CHECK: Breakpoint 1: no locations (pending).
-# CHECK: (lldb) run -jit-kind=mcjit {{.*}}/jitbp_elf.test.tmp.ll
+# CHECK: (lldb) run {{.*}}
 # CHECK: Process {{.*}} stopped
 # CHECK: JIT(0x{{.*}})`jitbp() at jitbp.cpp:1:15
 # CHECK: -> 1int jitbp() { return 0; }
Index: lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
===
--- lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
+++ lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
@@ -1,11 +1,16 @@
 # REQUIRES: target-x86_64
 # XFAIL: system-windows
 
-# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll 
%p/Inputs/jitbp.cpp
-# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
-o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s
+# JITLink is the Orc-specific JIT linker implementation.
+#
+# RUN: %clang -g -S -emit-llvm -fPIC --target=x86_64-unknown-unknown-elf \
+# RUN:-o %t.ll %p/Inputs/jitbp.cpp
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
\
+# RUN:  -o 'run --jit-kind=orc-lazy --per-module-lazy 
--jit-linker=jitlink %t.ll' \
+# RUN:  lli | FileCheck %s
 
 # CHECK: Breakpoint 1: no locations (pending).
-# CHECK: (lldb) run -jit-kind=mcjit {{.*}}/jitbp_elf.test.tmp.ll
+# CHECK: (lldb) run {{.*}}
 # CHECK: Process {{.*}} stopped
 # CHECK: JIT(0x{{.*}})`jitbp() at jitbp.cpp:1:15
 # CHECK: -> 1int jitbp() { return 0; }


Index: lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
===
--- lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
+++ lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test
@@ -1,11 +1,21 @@
 # REQUIRES: target-x86_64
 # XFAIL: system-windows
 
-# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll %p/Inputs/jitbp.cpp
-# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' -o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s
+# RuntimeDyld can be used to link and load emitted code for both, MCJIT and Orc.
+#
+# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf \
+# RUN:-o %t.ll %p/Inputs/jitbp.cpp
+#
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' \
+# RUN:  -o 'run --jit-kind=mcjit %t.ll' \
+# RUN:  lli | FileCheck %s
+#
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' \
+# RUN:  -o 'run --jit-kind=orc-lazy --per-module-lazy --jit-linker=rtdyld %t.ll' \
+# RUN:  lli | FileCheck %s
 
 # CHECK: Breakpoint 1: no locations (pending).
-# CHECK: (lldb) run -jit-kind=mcjit {{.*}}/jitbp_elf.test.tmp.ll
+# CHECK: (lldb) run {{.*}}
 # CHECK: Process {{.*}} stopped
 # CHECK: JIT(0x{{.*}})`jitbp() at jitbp.cpp:1:15
 # CHECK: -> 1int jitbp() { return 0; }
Index: lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
===
--- lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
+++ lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
@@ -1,11 +1,16 @@
 # REQUIRES: target-x86_64
 # XFAIL: system-windows
 
-# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll %p/Inputs/jitbp.cpp
-# RUN: %lldb -b 

[Lldb-commits] [PATCH] D95601: [lldb][AArch64] Add memory tag reading to lldb-server

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added inline comments.



Comment at: lldb/test/API/tools/lldb-server/memory-tagging/main.c:13
+  // Wait for lldb-server to stop us
+  while (1) {
+  }

infinite loop in test program may not be a good idea.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95601

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


[Lldb-commits] [PATCH] D95601: [lldb][AArch64] Add memory tag reading to lldb-server

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added inline comments.



Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1357
+
+  if (error.Fail())
+return error;

DavidSpickett wrote:
> DavidSpickett wrote:
> > DavidSpickett wrote:
> > > omjavaid wrote:
> > > > ptrace request is a success if number of tags requested is not equal to 
> > > > no of tags read? If not then this and following condition may be 
> > > > redundant.
> > > Well ptracewrapper doesn't check the iovec, but I'll check the kernel 
> > > source to see if it's actually possible for it to fail that way.
> > In `linux/arch/arm64/kernel/mte.c` `__access_remote_tags` there is a 
> > comment:
> > ```
> > +/*
> > + * Access MTE tags in another process' address space as given in mm. Update
> > + * the number of tags copied. Return 0 if any tags copied, error otherwise.
> > + * Inspired by __access_remote_vm().
> > + */
> > ```
> > 
> > *any tags* being the key words.
> > 
> > So the scenario is:
> > * ask to read from addr X in page 0, with length of pagesize+some so the 
> > range spills into page 1
> > * kernel can access page 0, reads tags until the end of the page
> > * tries to access page 1 to read the rest, fails, returns 0 (success) since 
> > *some* tags were read
> > * we see the ptrace call succeeded but with less tags than we expected
> > 
> > I don't see it's worth dealing with this corner case here since lldb will 
> > look before it leaps. It would have errored much earlier here because 
> > either page 1 isn't in the tracee's memory regions or it wasn't MTE enabled.
> > 
> > 
> Added a comment in the code too.
This means emitting less than requested number of tags is legit. However we 
have set tags vector size equal to whatever we have requested. We set error 
string which is actually not being used anywhere and can be removed in favor of 
a log message to help with debugging if needed.

Also we need to resize the vector after ptrace request so we use this size in 
gdb remote reply.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95601

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


[Lldb-commits] [lldb] 2e82608 - [lldb] Fix a bug in D96779 (shared lib directory logic)

2021-03-09 Thread Pavel Labath via lldb-commits

Author: Pavel Labath
Date: 2021-03-09T15:15:45+01:00
New Revision: 2e826088b9832067994e0348fc768b81632be687

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

LOG: [lldb] Fix a bug in D96779 (shared lib directory logic)

This function would fail in debug builds, as the two usages of the
LLDB_PYTHON_RELATIVE_LIBDIR macro would expand to two distinct strings.
The path iterator macros don't support that.

Use a temporary variable to ensure everything points to a single string.

Added: 


Modified: 
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index b3f72066195b..c4cc67cf7ab3 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -421,8 +421,9 @@ void ScriptInterpreterPython::SharedLibraryDirectoryHelper(
   if (this_file.GetFileNameExtension() == ConstString(".pyd")) {
 this_file.RemoveLastPathComponent(); // _lldb.pyd or _lldb_d.pyd
 this_file.RemoveLastPathComponent(); // lldb
-for (auto it = llvm::sys::path::begin(LLDB_PYTHON_RELATIVE_LIBDIR),
-  end = llvm::sys::path::end(LLDB_PYTHON_RELATIVE_LIBDIR);
+llvm::StringRef libdir = LLDB_PYTHON_RELATIVE_LIBDIR;
+for (auto it = llvm::sys::path::begin(libdir),
+  end = llvm::sys::path::end(libdir);
  it != end; ++it)
   this_file.RemoveLastPathComponent();
 this_file.AppendPathComponent("bin");



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


[Lldb-commits] [PATCH] D95601: [lldb][AArch64] Add memory tag reading to lldb-server

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added inline comments.



Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1345
+
+  tags.resize((range.GetByteSize() / details->manager->GetGranuleSize()) *
+  details->manager->GetBytesPerTag());

is there a difference between Granule and GranuleSize?



Comment at: 
lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py:102
+# Here we read from 1/2 way through a granule, into the next. Expands 
to 2 granules
+self.check_qmemtags_response("{:x},10:1".format(buf_address+64-8), 
"m0304")

Do we test partial read case here? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95601

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


[Lldb-commits] [PATCH] D96458: [LLDB] Add support for Arm64/Linux dynamic register sets

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added a comment.

@labath @rovka any further comments on this one?


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

https://reviews.llvm.org/D96458

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


[Lldb-commits] [PATCH] D96458: [LLDB] Add support for Arm64/Linux dynamic register sets

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added a comment.

In D96458#2613244 , @labath wrote:

> In D96458#2578760 , @omjavaid wrote:
>
>> In D96458#2566347 , @labath wrote:
>>
>>> I'm sorry, my response times are pretty slow these days.
>>>
>>> I'm thinking about this `ConfigureRegisterInfos` business. I get that the 
>>> vector length is variable, and so we need to refresh it after every stop. 
>>> However, the set of enabled extensions seems more static.
>>>
>>> Is it possible for that to change during the lifetime of the process? I'd 
>>> guess not, because otherwise we'd have to also resend the register lists 
>>> after every stop. And, if that's the case, I'm wondering if there's a way 
>>> to reflect this static-ness in the code. For example, by doing this setup 
>>> in the constructor, instead of a late `ConfigureRegisterInfos` call. IIRC, 
>>> the register contexts are created when the thread is stopped, so it should 
>>> be possible to fetch the information about supported registers quite early.
>>>
>>> What do you think?
>>
>> Yes that is doable. I ll move ConfigureRegisterInfos part into constructor.
>
> There's still one `ConfigureRegisterInfos` call in the 
> `RegisterContextCorePOSIX_arm64::ConfigureRegisterContext` function. Is that 
> an omission, or is it intentional (i.e., needed to support some arm feature)? 
> Because, if that's intentional, then the moving the setup to the constructor 
> does not achieve what I wanted, as the set of registers can be overridden 
> afterwards. It also means we need to have a bigger discussion about how to 
> communicate the changed registers between the client and server. OTOH, if 
> it's not intentional, then I'd like to remove that call, to make it obvious 
> that the set of registers cannot change (only their length, for sve registers 
> and such).
>
> So, let me try to ask a direct question: Is there any situation in which the 
> set of registers accessible to the inferior (and lldb-server) can change 
> during the lifetime of a single process. If so, what is it?

ConfigureRegisterContext is called only once in the lifetime of a core from 
RegisterContextCorePOSIX_arm64 constructor. A process registers cannot change 
during execution which is what made basis of this change. for 
NativeRegisterContextLinux_arm64 I moved the ConfigureRegisterInfos logic out 
of configure register context because it will be called again and again during 
execution. But for RegisterContextCorePOSIX_arm64 we call it once in the 
constructor so its safe to keep the function.


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

https://reviews.llvm.org/D96458

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


[Lldb-commits] [PATCH] D96458: [LLDB] Add support for Arm64/Linux dynamic register sets

2021-03-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D96458#2613894 , @omjavaid wrote:

> ConfigureRegisterContext is called only once in the lifetime of a core from 
> RegisterContextCorePOSIX_arm64 constructor. A process registers cannot change 
> during execution which is what made basis of this change. for 
> NativeRegisterContextLinux_arm64 I moved the ConfigureRegisterInfos logic out 
> of configure register context because it will be called again and again 
> during execution. But for RegisterContextCorePOSIX_arm64 we call it once in 
> the constructor so its safe to keep the function.

Ok, I understand what's happening now -- thanks for re-iterating. I have 
managed to miss the fact that this patch deals with both core file and live 
register contexts.

In that case, I'd like to go one step further, and remove the "configuration" 
operation from the `RegisterInfoPOSIX_arm64` class as well (by making it a part 
of the construction). It should be possible to do that by fetching the 
information needed to determine the registers before the class is instantiated. 
For the live context, that could be done inside the 
`CreateHostNativeRegisterContextLinux` function. For the core file context, we 
could create a similar factory function as well. I.e. move the construction of 
`RegisterInfoPOSIX_arm64` from ThreadElfCore into some static function inside 
`RegisterContextCorePOSIX_arm64` -- this function could examine the core data 
to determine the registers and construct the appropriate info class.


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

https://reviews.llvm.org/D96458

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


[Lldb-commits] [PATCH] D96458: [LLDB] Add support for Arm64/Linux dynamic register sets

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added a comment.

In D96458#2613948 , @labath wrote:

> In D96458#2613894 , @omjavaid wrote:
>
>> ConfigureRegisterContext is called only once in the lifetime of a core from 
>> RegisterContextCorePOSIX_arm64 constructor. A process registers cannot 
>> change during execution which is what made basis of this change. for 
>> NativeRegisterContextLinux_arm64 I moved the ConfigureRegisterInfos logic 
>> out of configure register context because it will be called again and again 
>> during execution. But for RegisterContextCorePOSIX_arm64 we call it once in 
>> the constructor so its safe to keep the function.
>
> Ok, I understand what's happening now -- thanks for re-iterating. I have 
> managed to miss the fact that this patch deals with both core file and live 
> register contexts.
>
> In that case, I'd like to go one step further, and remove the "configuration" 
> operation from the `RegisterInfoPOSIX_arm64` class as well (by making it a 
> part of the construction). It should be possible to do that by fetching the 
> information needed to determine the registers before the class is 
> instantiated. For the live context, that could be done inside the 
> `CreateHostNativeRegisterContextLinux` function. For the core file context, 
> we could create a similar factory function as well. I.e. move the 
> construction of `RegisterInfoPOSIX_arm64` from ThreadElfCore into some static 
> function inside `RegisterContextCorePOSIX_arm64` -- this function could 
> examine the core data to determine the registers and construct the 
> appropriate info class.

hmm .. in that case we will have to defer creation of RegisterInfoPOSIX_arm64 
as you said above. I will create a function that will allow us to update 
unique_ptr m_register_info_up in RegisterContextPOSIX_arm64 and also another 
function for doing the same for m_register_info_interface_up object in 
NativeRegisterContextRegisterInfo class. Rest will be same as you suggested 
above.


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

https://reviews.llvm.org/D96458

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


[Lldb-commits] [PATCH] D96459: [LLDB] Pull AuxVec info into NativeRegisterContextLinux_arm64

2021-03-09 Thread Pavel Labath via Phabricator via lldb-commits
labath requested changes to this revision.
labath added inline comments.
This revision now requires changes to proceed.



Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:2038
+  return m_aux_vector->GetAuxValue(type);
+}

DavidSpickett wrote:
> Do we not get this from the protected `GetAuxValue` on `NativeProcessELF`?
Indeed. We should not reimplement that here. I don't think there's any reason 
the NativeProcessELF function can't be public.


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

https://reviews.llvm.org/D96459

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


[Lldb-commits] [PATCH] D96459: [LLDB] Pull AuxVec info into NativeRegisterContextLinux_arm64

2021-03-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h:169
 
+  void QueryAuxvForOptionalRegset(Flags &opt_regsets);
+

This should be a result instead of a by-ref argument.


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

https://reviews.llvm.org/D96459

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


[Lldb-commits] [PATCH] D96458: [LLDB] Add support for Arm64/Linux dynamic register sets

2021-03-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D96458#2614076 , @omjavaid wrote:

> In D96458#2613948 , @labath wrote:
>
>> In D96458#2613894 , @omjavaid wrote:
>>
>>> ConfigureRegisterContext is called only once in the lifetime of a core from 
>>> RegisterContextCorePOSIX_arm64 constructor. A process registers cannot 
>>> change during execution which is what made basis of this change. for 
>>> NativeRegisterContextLinux_arm64 I moved the ConfigureRegisterInfos logic 
>>> out of configure register context because it will be called again and again 
>>> during execution. But for RegisterContextCorePOSIX_arm64 we call it once in 
>>> the constructor so its safe to keep the function.
>>
>> Ok, I understand what's happening now -- thanks for re-iterating. I have 
>> managed to miss the fact that this patch deals with both core file and live 
>> register contexts.
>>
>> In that case, I'd like to go one step further, and remove the 
>> "configuration" operation from the `RegisterInfoPOSIX_arm64` class as well 
>> (by making it a part of the construction). It should be possible to do that 
>> by fetching the information needed to determine the registers before the 
>> class is instantiated. For the live context, that could be done inside the 
>> `CreateHostNativeRegisterContextLinux` function. For the core file context, 
>> we could create a similar factory function as well. I.e. move the 
>> construction of `RegisterInfoPOSIX_arm64` from ThreadElfCore into some 
>> static function inside `RegisterContextCorePOSIX_arm64` -- this function 
>> could examine the core data to determine the registers and construct the 
>> appropriate info class.
>
> hmm .. in that case we will have to defer creation of RegisterInfoPOSIX_arm64 
> as you said above. I will create a function that will allow us to update 
> unique_ptr m_register_info_up in RegisterContextPOSIX_arm64

That would make the registers of a RegisterInfoPOSIX_arm64 instance immutable 
(which is good), but that function would allow one to mutate the 
RegisterContextPOSIX_arm64 class in the middle of its lifetime by swapping the 
register info backing it (which is exactly what I'm trying to avoid). I'm 
trying to create an apis that is impossible/hard to use incorrectly. I'd like 
to avoid this kind of "configuration" functions unless they are really 
necessary. I could be wrong, but right now I don't see a reason why they'd be 
necessary.


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

https://reviews.llvm.org/D96458

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


[Lldb-commits] [PATCH] D96458: [LLDB] Add support for Arm64/Linux dynamic register sets

2021-03-09 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added a comment.

In D96458#2614101 , @labath wrote:

> In D96458#2614076 , @omjavaid wrote:
>
>> In D96458#2613948 , @labath wrote:
>>
>>> In D96458#2613894 , @omjavaid 
>>> wrote:
>>>
 ConfigureRegisterContext is called only once in the lifetime of a core 
 from RegisterContextCorePOSIX_arm64 constructor. A process registers 
 cannot change during execution which is what made basis of this change. 
 for NativeRegisterContextLinux_arm64 I moved the ConfigureRegisterInfos 
 logic out of configure register context because it will be called again 
 and again during execution. But for RegisterContextCorePOSIX_arm64 we call 
 it once in the constructor so its safe to keep the function.
>>>
>>> Ok, I understand what's happening now -- thanks for re-iterating. I have 
>>> managed to miss the fact that this patch deals with both core file and live 
>>> register contexts.
>>>
>>> In that case, I'd like to go one step further, and remove the 
>>> "configuration" operation from the `RegisterInfoPOSIX_arm64` class as well 
>>> (by making it a part of the construction). It should be possible to do that 
>>> by fetching the information needed to determine the registers before the 
>>> class is instantiated. For the live context, that could be done inside the 
>>> `CreateHostNativeRegisterContextLinux` function. For the core file context, 
>>> we could create a similar factory function as well. I.e. move the 
>>> construction of `RegisterInfoPOSIX_arm64` from ThreadElfCore into some 
>>> static function inside `RegisterContextCorePOSIX_arm64` -- this function 
>>> could examine the core data to determine the registers and construct the 
>>> appropriate info class.
>>
>> hmm .. in that case we will have to defer creation of 
>> RegisterInfoPOSIX_arm64 as you said above. I will create a function that 
>> will allow us to update unique_ptr m_register_info_up in 
>> RegisterContextPOSIX_arm64
>
> That would make the registers of a RegisterInfoPOSIX_arm64 instance immutable 
> (which is good), but that function would allow one to mutate the 
> RegisterContextPOSIX_arm64 class in the middle of its lifetime by swapping 
> the register info backing it (which is exactly what I'm trying to avoid). I'm 
> trying to create an apis that is impossible/hard to use incorrectly. I'd like 
> to avoid this kind of "configuration" functions unless they are really 
> necessary. I could be wrong, but right now I don't see a reason why they'd be 
> necessary.

We cannot calculated register set configuration untill we create register 
context. Both RegisterContextPOSIX_arm64 and NativeRegisterContextRegisterInfo 
are base class objects for their corresponding register contexts and its not 
trivial to make them immutable without serious refactoring.


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

https://reviews.llvm.org/D96458

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


[Lldb-commits] [PATCH] D95601: [lldb][AArch64] Add memory tag reading to lldb-server

2021-03-09 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett added inline comments.



Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1345
+
+  tags.resize((range.GetByteSize() / details->manager->GetGranuleSize()) *
+  details->manager->GetBytesPerTag());

omjavaid wrote:
> is there a difference between Granule and GranuleSize?
Granule is used to mean the current Granule you're in. So if you were at 
address 0x10 you'd be in the [0x10,0x20) granule.
GranuleSize is the size of each granule.

If I saw `manager->GetGranule` I'd expect it to be something like 
`std::pair GetGranule(addr_t addr);`.
As in, tell me which granule I'm in.

Though I admit this is more an issue of "ExpandToGranule" not being clear 
enough, rather than "GetGranuleSize" being too redunant.
AlignToGranule(s) perhaps? But then you ask "align how", hence "ExpandTo". 
Anyway.



Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1357
+
+  if (error.Fail())
+return error;

omjavaid wrote:
> DavidSpickett wrote:
> > DavidSpickett wrote:
> > > DavidSpickett wrote:
> > > > omjavaid wrote:
> > > > > ptrace request is a success if number of tags requested is not equal 
> > > > > to no of tags read? If not then this and following condition may be 
> > > > > redundant.
> > > > Well ptracewrapper doesn't check the iovec, but I'll check the kernel 
> > > > source to see if it's actually possible for it to fail that way.
> > > In `linux/arch/arm64/kernel/mte.c` `__access_remote_tags` there is a 
> > > comment:
> > > ```
> > > +/*
> > > + * Access MTE tags in another process' address space as given in mm. 
> > > Update
> > > + * the number of tags copied. Return 0 if any tags copied, error 
> > > otherwise.
> > > + * Inspired by __access_remote_vm().
> > > + */
> > > ```
> > > 
> > > *any tags* being the key words.
> > > 
> > > So the scenario is:
> > > * ask to read from addr X in page 0, with length of pagesize+some so the 
> > > range spills into page 1
> > > * kernel can access page 0, reads tags until the end of the page
> > > * tries to access page 1 to read the rest, fails, returns 0 (success) 
> > > since *some* tags were read
> > > * we see the ptrace call succeeded but with less tags than we expected
> > > 
> > > I don't see it's worth dealing with this corner case here since lldb will 
> > > look before it leaps. It would have errored much earlier here because 
> > > either page 1 isn't in the tracee's memory regions or it wasn't MTE 
> > > enabled.
> > > 
> > > 
> > Added a comment in the code too.
> This means emitting less than requested number of tags is legit. However we 
> have set tags vector size equal to whatever we have requested. We set error 
> string which is actually not being used anywhere and can be removed in favor 
> of a log message to help with debugging if needed.
> 
> Also we need to resize the vector after ptrace request so we use this size in 
> gdb remote reply.
I'll log that error in in GDBRemoteCommunicationServerLLGS.cpp.

I'll do what you suggested to support partial read on the server side. Then 
lldb client can error if it doesn't get what it expected.
(testing partial reads on the lldb side is going to be very difficult anyway 
since we'd need a valid smaps entry to even issue one)



Comment at: 
lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py:102
+# Here we read from 1/2 way through a granule, into the next. Expands 
to 2 granules
+self.check_qmemtags_response("{:x},10:1".format(buf_address+64-8), 
"m0304")

omjavaid wrote:
> Do we test partial read case here? 
Ack. No, but it should be a case of reading off of the end of the allocated 
buffer by some amount.



Comment at: lldb/test/API/tools/lldb-server/memory-tagging/main.c:13
+  // Wait for lldb-server to stop us
+  while (1) {
+  }

omjavaid wrote:
> infinite loop in test program may not be a good idea.
I'll check what the timeouts are on the expect packet sequence. I think it 
would get killed eventually if we didn't see the output we're looking for.
(I could do something more CPU friendly, sleep/halt/wait on something)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95601

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


[Lldb-commits] [PATCH] D98219: [lldb] Update crashlog script for JSON changes

2021-03-09 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl accepted this revision.
aprantl added inline comments.
This revision is now accepted and ready to land.



Comment at: lldb/examples/python/crashlog.py:446
+low = int(json_image['base'])
+high = int(0)
+name = json_image['name']

Time for me to learn some dark Python: What is 0 otherwise?


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

https://reviews.llvm.org/D98219

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


[Lldb-commits] [PATCH] D98219: [lldb] Update crashlog script for JSON changes

2021-03-09 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added inline comments.



Comment at: lldb/examples/python/crashlog.py:446
+low = int(json_image['base'])
+high = int(0)
+name = json_image['name']

aprantl wrote:
> Time for me to learn some dark Python: What is 0 otherwise?
This was fine, just added the `int` for consistency :-) 


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

https://reviews.llvm.org/D98219

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


[Lldb-commits] [PATCH] D96176: Implement jAttachWait

2021-03-09 Thread Augusto Noronha via Phabricator via lldb-commits
augusto2112 updated this revision to Diff 329385.
augusto2112 marked 7 inline comments as done and an inline comment as not done.
augusto2112 added a comment.

Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96176

Files:
  lldb/include/lldb/Target/Process.h
  lldb/include/lldb/Utility/StringExtractorGDBRemote.h
  lldb/include/lldb/lldb-enumerations.h
  lldb/source/Commands/CommandObjectProcess.cpp
  lldb/source/Commands/Options.td
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Utility/StringExtractorGDBRemote.cpp

Index: lldb/source/Utility/StringExtractorGDBRemote.cpp
===
--- lldb/source/Utility/StringExtractorGDBRemote.cpp
+++ lldb/source/Utility/StringExtractorGDBRemote.cpp
@@ -200,7 +200,10 @@
   if (PACKET_MATCHES("qHostInfo"))
 return eServerPacketType_qHostInfo;
   break;
-
+case 'J':
+  if (PACKET_MATCHES("qJAttachSupported"))
+return eServerPacketType_qJAttachSupported;
+  break;
 case 'K':
   if (PACKET_STARTS_WITH("qKillSpawnedProcess"))
 return eServerPacketType_qKillSpawnedProcess;
@@ -294,6 +297,8 @@
 break;
 
   case 'j':
+if (PACKET_STARTS_WITH("jAttach:"))
+  return eServerPacketType_jAttach;
 if (PACKET_STARTS_WITH("jModulesInfo:"))
   return eServerPacketType_jModulesInfo;
 if (PACKET_MATCHES("jSignalsInfo"))
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -1160,41 +1160,72 @@
   return error;
 }
 
+static StreamGDBRemote MakeJAttachPacket(const char *process_name,
+ const ProcessAttachInfo &attach_info) {
+
+  StreamString json_string;
+  json_string.PutCString("jAttach:");
+
+  StructuredData::Dictionary json_packet;
+  json_packet.AddStringItem("process_name", process_name);
+
+  if (auto interval = attach_info.GetWaitForLaunchInterval())
+json_packet.AddIntegerItem("waitfor-interval-usec", interval->count());
+
+  if (auto duration = attach_info.GetWaitForLaunchDuration())
+json_packet.AddIntegerItem("waitfor-duration-sec", duration->count());
+
+  json_packet.AddBooleanItem("include-existing",
+ !attach_info.GetIgnoreExisting());
+
+  json_packet.Dump(json_string, false);
+  StreamGDBRemote escaped_packet;
+  escaped_packet.PutEscapedBytes(json_string.GetData(), json_string.GetSize());
+  return escaped_packet;
+}
+
 Status ProcessGDBRemote::DoAttachToProcessWithName(
 const char *process_name, const ProcessAttachInfo &attach_info) {
   Status error;
   // Clear out and clean up from any current state
   Clear();
 
-  if (process_name && process_name[0]) {
-error = EstablishConnectionIfNeeded(attach_info);
-if (error.Success()) {
-  StreamString packet;
+  if (!process_name || !process_name[0])
+return error;
 
-  m_gdb_comm.SetDetachOnError(attach_info.GetDetachOnError());
+  error = EstablishConnectionIfNeeded(attach_info);
+  if (!error.Success()) {
+SetExitStatus(-1, error.AsCString());
+return error;
+  }
 
-  if (attach_info.GetWaitForLaunch()) {
-if (!m_gdb_comm.GetVAttachOrWaitSupported()) {
+  m_gdb_comm.SetDetachOnError(attach_info.GetDetachOnError());
+  if (attach_info.GetWaitForLaunch() && m_gdb_comm.GetJAttachSupported()) {
+auto gdb_stream = MakeJAttachPacket(process_name, attach_info);
+m_async_broadcaster.BroadcastEvent(
+eBroadcastBitAsyncContinue,
+new EventDataBytes(gdb_stream.GetString().data(),
+   gdb_stream.GetSize()));
+  } else {
+StreamString packet;
+if (attach_info.GetWaitForLaunch()) {
+  if (!m_gdb_comm.GetVAttachOrWaitSupported()) {
+packet.PutCString("vAttachWait");
+  } else {
+if (attach_info.GetIgnoreExisting())
   packet.PutCString("vAttachWait");
-} else {
-  if (attach_info.GetIgnoreExisting())
-packet.PutCString("vAttachWait");
-  else
-packet.PutCString("vAttachOrWait");
-}
-  } else
-packet.PutCString("vAttachName");
-  packet.PutChar(';');
-  packet.PutBytesAsRawHex8(process_name, strlen(process_name),
-   endian::InlHostByteOrder(),
-   endian::InlHostByteOrder());
-
-  m_async_broadcaster.BroadcastEvent(
-  eBroadcastB

[Lldb-commits] [PATCH] D96176: Implement jAttachWait

2021-03-09 Thread Augusto Noronha via Phabricator via lldb-commits
augusto2112 added a comment.

In D96176#2546777 , @labath wrote:

> I'm not sure this new functionality is really worth the new packet (or two), 
> but if it solves a use case you care about, then I suppose that's fine.

To be honest, I started this as I thought it'd be useful to LLDB users. If you 
think it's more trouble than it's worth, I'd be OK abandoning this change (I'm 
also OK completing it).

In D96176#2547429 , @labath wrote:

> In D96176#2547324 , @augusto2112 
> wrote:
>
>> In D96176#2546777 , @labath wrote:
>>
>>> One alternative could be to just tack on some extra data to the existing 
>>> vAttach family packets  (`vAttachWait;foo;interval:47;duration=74`).
>>
>> This was how I did it originally on https://reviews.llvm.org/D93895. 
>> @clayborg pointed out that this might not be compatible with existing 
>> lldb-server implementations, and suggested a new packet.
>
> If we only append the extra fields when the user explicitly requests them, 
> then I don't think this would be a compatibility issue. The way I see it, one 
> of two things can happen in this case:
> a) the server ignores the extra fields and completes the attach with the 
> default values
> b) the server balks at the packet, and returns an error
> I think both of them are reasonable results and they can be fixed/worked 
> around in the same way -- just drop the special requests...

If you guys think that's less messy, I could do that. Although I think it'd be 
nice to warn users if the parameters they're passing are ignored.




Comment at: lldb/include/lldb/Utility/StringExtractorGDBRemote.h:136
 eServerPacketType_vAttachOrWait,
+eServerPacketType_jAttachWait,
 eServerPacketType_vAttachName,

augusto2112 wrote:
> labath wrote:
> > clayborg wrote:
> > > So we currently have 4 flavors from the old way: vAttach, vAttachWait 
> > > vAttachOrWait, vAttachName. Do we want to possibly make a "jAttach" that 
> > > works for all cases? The new "jAttach" could be powerful enough to do it 
> > > all in one packet if needed. I just worry about attaching the "Wait" to 
> > > the "jAttachWait" command name in case we want to use it for all of the 
> > > above cases at a later point. 
> > > 
> > > A "jAttach" could implement all of:
> > > - attach to existing pid
> > > - attach to by name
> > >   - unique existing process
> > >   - wait
> > > - allow existing (true/false)
> > > - poll interval (time in usec)
> > > - wait duration (time in sec)
> > > 
> > > Not that we need to add support for all of these flavor with this patch, 
> > > I'm just trying to forward think about the future in case other attach 
> > > flags are added to any flavor of attach. 
> > Sounds like a good idea.
> Sure! I was considering that as well. I wasn't sure what granularity lldb's 
> packets should have, which is why I decided to start only with the attachWait 
> first and see what you thought. I can include this in this patch, I don't 
> think it's a lot of extra work.
Actually, it looks like this would be more work than I though. I changed the 
name to "jAttach" but am keeping only the existing functionality so this patch 
doesn't get too big.



Comment at: lldb/include/lldb/lldb-enumerations.h:600-601
   eArgTypeModuleUUID,
+  eArgTypeWaitforInterval,
+  eArgTypeWaitforDuration,
   eArgTypeLastArg // Always keep this entry as the last entry in this

labath wrote:
> What's up with this? Though this is the first time I see this table, I 
> suspect it is not necessary to create a new command argument
Seems like this is necessary when adding arguments to parameters. I think that 
the name must match whatever is define inside the `Arg` tag in `Options.td`:

```
  def process_attach_waitfor_interval : Option<"waitfor-interval", "I">,
Group<2>, Arg<"WaitforInterval">,
Desc<"The interval that waitfor uses to poll the list of processes.">;
  def process_attach_waitfor_duration : Option<"waitfor-duration", "d">,
Group<2>, Arg<"WaitforDuration">,
```



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:394
   ProcessInstanceInfoList loop_process_list;
-  while (true) {
+  while (!timeout.hasValue() || now < target) {
 loop_process_list.clear();

labath wrote:
> `<= target` ? In case of a zero timeout, I guess this should loop at least 
> once. Or, even better:
> ```
> do {
>   ...
> } while (std::chrono::steady_clock::now() < target);
> ```
> (At that point it does not matter whether it's `<` or `<=`).
Good catch!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96176

___
lldb-commits mailing list
lldb-commit

[Lldb-commits] [lldb] 080ded7 - [lldb] Use lit.with_system_environment to propagate env variables

2021-03-09 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2021-03-09T10:44:34-08:00
New Revision: 080ded7445cc670cf2628e660690a06503d226d7

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

LOG: [lldb] Use lit.with_system_environment to propagate env variables

Use lit's with_system_environment function to propagate environment
variables to the tests. Include the usual suspects, as well as the
variables already explicitly forwarded.

Added: 


Modified: 
lldb/test/Shell/lit.cfg.py
lldb/test/Unit/lit.cfg.py

Removed: 




diff  --git a/lldb/test/Shell/lit.cfg.py b/lldb/test/Shell/lit.cfg.py
index 83e3ef6782ad..fb9412b35be8 100644
--- a/lldb/test/Shell/lit.cfg.py
+++ b/lldb/test/Shell/lit.cfg.py
@@ -38,10 +38,14 @@
 # test_exec_root: The root path where tests should be run.
 config.test_exec_root = os.path.join(config.lldb_obj_root, 'test')
 
-# Propagate reproducer environment vars.
-if 'LLDB_CAPTURE_REPRODUCER' in os.environ:
-  config.environment['LLDB_CAPTURE_REPRODUCER'] = os.environ[
-  'LLDB_CAPTURE_REPRODUCER']
+# Propagate environment vars.
+llvm_config.with_system_environment([
+'FREEBSD_LEGACY_PLUGIN',
+'HOME',
+'LLDB_CAPTURE_REPRODUCER',
+'TEMP',
+'TMP',
+])
 
 # Support running the test suite under the lldb-repro wrapper. This makes it
 # possible to capture a test suite run and then rerun all the test from the
@@ -136,6 +140,3 @@ def calculate_arch_features(arch_string):
 can_set_dbregs = False
 if can_set_dbregs:
 config.available_features.add('dbregs-set')
-
-# pass control variable through
-llvm_config.with_system_environment('FREEBSD_LEGACY_PLUGIN')

diff  --git a/lldb/test/Unit/lit.cfg.py b/lldb/test/Unit/lit.cfg.py
index e53bcd394ca1..69aab2a4a29f 100644
--- a/lldb/test/Unit/lit.cfg.py
+++ b/lldb/test/Unit/lit.cfg.py
@@ -23,8 +23,15 @@
 # it needs to be able to find it at runtime.  This is fine if Python is on your
 # system PATH, but if it's not, then this unit test executable will fail to 
run.
 # We can solve this by forcing the Python directory onto the system path here.
-llvm_config.with_system_environment('PATH')
-llvm_config.with_environment('PATH', os.path.dirname(sys.executable), 
append_path=True)
+llvm_config.with_system_environment([
+'HOME',
+'PATH',
+'TEMP',
+'TMP',
+])
+llvm_config.with_environment('PATH',
+ os.path.dirname(sys.executable),
+ append_path=True)
 
 # testFormat: The test format to use to interpret tests.
 config.test_format = lit.formats.GoogleTest(config.llvm_build_mode, 'Tests')



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


[Lldb-commits] [lldb] cc52ea3 - [lldb] Update crashlog script for JSON changes

2021-03-09 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2021-03-09T10:44:34-08:00
New Revision: cc52ea30012d3d9495a41255be50dccc77464cad

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

LOG: [lldb] Update crashlog script for JSON changes

Update the crashlog script for changes to the JSON schema.

rdar://75122914

Differential revision: https://reviews.llvm.org/D98219

Added: 


Modified: 
lldb/examples/python/crashlog.py
lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/a.out.ips
lldb/test/Shell/ScriptInterpreter/Python/Crashlog/json.test

Removed: 




diff  --git a/lldb/examples/python/crashlog.py 
b/lldb/examples/python/crashlog.py
index dbd9cea62e5d..88692271bdce 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -415,13 +415,9 @@ def parse(self):
 
 thread = self.crashlog.threads[self.crashlog.crashed_thread_idx]
 thread.reason = self.parse_crash_reason(self.data['exception'])
-thread.registers = 
self.parse_thread_registers(self.data['threadState'])
 
 return self.crashlog
 
-def get_image_extra_info(self, idx):
-return self.data['legacyInfo']['imageExtraInfo'][idx]
-
 def get_used_image(self, idx):
 return self.data['usedImages'][idx]
 
@@ -440,17 +436,16 @@ def parse_crash_reason(self, json_exception):
 else:
 exception_extra = ""
 return "{} ({}){}".format(exception_type, exception_signal,
-exception_extra)
+  exception_extra)
 
 def parse_images(self, json_images):
 idx = 0
-for json_images in json_images:
-img_uuid = uuid.UUID(json_images[0])
-low = int(json_images[1])
-high = 0
-extra_info = self.get_image_extra_info(idx)
-name = extra_info['name']
-path = extra_info['path']
+for json_image in json_images:
+img_uuid = uuid.UUID(json_image['uuid'])
+low = int(json_image['base'])
+high = int(0)
+name = json_image['name']
+path = json_image['path']
 version = ""
 darwin_image = self.crashlog.DarwinImage(low, high, name, version,
  img_uuid, path,
@@ -461,16 +456,14 @@ def parse_images(self, json_images):
 def parse_frames(self, thread, json_frames):
 idx = 0
 for json_frame in json_frames:
-image_id = int(json_frame[0])
-
-ident = self.get_image_extra_info(image_id)['name']
+image_id = int(json_frame['imageIndex'])
+ident = self.get_used_image(image_id)['name']
 thread.add_ident(ident)
 if ident not in self.crashlog.idents:
 self.crashlog.idents.append(ident)
 
-frame_offset = int(json_frame[1])
-image = self.get_used_image(image_id)
-image_addr = int(image[1])
+frame_offset = int(json_frame['imageOffset'])
+image_addr = self.get_used_image(image_id)['base']
 pc = image_addr + frame_offset
 thread.frames.append(self.crashlog.Frame(idx, pc, frame_offset))
 idx += 1
@@ -481,6 +474,8 @@ def parse_threads(self, json_threads):
 thread = self.crashlog.Thread(idx, False)
 if json_thread.get('triggered', False):
 self.crashlog.crashed_thread_idx = idx
+self.registers = self.parse_thread_registers(
+json_thread['threadState'])
 thread.queue = json_thread.get('queue')
 self.parse_frames(thread, json_thread.get('frames', []))
 self.crashlog.threads.append(thread)
@@ -489,15 +484,16 @@ def parse_threads(self, json_threads):
 def parse_thread_registers(self, json_thread_state):
 idx = 0
 registers = dict()
-for reg in json_thread_state.get('x', []):
+for json_reg in json_thread_state.get('x', []):
 key = str('x{}'.format(idx))
-value = int(reg)
+value = int(json_reg['value'])
 registers[key] = value
 idx += 1
 
 for register in ['lr', 'cpsr', 'fp', 'sp', 'esr', 'pc']:
 if register in json_thread_state:
-registers[register] = int(json_thread_state[register])
+json_reg = json_thread_state[register]
+registers[register] = int(json_reg['value'])
 
 return registers
 

diff  --git 
a/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/a.out.ips 
b/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/a.out.ips
index 13feba12c177..02a7a037afe4 100644
--- a/lldb/test/Shell/ScriptInter

[Lldb-commits] [lldb] c2d2adb - [lldb] Propagate XDG_CACHE_HOME environment variable to tests

2021-03-09 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2021-03-09T10:44:34-08:00
New Revision: c2d2adbce9299e562abd00b8f3139933beb97e17

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

LOG: [lldb] Propagate XDG_CACHE_HOME environment variable to tests

This variable is used to reducing the likelihood of hitting module cache
issues in CI where different branches can potentially run on the same
machine.

Added: 


Modified: 
lldb/test/API/lit.cfg.py
lldb/test/Shell/lit.cfg.py
lldb/test/Unit/lit.cfg.py

Removed: 




diff  --git a/lldb/test/API/lit.cfg.py b/lldb/test/API/lit.cfg.py
index 08e2dcc1ef80..54a02453b174 100644
--- a/lldb/test/API/lit.cfg.py
+++ b/lldb/test/API/lit.cfg.py
@@ -129,11 +129,6 @@ def delete_module_cache(path):
 lit_config.warning("unable to inject shared library path on '{}'".format(
 platform.system()))
 
-# Propagate LLDB_CAPTURE_REPRODUCER
-if 'LLDB_CAPTURE_REPRODUCER' in os.environ:
-  config.environment['LLDB_CAPTURE_REPRODUCER'] = os.environ[
-  'LLDB_CAPTURE_REPRODUCER']
-
 # Support running the test suite under the lldb-repro wrapper. This makes it
 # possible to capture a test suite run and then rerun all the test from the
 # just captured reproducer.
@@ -256,3 +251,12 @@ def delete_module_cache(path):
 if 'FREEBSD_LEGACY_PLUGIN' in os.environ:
   config.environment['FREEBSD_LEGACY_PLUGIN'] = os.environ[
   'FREEBSD_LEGACY_PLUGIN']
+
+# Propagate LLDB_CAPTURE_REPRODUCER
+if 'LLDB_CAPTURE_REPRODUCER' in os.environ:
+  config.environment['LLDB_CAPTURE_REPRODUCER'] = os.environ[
+  'LLDB_CAPTURE_REPRODUCER']
+
+# Propagate XDG_CACHE_HOME
+if 'XDG_CACHE_HOME' in os.environ:
+  config.environment['XDG_CACHE_HOME'] = os.environ['XDG_CACHE_HOME']

diff  --git a/lldb/test/Shell/lit.cfg.py b/lldb/test/Shell/lit.cfg.py
index fb9412b35be8..1e793846023a 100644
--- a/lldb/test/Shell/lit.cfg.py
+++ b/lldb/test/Shell/lit.cfg.py
@@ -45,6 +45,7 @@
 'LLDB_CAPTURE_REPRODUCER',
 'TEMP',
 'TMP',
+'XDG_CACHE_HOME',
 ])
 
 # Support running the test suite under the lldb-repro wrapper. This makes it

diff  --git a/lldb/test/Unit/lit.cfg.py b/lldb/test/Unit/lit.cfg.py
index 69aab2a4a29f..75ca85978155 100644
--- a/lldb/test/Unit/lit.cfg.py
+++ b/lldb/test/Unit/lit.cfg.py
@@ -28,6 +28,7 @@
 'PATH',
 'TEMP',
 'TMP',
+'XDG_CACHE_HOME',
 ])
 llvm_config.with_environment('PATH',
  os.path.dirname(sys.executable),



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


[Lldb-commits] [PATCH] D98219: [lldb] Update crashlog script for JSON changes

2021-03-09 Thread Jonas Devlieghere via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcc52ea30012d: [lldb] Update crashlog script for JSON changes 
(authored by JDevlieghere).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98219

Files:
  lldb/examples/python/crashlog.py
  lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/a.out.ips
  lldb/test/Shell/ScriptInterpreter/Python/Crashlog/json.test

Index: lldb/test/Shell/ScriptInterpreter/Python/Crashlog/json.test
===
--- lldb/test/Shell/ScriptInterpreter/Python/Crashlog/json.test
+++ lldb/test/Shell/ScriptInterpreter/Python/Crashlog/json.test
@@ -3,7 +3,7 @@
 # RUN: python %S/patch-crashlog.py --binary %t.out --crashlog %t.crash --offsets '{"main":20, "bar":9, "foo":16}' --json
 # RUN: %lldb %t.out -o 'command script import lldb.macosx.crashlog' -o 'crashlog %t.crash' 2>&1 | FileCheck %s
 
-# CHECK: Thread[0] EXC_BAD_ACCESS (SIGSEGV) (KERN_INVALID_ADDRESS at 0x)
+# CHECK: Thread[0] EXC_BAD_ACCESS (SIGSEGV) (KERN_INVALID_ADDRESS at 0x)
 # CHECK: [  0] {{.*}}out`foo + 16 at test.c
 # CHECK: [  1] {{.*}}out`bar + 8 at test.c
 # CHECK: [  2] {{.*}}out`main + 19 at test.c
Index: lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/a.out.ips
===
--- lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/a.out.ips
+++ lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/a.out.ips
@@ -1,95 +1,172 @@
-{"app_name":"a.out","timestamp":"2020-11-11 16:12:18.00 -0800","app_version":"","slice_uuid":"9b76648c-9b4e-33a9-a97e-10856e911631","build_version":"","platform":1,"share_with_app_devs":1,"is_first_party":1,"bug_type":"309","os_version":"macOS 11.0.1","incident_id":"598C4706-28B0-4D96-A2F9-AE6973BEC635","name":"a.out"}
+{"app_name":"json.test.tmp.out","timestamp":"2021-03-08 13:57:06.00 -0800","app_version":"","slice_uuid":"8f528c10-3e80-3dd6-b0be-5d558f64f7ab","build_version":"","platform":1,"share_with_app_devs":1,"is_first_party":1,"etl_key":"3","bug_type":"309","os_version":"macOS 11.3","incident_id":"FA21DF23-3344-4E45-BF27-4B8E63B7012B","name":"json.test.tmp.out"}
 {
-  "uptime" : 180,
-  "procLaunch" : "2020-11-11 16:12:12.4375 -0800",
+  "uptime" : 32,
+  "procLaunch" : "2021-03-08 13:56:51.7232 -0800",
   "procRole" : "Unspecified",
+  "version" : 2,
   "exception" : {
 "type" : "EXC_BAD_ACCESS",
 "signal" : "SIGSEGV",
-"subtype" : "KERN_INVALID_ADDRESS at 0x"
+"subtype" : "KERN_INVALID_ADDRESS at 0x"
   },
   "userID" : 501,
   "modelCode" : "iMacPro1,1",
-  "coalitionID" : 471,
+  "coalitionID" : 6086,
   "osVersion" : {
-"train" : "macOS 11.0.1",
+"train" : "macOS 11.3",
 "build" : "",
 "releaseType" : ""
   },
-  "captureTime" : "2020-11-11 16:12:12.6267 -0800",
-  "incident" : "598C4706-28B0-4D96-A2F9-AE6973BEC635",
-  "pid" : 2187,
+  "captureTime" : "2021-03-08 13:56:51.8610 -0800",
+  "incident" : "FA21DF23-3344-4E45-BF27-4B8E63B7012B",
+  "pid" : 72932,
   "cpuType" : "X86-64",
-  "procName" : "a.out",
-  "procPath" : "\/private\/tmp\/a.out",
+  "procName" : "json.test.tmp.out",
+  "procPath" : "\/Users\/USER\/*\/json.test.tmp.out",
   "parentProc" : "fish",
-  "parentPid" : 1651,
+  "parentPid" : 67002,
   "coalitionName" : "io.alacritty",
   "crashReporterKey" : "DCEF35CB-68D5-F524-FF13-060901F52EA8",
-  "responsiblePid" : 428,
+  "responsiblePid" : 65465,
   "responsibleProc" : "alacritty",
-  "bridgeVersion" : {"build":"","train":""},
+  "bridgeVersion" : {"build":"18P4544","train":"5.3"},
   "sip" : "enabled",
-  "is_corpse" : 1,
-  "termination" : {"reason":"Namespace SIGNAL, Code 0xb","signal":"Segmentation fault: 11","byProc":"exc handler","code":11,"namespace":"SIGNAL","byPid":2187,"flags":0},
-  "asi" : ["dyld2 mode"],
-  "extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":2067},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
-  "threads" : [{"triggered":true,"id":22172,"queue":"com.apple.main-thread","frames":[[0,@foo@],[0,@bar@],[0,@main@],[1,87601]]}],
-  "threadState" : {
-  "r13" : 0,
-  "rax" : 0,
-  "rflags" : 66054,
-  "cpu" : 6,
-  "rsi" : 140732908048520,
-  "r14" : 0,
-  "trap_description" : "(no mapping for user data write)",
-  "r8" : 0,
-  "cr2" : 0,
-  "rdx" : 140732908048536,
-  "r10" : 0,
-  "r9" : 0,
-  "r15" : 0,
-  "rbx" : 0,
-  "trap" : 14,
-  "err" : 6,
-  "r11" : 0,
-  "rip" : 4307689328,
-  "rbp" : 140732908048432,
-  "rsp" : 140732908048432,
-  "r12" : 0,
-  "rcx" : 140732908048880,
-  "flavor" : "x86_THREAD_STATE",
-  "rdi" : 1
-},
+  "isCorpse" : 1,
+  "termination" : {"flags":0,"code":11,"namespace":"SIGNAL","indicator":"Segmentation fault: 11","b

[Lldb-commits] [PATCH] D98272: [lldb/Platform] Skip very slow xcrun queries for simulator platforms, NFC

2021-03-09 Thread Vedant Kumar via Phabricator via lldb-commits
vsk created this revision.
vsk added reviewers: aprantl, JDevlieghere.
vsk requested review of this revision.
Herald added a project: LLDB.

GetXcodeSDK() consistently takes over 1 second to complete if the
queried SDK is missing, because `xcrun` doesn't cache negative lookups.

Because there are multiple simulator platforms, this can add 4+ seconds
to `lldb -b some_object_file.o`.

To work around this, skip the call to GetXcodeSDK() when setting up
simulator platforms if the specified arch doesn't have what looks like a
simulator triple.

Some other ways to fix this:

- Fix caching in xcrun (rdar://74882205)
- Test for arch compat before calling SomePlatform::CreateInstance() (much 
larger change)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98272

Files:
  lldb/source/Plugins/Platform/MacOSX/PlatformAppleSimulator.cpp


Index: lldb/source/Plugins/Platform/MacOSX/PlatformAppleSimulator.cpp
===
--- lldb/source/Plugins/Platform/MacOSX/PlatformAppleSimulator.cpp
+++ lldb/source/Plugins/Platform/MacOSX/PlatformAppleSimulator.cpp
@@ -530,6 +530,8 @@
   }
 
   static PlatformSP CreateInstance(bool force, const ArchSpec *arch) {
+if (arch && arch->IsValid() && !arch->TripleEnvironmentWasSpecified())
+  return nullptr; // Avoid very slow xcrun query for non-simulator archs.
 llvm::StringRef sdk;
 sdk = HostInfo::GetXcodeSDKPath(XcodeSDK("iPhoneSimulator.Internal.sdk"));
 if (sdk.empty())
@@ -578,6 +580,8 @@
   }
 
   static PlatformSP CreateInstance(bool force, const ArchSpec *arch) {
+if (arch && arch->IsValid() && !arch->TripleEnvironmentWasSpecified())
+  return nullptr; // Avoid very slow xcrun query for non-simulator archs.
 return PlatformAppleSimulator::CreateInstance(
 "PlatformAppleTVSimulator", g_tvos_description,
 ConstString(g_tvos_plugin_name),
@@ -619,6 +623,8 @@
   }
 
   static PlatformSP CreateInstance(bool force, const ArchSpec *arch) {
+if (arch && arch->IsValid() && !arch->TripleEnvironmentWasSpecified())
+  return nullptr; // Avoid very slow xcrun query for non-simulator archs.
 return PlatformAppleSimulator::CreateInstance(
 "PlatformAppleWatchSimulator", g_watchos_description,
 ConstString(g_watchos_plugin_name),


Index: lldb/source/Plugins/Platform/MacOSX/PlatformAppleSimulator.cpp
===
--- lldb/source/Plugins/Platform/MacOSX/PlatformAppleSimulator.cpp
+++ lldb/source/Plugins/Platform/MacOSX/PlatformAppleSimulator.cpp
@@ -530,6 +530,8 @@
   }
 
   static PlatformSP CreateInstance(bool force, const ArchSpec *arch) {
+if (arch && arch->IsValid() && !arch->TripleEnvironmentWasSpecified())
+  return nullptr; // Avoid very slow xcrun query for non-simulator archs.
 llvm::StringRef sdk;
 sdk = HostInfo::GetXcodeSDKPath(XcodeSDK("iPhoneSimulator.Internal.sdk"));
 if (sdk.empty())
@@ -578,6 +580,8 @@
   }
 
   static PlatformSP CreateInstance(bool force, const ArchSpec *arch) {
+if (arch && arch->IsValid() && !arch->TripleEnvironmentWasSpecified())
+  return nullptr; // Avoid very slow xcrun query for non-simulator archs.
 return PlatformAppleSimulator::CreateInstance(
 "PlatformAppleTVSimulator", g_tvos_description,
 ConstString(g_tvos_plugin_name),
@@ -619,6 +623,8 @@
   }
 
   static PlatformSP CreateInstance(bool force, const ArchSpec *arch) {
+if (arch && arch->IsValid() && !arch->TripleEnvironmentWasSpecified())
+  return nullptr; // Avoid very slow xcrun query for non-simulator archs.
 return PlatformAppleSimulator::CreateInstance(
 "PlatformAppleWatchSimulator", g_watchos_description,
 ConstString(g_watchos_plugin_name),
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] b4825a6 - [lldb][gui] Fix uninitialized variable in SourceFileWindowDelegate.

2021-03-09 Thread Jordan Rupprecht via lldb-commits

Author: Jordan Rupprecht
Date: 2021-03-09T10:57:00-08:00
New Revision: b4825a6d9c18bdb3e241d709f2f76573aba9f91b

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

LOG: [lldb][gui] Fix uninitialized variable in SourceFileWindowDelegate.

After 5419b671375c46299ff1da6c929859040e7beaf5 (which is `[SimplifyCFG] Update 
FoldTwoEntryPHINode to handle and/or of select and binop equally`), this 
uninitialized value is detected by msan.

Added: 


Modified: 
lldb/source/Core/IOHandlerCursesGUI.cpp

Removed: 




diff  --git a/lldb/source/Core/IOHandlerCursesGUI.cpp 
b/lldb/source/Core/IOHandlerCursesGUI.cpp
index e76a0bc16f75..a1c9daa79be7 100644
--- a/lldb/source/Core/IOHandlerCursesGUI.cpp
+++ b/lldb/source/Core/IOHandlerCursesGUI.cpp
@@ -3392,10 +3392,10 @@ class SourceFileWindowDelegate : public WindowDelegate {
   SourceFileWindowDelegate(Debugger &debugger)
   : WindowDelegate(), m_debugger(debugger), m_sc(), m_file_sp(),
 m_disassembly_scope(nullptr), m_disassembly_sp(), 
m_disassembly_range(),
-m_title(), m_line_width(4), m_selected_line(0), m_pc_line(0),
-m_stop_id(0), m_frame_idx(UINT32_MAX), m_first_visible_line(0),
-m_first_visible_column(0), m_min_x(0), m_min_y(0), m_max_x(0),
-m_max_y(0) {}
+m_title(), m_tid(LLDB_INVALID_THREAD_ID), m_line_width(4),
+m_selected_line(0), m_pc_line(0), m_stop_id(0), 
m_frame_idx(UINT32_MAX),
+m_first_visible_line(0), m_first_visible_column(0), m_min_x(0),
+m_min_y(0), m_max_x(0), m_max_y(0) {}
 
   ~SourceFileWindowDelegate() override = default;
 



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


[Lldb-commits] [PATCH] D98153: Some FormatEntity.cpp cleanup and unit testing

2021-03-09 Thread Neal via Phabricator via lldb-commits
nealsid marked 2 inline comments as done.
nealsid added a comment.

In D98153#2610953 , @teemperor wrote:

> Thanks for cleaning this up! Are the `if (!sc) ...` stuff are missing nullptr 
> checks that affect a normal LLDB session (not sure if we can ever have no 
> SymbolContext) or is this just for the unit test?
>
> Anyway, I have some small inline comments but otherwise this looks pretty 
> good to me.

Missed this earlier - I think you're right, because the formatting code is used 
for thread/frame lists & information, so there will be a SymbolContext.  But 
one my planned upcoming changes is to use it in the LLDB prompt, where a target 
might not be available.  And it's also more consistent with formatting code for 
other Entry types.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98153

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


[Lldb-commits] [PATCH] D98289: [lldb] Fix DW_AT_ranges DW_FORM_sec_offset not using DW_AT_rnglists_base (used by GCC)

2021-03-09 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil created this revision.
jankratochvil added reviewers: labath, grimar.
jankratochvil added a project: LLDB.
Herald added a subscriber: JDevlieghere.
jankratochvil requested review of this revision.

`DW_AT_ranges` can use `DW_FORM_sec_offset` (instead of `DW_FORM_rnglistx`). In 
such case `DW_AT_rnglists_base` does not need to be present.
DWARF-5 spec:

> "If the offset_entry_count is zero, then DW_FORM_rnglistx cannot be used to 
> access a range list; DW_FORM_sec_offset must be used instead. If the 
> offset_entry_count is non-zero, then DW_FORM_rnglistx may be used to access a 
> range list;"

This fix is for `TestTypeCompletion.py` category `dwarf` using GCC with DWARF-5.
`TestTypeCompletion.py` category `dwo` still fails but that is a GCC bug: 
-gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file 


The fix just provides `GetRnglist()` lazy getter for `m_rnglist_table`.
The testcase is easier to review by: `diff -u 
lldb/test/Shell/SymbolFile/DWARF/DW_AT_low_pc-addrx.s 
lldb/test/Shell/SymbolFile/DWARF/DW_AT_range-DW_FORM_sec_offset.s`


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98289

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
  lldb/test/Shell/SymbolFile/DWARF/DW_AT_range-DW_FORM_sec_offset.s

Index: lldb/test/Shell/SymbolFile/DWARF/DW_AT_range-DW_FORM_sec_offset.s
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/DW_AT_range-DW_FORM_sec_offset.s
@@ -0,0 +1,107 @@
+# DW_AT_ranges can use DW_FORM_sec_offset (instead of DW_FORM_rnglistx).
+# In such case DW_AT_rnglists_base does not need to be present.
+
+# REQUIRES: x86
+
+# RUN: llvm-mc -triple=x86_64-pc-linux -filetype=obj %s > %t
+# RUN: %lldb %t -o "image lookup -v -s lookup_rnglists" \
+# RUN:   -o exit | FileCheck %s
+
+# Failure was the block range 1..2 was not printed plus:
+# error: DW_AT_range-DW_FORM_sec_offset.s.tmp {0x003f}: DIE has DW_AT_ranges(0xc) attribute, but range extraction failed (missing or invalid range list table), please file a bug and attach the file at the start of this error message
+
+# CHECK-LABEL: image lookup -v -s lookup_rnglists
+# CHECK:  Function: id = {0x0029}, name = "rnglists", range = [0x-0x0003)
+# CHECK:Blocks: id = {0x0029}, range = [0x-0x0003)
+# CHECK-NEXT:   id = {0x003f}, range = [0x0001-0x0002)
+
+.text
+rnglists:
+nop
+.Lblock1_begin:
+lookup_rnglists:
+nop
+.Lblock1_end:
+nop
+.Lrnglists_end:
+
+.section.debug_abbrev,"",@progbits
+.byte   1   # Abbreviation Code
+.byte   17  # DW_TAG_compile_unit
+.byte   1   # DW_CHILDREN_yes
+.byte   37  # DW_AT_producer
+.byte   8   # DW_FORM_string
+.byte   17  # DW_AT_low_pc
+.byte   27  # DW_FORM_addrx
+.byte   18  # DW_AT_high_pc
+.byte   6   # DW_FORM_data4
+.byte   115 # DW_AT_addr_base
+.byte   23  # DW_FORM_sec_offset
+.byte   0   # EOM(1)
+.byte   0   # EOM(2)
+.byte   2   # Abbreviation Code
+.byte   46  # DW_TAG_subprogram
+.byte   1   # DW_CHILDREN_yes
+.byte   17  # DW_AT_low_pc
+.byte   1   # DW_FORM_addr
+.byte   18  # DW_AT_high_pc
+.byte   6   # DW_FORM_data4
+.byte   3   # DW_AT_name
+.byte   8   # DW_FORM_string
+.byte   0   # EOM(1)
+.byte   0   # EOM(2)
+.byte   5   # Abbreviation Code
+.byte   11  # DW_TAG_lexical_block
+.byte   0   # DW_CHILDREN_no
+.byte   85  # DW_AT_ranges
+.byte   0x17# DW_FORM_sec_offset
+.byte   0   # EOM(1)
+.byte   0   # EOM(2)
+.byte   0   # EOM(3)
+
+.section.debug_info,"",@progbits
+.Lcu_begin0:
+.long   .Ldebug_info_end0-.Ldebug_info_start0 # Length of Unit
+.Ldebug_info_start0:
+.short  5   # DWARF version number
+.byte   1   # DWARF Unit Type
+.byte   8   # Address Size (in bytes)
+.long   .debug_abbrev   # Offset Into Abbrev. Section
+.byte   1

[Lldb-commits] [lldb] ea659ea - Log in SetPrivateState when unwind logging enabled

2021-03-09 Thread Jason Molenda via lldb-commits

Author: Jason Molenda
Date: 2021-03-09T16:22:46-08:00
New Revision: ea659ea101a56a08c73be65ab62c3e180e37ca38

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

LOG: Log in SetPrivateState when unwind logging enabled

It is easier to read the unwind logging when you can see
when the inferior resumes / stops and we're doing new unwinds.

Added: 


Modified: 
lldb/source/Target/Process.cpp

Removed: 




diff  --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 979c649bf6e0..63673735ea83 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -1352,8 +1352,8 @@ void Process::SetPrivateState(StateType new_state) {
   if (m_finalizing)
 return;
 
-  Log *log(lldb_private::GetLogIfAnyCategoriesSet(LIBLLDB_LOG_STATE |
-  LIBLLDB_LOG_PROCESS));
+  Log *log(lldb_private::GetLogIfAnyCategoriesSet(
+  LIBLLDB_LOG_STATE | LIBLLDB_LOG_PROCESS | LIBLLDB_LOG_UNWIND));
   bool state_changed = false;
 
   LLDB_LOGF(log, "Process::SetPrivateState (%s)", StateAsCString(new_state));



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


[Lldb-commits] [PATCH] D98272: [lldb/Platform] Skip very slow xcrun queries for simulator platforms, NFC

2021-03-09 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added inline comments.



Comment at: lldb/source/Plugins/Platform/MacOSX/PlatformAppleSimulator.cpp:533
   static PlatformSP CreateInstance(bool force, const ArchSpec *arch) {
+if (arch && arch->IsValid() && !arch->TripleEnvironmentWasSpecified())
+  return nullptr; // Avoid very slow xcrun query for non-simulator archs.

We should extract this into a little helper function to avoid the code (and 
comment) duplication.



Comment at: lldb/source/Plugins/Platform/MacOSX/PlatformAppleSimulator.cpp:534
+if (arch && arch->IsValid() && !arch->TripleEnvironmentWasSpecified())
+  return nullptr; // Avoid very slow xcrun query for non-simulator archs.
 llvm::StringRef sdk;

Is it equivalent to return nullptr here to passing an empty string as the 
`sdk`? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98272

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