[Lldb-commits] [PATCH] D154927: [lldb][AArch64] Add SME's streaming vector control register

[Muhammad Omair Javaid via Phabricator via lldb-commits]

omjavaid added a comment.

Are




Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:1181
+
+  return {};
+}

Shouldnt we build a relevant error message here incase ReadSMEControl fails on 
ReadZAHeader



Comment at: 
lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py:183
+self.expect("register read svcr", 
substrs=["0x{:016x}".format(svcr_value)])
 
 for expr in exprs:

should we also add a svcr write test here? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154927

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

[Lldb-commits] [PATCH] D154927: [lldb][AArch64] Add SME's streaming vector control register

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added inline comments.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:1181
+
+  return {};
+}

omjavaid wrote:
> Shouldnt we build a relevant error message here incase ReadSMEControl fails 
> on ReadZAHeader
I think this should be `return error` in fact, let me check what that does.



Comment at: 
lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py:183
+self.expect("register read svcr", 
substrs=["0x{:016x}".format(svcr_value)])
 
 for expr in exprs:

omjavaid wrote:
> should we also add a svcr write test here? 
It's read only. We could allow writes but it introduces a lot more ways to 
change state, most of which aren't obviously useful for the user. If someone 
really wants it, it can be added.

I will note this in a comment here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154927

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

[Lldb-commits] [lldb] 87f937e - [lldb][Docs] Fix typo in style docs

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2023-09-20T08:04:23Z
New Revision: 87f937e9d68ae3ceea93982420f06bf90623aeba

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

LOG: [lldb][Docs] Fix typo in style docs

Added: 


Modified: 
lldb/docs/resources/contributing.rst

Removed: 




diff  --git a/lldb/docs/resources/contributing.rst 
b/lldb/docs/resources/contributing.rst
index 5ac4afb82a0747a..d3d467533c9eac8 100644
--- a/lldb/docs/resources/contributing.rst
+++ b/lldb/docs/resources/contributing.rst
@@ -33,7 +33,7 @@ in a few ways. The 2 main ones are:
 
   * Functions and methods are ``UpperCamelCase``.
 
-  * Static, global and member variables have ``s_``, ``g_`` and ``_m``
+  * Static, global and member variables have ``s_``, ``g_`` and ``m_``
 prefixes respectively.
 
 * `Use of asserts 
`_:



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

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

@@ -18,19 +18,45 @@ Please refer to the `LLVM Developer Policy
 authoring and uploading a patch. LLDB differs from the LLVM Developer
 Policy in the following respects.
 
- - **Test infrastructure**: Like LLVM it is  important to submit tests with 
your
-   patches, but note that LLDB uses a different system for tests. Refer to the
-   `test documentation `_ for more details and the ``lldb/test``
-   folder on disk for examples.
-
- - **Coding Style**: LLDB's code style differs from
-   `LLVM's coding style `_.
-   Unfortunately there is no document describing the differences. Please be
-   consistent with the existing code.
-
 For anything not explicitly listed here, assume that LLDB follows the LLVM
 policy.
 
+Coding Style
+
+
+LLDB's code style differs from `LLVM's coding style 
`_
+in a few ways. The 2 main ones are:
+
+* `Variable and function naming 
`_:
+
+  * Variables are ``snake_case``.
+
+  * Functions and methods are ``UpperCamelCase``.
+
+  * Static, global and member variables have ``s_``, ``g_`` and ``_m``

DavidSpickett wrote:

Thanks, fixed 
https://github.com/llvm/llvm-project/commit/87f937e9d68ae3ceea93982420f06bf90623aeba.

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

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

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

[Lldb-commits] [PATCH] D154927: [lldb][AArch64] Add SME's streaming vector control register

[David Spickett via Phabricator via lldb-commits]

DavidSpickett updated this revision to Diff 557100.
DavidSpickett added a comment.

- Return error in SVCR read.
- Note absence of write tests of SVCR because it's read only.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154927

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/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
  
lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
  
lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
  
lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py

Index: lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py
===
--- lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py
+++ lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py
@@ -164,6 +164,10 @@
 self.runCmd("register read " + sve_reg_names)
 sve_values = self.res.GetOutput()
 
+svcr_value = 1 if sve_mode == Mode.SSVE else 0
+if za_state == ZA.Enabled:
+svcr_value += 2
+
 def check_regs():
 if za_state == ZA.Enabled:
 self.check_za(start_vl)
@@ -175,6 +179,7 @@
 self.assertEqual(start_vg, self.read_vg())
 
 self.expect("register read " + sve_reg_names, substrs=[sve_values])
+self.expect("register read svcr", substrs=["0x{:016x}".format(svcr_value)])
 
 for expr in exprs:
 expr_cmd = "expression {}()".format(expr)
Index: lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
===
--- lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
+++ lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
@@ -9,7 +9,7 @@
 #define PR_SME_SET_VL 63
 #endif
 
-#define SMSTART() asm volatile("msr  s0_3_c4_c7_3, xzr" /*smstart*/)
+#define SMSTART_SM() asm volatile("msr  s0_3_c4_c3_3, xzr" /*smstart sm*/)
 
 void write_sve_regs() {
   // We assume the smefa64 feature is present, which allows ffr access
@@ -130,18 +130,18 @@
   // Note that doing a syscall brings you back to non-streaming mode, so we
   // don't need to SMSTOP here.
   if (streaming)
-SMSTART();
+SMSTART_SM();
   write_sve_regs_expr();
   prctl(SET_VL_OPT, 8 * 4);
   if (streaming)
-SMSTART();
+SMSTART_SM();
   write_sve_regs_expr();
   return 1;
 }
 
 int main() {
 #ifdef START_SSVE
-  SMSTART();
+  SMSTART_SM();
 #endif
   write_sve_regs();
 
Index: lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
===
--- lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
+++ lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
@@ -24,7 +24,15 @@
 reg_value.GetByteSize(), expected, 'Verify "%s" == %i' % (name, expected)
 )
 
-def check_sve_regs_read(self, z_reg_size):
+def check_sve_regs_read(self, z_reg_size, expected_mode):
+if self.isAArch64SME():
+# This test uses SMSTART SM, which only enables streaming mode,
+# leaving ZA disabled.
+expected_value = "1" if expected_mode == Mode.SSVE else "0"
+self.expect(
+"register read svcr", substrs=["0x000" + expected_value]
+)
+
 p_reg_size = int(z_reg_size / 8)
 
 for i in range(32):
@@ -168,7 +176,7 @@
 
 vg_reg_value = sve_registers.GetChildMemberWithName("vg").GetValueAsUnsigned()
 z_reg_size = vg_reg_value * 8
-self.check_sve_regs_read(z_reg_size)
+self.check_sve_regs_read(z_reg_size, start_mode)
 
 # Evaluate simple expression and print function expr_eval_func address.
 self.expect("expression expr_eval_func", substrs=["= 0x"])
@@ -184,7 +192,7 @@
 
 # We called a jitted function above which must not have changed SVE
 # vector length or register values.
-self.check_sve_regs_read(z_reg_size)
+self.check_sve_regs_read(z_reg_size, start_mode)
 
 self.check_sve_regs_read_after_write(z_reg_size)
 
Index: lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
===

[Lldb-commits] [PATCH] D154927: [lldb][AArch64] Add SME's streaming vector control register

[David Spickett via Phabricator via lldb-commits]

DavidSpickett marked 2 inline comments as done.
DavidSpickett added inline comments.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:1181
+
+  return {};
+}

DavidSpickett wrote:
> omjavaid wrote:
> > Shouldnt we build a relevant error message here incase ReadSMEControl fails 
> > on ReadZAHeader
> I think this should be `return error` in fact, let me check what that does.
I now return the underlying error so it won't fail silently.



Comment at: 
lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py:183
+self.expect("register read svcr", 
substrs=["0x{:016x}".format(svcr_value)])
 
 for expr in exprs:

DavidSpickett wrote:
> omjavaid wrote:
> > should we also add a svcr write test here? 
> It's read only. We could allow writes but it introduces a lot more ways to 
> change state, most of which aren't obviously useful for the user. If someone 
> really wants it, it can be added.
> 
> I will note this in a comment here.
I've actually added comments to the other file, where it makes more sense that 
you might be writing to svcr.

Here the whole test is about having the program setup the registers, and modify 
them. So there's less expectation that you'd check writing here.

The fact that SVCR is read only (as is SVG) will be documented in fully 
https://github.com/llvm/llvm-project/pull/66767.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154927

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

[Lldb-commits] [PATCH] D158500: [lldb][AArch64] Linux corefile support for SME

[David Spickett via Phabricator via lldb-commits]

DavidSpickett updated this revision to Diff 557101.
DavidSpickett added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158500

Files:
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.h
  lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
  lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
  lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
  lldb/test/API/linux/aarch64/sme_core_file/TestAArch64LinuxSMECoreFile.py
  lldb/test/API/linux/aarch64/sme_core_file/core_0_16_32_1
  lldb/test/API/linux/aarch64/sme_core_file/core_0_32_16_0
  lldb/test/API/linux/aarch64/sme_core_file/core_1_16_32_0
  lldb/test/API/linux/aarch64/sme_core_file/core_1_32_16_1
  lldb/test/API/linux/aarch64/sme_core_file/main.c

Index: lldb/test/API/linux/aarch64/sme_core_file/main.c
===
--- /dev/null
+++ lldb/test/API/linux/aarch64/sme_core_file/main.c
@@ -0,0 +1,140 @@
+// clang-format off
+// Compile with:
+// clang -target aarch64-unknown-linux-gnu main.c -o a.out -g -march=armv8.6-a+sve+sme
+//
+// For minimal corefile size, do this before running the program:
+// echo 0x20 > /proc/self/coredeump_filter
+//
+// Must be run on a system that has SVE and SME, including the smefa64
+// extension. Example command:
+// main 0 32 64 1
+//
+// This would not enter streaming mode, set non-streaming VL to 32
+// bytes, streaming VL to 64 bytes and enable ZA.
+// clang-format on
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef PR_SME_SET_VL
+#define PR_SME_SET_VL 63
+#endif
+
+#define SM_INST(c) asm volatile("msr s0_3_c4_c" #c "_3, xzr")
+#define SMSTART_SM SM_INST(3)
+#define SMSTART_ZA SM_INST(5)
+
+void set_sve_registers() {
+  // We assume the smefa64 feature is present, which allows ffr access
+  // in streaming mode.
+  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");
+}
+
+void set_za_register(int streaming_vl) {
+#define MAX_VL_BYTES 256
+  uint8_t data[MAX_VL_BYTES];
+
+  for (unsigned i = 0; i < streaming_vl; ++i) {
+for (unsigned j = 0; j < MAX_VL_BYTES; ++j)
+  data[j] = i + 1;
+asm volatile("mov w12, %w0\n\t"
+ "ldr za[w12, 0], [%1]\n\t" ::"r"(i),
+ "r"(&data)
+ : "w12");
+  }
+}
+
+void set_tpidr2(uint64_t value) {
+  __asm__ volatile("msr S3_3_C13_C0_5, %0" ::"r"(value));
+}
+
+int main(int argc, char **argv) {
+  // Arguments:
+  //  SVE mode: 1 for streaming SVE (SSVE), any other value
+  //  for non-streaming SVE mode.
+  //   Non-Streaming Vector length: In bytes, an integer e.g. "32".
+  //   Streaming Vector length: As above, but for streaming mode.
+  //   ZA mode: 1 for enabled, any other value for disabled.
+  if (argc != 5)
+return 1;
+
+  // We assume this is run on 

[Lldb-commits] [lldb] 1446e3c - Revert "Fix a bug with cancelling "attach -w" after you have run a process previously (#65822)"

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2023-09-20T08:19:53Z
New Revision: 1446e3cf7605f0988b914fac0a34d63045394ff3

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

LOG: Revert "Fix a bug with cancelling "attach -w" after you have run a process 
previously (#65822)"

This reverts commit 7265f792dc8e1157a3874aee5f8aed6d4d8236e7.

The new test case is flaky on Linux AArch64 
(https://lab.llvm.org/buildbot/#/builders/96)
and more flaky on Windows on Arm 
(https://lab.llvm.org/buildbot/#/builders/219/builds/5735).

Added: 


Modified: 
lldb/include/lldb/Interpreter/CommandInterpreter.h
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Target/Process.cpp
lldb/test/API/commands/process/attach/TestProcessAttach.py
lldb/test/API/commands/process/attach/main.cpp

Removed: 




diff  --git a/lldb/include/lldb/Interpreter/CommandInterpreter.h 
b/lldb/include/lldb/Interpreter/CommandInterpreter.h
index 960a1c18f0130ab..747188a15312fa3 100644
--- a/lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ b/lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -447,7 +447,7 @@ class CommandInterpreter : public Broadcaster,
 
   Debugger &GetDebugger() { return m_debugger; }
 
-  ExecutionContext GetExecutionContext();
+  ExecutionContext GetExecutionContext() const;
 
   lldb::PlatformSP GetPlatform(bool prefer_target_platform);
 
@@ -661,7 +661,7 @@ class CommandInterpreter : public Broadcaster,
 
   void GetProcessOutput();
 
-  bool DidProcessStopAbnormally();
+  bool DidProcessStopAbnormally() const;
 
   void SetSynchronous(bool value);
 

diff  --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index 9f1f520abb198f0..dcff53ff843f328 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -2471,7 +2471,7 @@ PlatformSP CommandInterpreter::GetPlatform(bool 
prefer_target_platform) {
   return platform_sp;
 }
 
-bool CommandInterpreter::DidProcessStopAbnormally() {
+bool CommandInterpreter::DidProcessStopAbnormally() const {
   auto exe_ctx = GetExecutionContext();
   TargetSP target_sp = exe_ctx.GetTargetSP();
   if (!target_sp)
@@ -2976,22 +2976,10 @@ void 
CommandInterpreter::FindCommandsForApropos(llvm::StringRef search_word,
m_alias_dict);
 }
 
-ExecutionContext CommandInterpreter::GetExecutionContext() {
-  ExecutionContext exe_ctx;
-  if (!m_overriden_exe_contexts.empty()) {
-// During the course of a command, the target may have replaced the 
process 
-// coming in with another.  I fix that here:
-exe_ctx = m_overriden_exe_contexts.top();
-// Don't use HasProcessScope, that returns false if there is a process but
-// it's no longer valid, which is one of the cases we want to catch here.
-if (exe_ctx.HasTargetScope() && exe_ctx.GetProcessPtr()) {
-  ProcessSP actual_proc_sp = exe_ctx.GetTargetSP()->GetProcessSP();
-  if (actual_proc_sp != exe_ctx.GetProcessSP())
-m_overriden_exe_contexts.top().SetContext(actual_proc_sp);
-}
-return m_overriden_exe_contexts.top();
-  }
-  return m_debugger.GetSelectedExecutionContext();
+ExecutionContext CommandInterpreter::GetExecutionContext() const {
+  return !m_overriden_exe_contexts.empty()
+ ? m_overriden_exe_contexts.top()
+ : m_debugger.GetSelectedExecutionContext();
 }
 
 void CommandInterpreter::OverrideExecutionContext(
@@ -3184,17 +3172,12 @@ void 
CommandInterpreter::IOHandlerInputComplete(IOHandler &io_handler,
 }
 
 bool CommandInterpreter::IOHandlerInterrupt(IOHandler &io_handler) {
-  // InterruptCommand returns true if this is the first time
-  // we initiate an interrupt for this command.  So we give the
-  // command a chance to handle the interrupt on the first
-  // interrupt, but if that didn't do anything, a second
-  // interrupt will do more work to halt the process/interpreter.
-  if (InterruptCommand()) 
-return true;
-
   ExecutionContext exe_ctx(GetExecutionContext());
   Process *process = exe_ctx.GetProcessPtr();
 
+  if (InterruptCommand())
+return true;
+
   if (process) {
 StateType state = process->GetState();
 if (StateIsRunningState(state)) {

diff  --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index d30557312f7a8f9..f82ab05362fbee9 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -3153,14 +3153,6 @@ Status Process::Halt(bool clear_thread_plans, bool 
use_run_lock) {
   // case it was already set and some thread plan logic calls halt on its own.
   m_clear_thread_plans_on_stop |= clear_thread_plans;
 
-  if (m_public_state.GetValue() == eStateAttaching) {
-// Don't hijack and eat the eStateExited as the code t

[Lldb-commits] [lldb] Fix a bug with cancelling "attach -w" after you have run a process previously (PR #65822)

[David Spickett via lldb-commits]

DavidSpickett wrote:

This is failing on AArch64 Linux and Windows, it finds some async error in the 
output but the bots don't say what. I'll find what it is.

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

[Lldb-commits] [PATCH] D154927: [lldb][AArch64] Add SME's streaming vector control register

[Muhammad Omair Javaid via Phabricator via lldb-commits]

omjavaid accepted this revision.
omjavaid added a comment.
This revision is now accepted and ready to land.

This is good too. Thanks!!!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154927

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

[Lldb-commits] [lldb] Fix a bug with cancelling "attach -w" after you have run a process previously (PR #65822)

[David Spickett via lldb-commits]

@@ -127,3 +128,65 @@ def tearDown(self):
 
 # Call super's tearDown().
 TestBase.tearDown(self)
+
+def test_run_then_attach_wait_interrupt(self):
+# Test that having run one process doesn't cause us to be unable
+# to interrupt a subsequent attach attempt.
+self.build()
+exe = self.getBuildArtifact(exe_name)
+
+target = lldbutil.run_to_breakpoint_make_target(self, exe_name, True)
+launch_info = target.GetLaunchInfo()
+launch_info.SetArguments(["q"], True)
+error = lldb.SBError()
+target.Launch(launch_info, error)
+self.assertSuccess(error, "Launched a process")
+self.assertState(target.process.state, lldb.eStateExited, "and it 
exited.") 
+
+# Okay now we've run a process, try to attach/wait to something
+# and make sure that we can interrupt that.
+
+options = lldb.SBCommandInterpreterRunOptions()
+options.SetPrintResults(True)
+options.SetEchoCommands(False)
+
+self.stdin_path = self.getBuildArtifact("stdin.txt")
+
+with open(self.stdin_path, "w") as input_handle:
+input_handle.write("process attach -w -n 
noone_would_use_this_name\nquit")
+
+# Python will close the file descriptor if all references
+# to the filehandle object lapse, so we need to keep one
+# around.
+self.filehandle = open(self.stdin_path, "r")
+self.dbg.SetInputFileHandle(self.filehandle, False)
+
+# No need to track the output
+self.stdout_path = self.getBuildArtifact("stdout.txt")
+self.out_filehandle = open(self.stdout_path, "w")
+self.dbg.SetOutputFileHandle(self.out_filehandle, False)
+self.dbg.SetErrorFileHandle(self.out_filehandle, False)
+
+n_errors, quit_req, crashed = self.dbg.RunCommandInterpreter(
+True, True, options, 0, False, False)
+
+while 1:
+time.sleep(1)
+if target.process.state == lldb.eStateAttaching:
+break
+
+self.dbg.DispatchInputInterrupt()
+self.dbg.DispatchInputInterrupt()

DavidSpickett wrote:

Why is this done twice?

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

[Lldb-commits] [lldb] [reland][libc][cmake] Tidy compiler includes (#66783) (PR #66878)

[Guillaume Chatelet via lldb-commits]

https://github.com/gchatelet created 
https://github.com/llvm/llvm-project/pull/66878

This is a reland of #66783 a35a3b75b219247eb9ff6784d1a0fe562f72d415 fixing the 
benchmark breakage.



>From b3150085acea981ca9ed55c161ee9afeccfead20 Mon Sep 17 00:00:00 2001
From: Guillaume Chatelet 
Date: Tue, 19 Sep 2023 21:16:42 +
Subject: [PATCH 1/2] Revert "[libc][cmake] Tidy compiler includes (#66783)"

This reverts commit a35a3b75b219247eb9ff6784d1a0fe562f72d415.
This broke libc benchmarks.
---
 libc/CMakeLists.txt  |  5 ---
 libc/cmake/modules/LLVMLibCObjectRules.cmake | 31 +++
 libc/cmake/modules/LLVMLibCTestRules.cmake   | 32 +++-
 libc/utils/HdrGen/CMakeLists.txt |  2 +-
 libc/utils/LibcTableGenUtil/CMakeLists.txt   |  1 -
 5 files changed, 43 insertions(+), 28 deletions(-)

diff --git a/libc/CMakeLists.txt b/libc/CMakeLists.txt
index 414be906336bf3f..0cec6fc07d982b4 100644
--- a/libc/CMakeLists.txt
+++ b/libc/CMakeLists.txt
@@ -7,11 +7,6 @@ endif()
 include(${LLVM_COMMON_CMAKE_UTILS}/Modules/CMakePolicy.cmake
   NO_POLICY_SCOPE)
 
-# `llvm-project/llvm/CMakeLists.txt` adds the following directive
-# `include_directories( ${LLVM_INCLUDE_DIR} ${LLVM_MAIN_INCLUDE_DIR})`
-# We undo it to be able to precisely control what is getting included.
-set_directory_properties(PROPERTIES INCLUDE_DIRECTORIES "")
-
 # Default to C++17
 set(CMAKE_CXX_STANDARD 17)
 
diff --git a/libc/cmake/modules/LLVMLibCObjectRules.cmake 
b/libc/cmake/modules/LLVMLibCObjectRules.cmake
index c10b81f1af8cba3..994437f55d27407 100644
--- a/libc/cmake/modules/LLVMLibCObjectRules.cmake
+++ b/libc/cmake/modules/LLVMLibCObjectRules.cmake
@@ -151,6 +151,7 @@ function(_build_gpu_objects fq_target_name 
internal_target_name)
 ${ARGN}
   )
 
+  set(include_dirs ${LIBC_SOURCE_DIR} ${LIBC_INCLUDE_DIR})
   set(common_compile_options ${ADD_GPU_OBJ_COMPILE_OPTIONS})
   if(NOT ADD_GPU_OBJ_CXX_STANDARD)
 set(ADD_GPU_OBJ_CXX_STANDARD ${CMAKE_CXX_STANDARD})
@@ -188,10 +189,13 @@ function(_build_gpu_objects fq_target_name 
internal_target_name)
   )
 
   target_compile_options(${gpu_target_name} PRIVATE ${compile_options})
-  target_include_directories(${gpu_target_name} SYSTEM PRIVATE 
${LIBC_INCLUDE_DIR})
-  target_include_directories(${gpu_target_name} PRIVATE ${LIBC_SOURCE_DIR})
+  target_include_directories(${gpu_target_name} PRIVATE ${include_dirs})
   target_compile_definitions(${gpu_target_name} PRIVATE 
LIBC_COPT_PUBLIC_PACKAGING)
-  set_target_properties(${gpu_target_name} PROPERTIES CXX_STANDARD 
${ADD_GPU_OBJ_CXX_STANDARD})
+  set_target_properties(
+${gpu_target_name}
+PROPERTIES
+  CXX_STANDARD ${ADD_GPU_OBJ_CXX_STANDARD}
+  )
   if(ADD_GPU_OBJ_DEPENDS)
 add_dependencies(${gpu_target_name} ${ADD_GPU_OBJ_DEPENDS})
   endif()
@@ -257,8 +261,7 @@ function(_build_gpu_objects fq_target_name 
internal_target_name)
 target_compile_options(${fq_target_name} PRIVATE
"SHELL:-Xclang 
-fembed-offload-object=${packaged_gpu_binary}")
   endforeach()
-  target_include_directories(${fq_target_name} SYSTEM PRIVATE 
${LIBC_INCLUDE_DIR})
-  target_include_directories(${fq_target_name} PRIVATE ${LIBC_SOURCE_DIR})
+  target_include_directories(${fq_target_name} PRIVATE ${include_dirs})
   add_dependencies(${fq_target_name}
${full_deps_list} ${packaged_gpu_names} ${stub_target_name})
 
@@ -282,8 +285,7 @@ function(_build_gpu_objects fq_target_name 
internal_target_name)
   get_nvptx_compile_options(nvptx_options ${LIBC_GPU_TARGET_ARCHITECTURE})
   target_compile_options(${internal_target_name} PRIVATE ${nvptx_options})
 endif()
-target_include_directories(${internal_target_name} SYSTEM PRIVATE 
${LIBC_INCLUDE_DIR})
-target_include_directories(${internal_target_name} PRIVATE 
${LIBC_SOURCE_DIR})
+target_include_directories(${internal_target_name} PRIVATE ${include_dirs})
 if(full_deps_list)
   add_dependencies(${internal_target_name} ${full_deps_list})
 endif()
@@ -367,8 +369,12 @@ function(create_object_library fq_target_name)
   ${ADD_OBJECT_SRCS}
   ${ADD_OBJECT_HDRS}
 )
-target_include_directories(${fq_target_name} SYSTEM PRIVATE 
${LIBC_INCLUDE_DIR})
-target_include_directories(${fq_target_name} PRIVATE ${LIBC_SOURCE_DIR})
+target_include_directories(
+  ${fq_target_name}
+  PRIVATE
+${LIBC_SOURCE_DIR}
+${LIBC_INCLUDE_DIR}
+)
 target_compile_options(${fq_target_name} PRIVATE ${compile_options})
   endif()
 
@@ -627,6 +633,7 @@ function(create_entrypoint_object fq_target_name)
 "${ADD_ENTRYPOINT_OBJ_FLAGS}"
 ${ADD_ENTRYPOINT_OBJ_COMPILE_OPTIONS}
   )
+  set(include_dirs ${LIBC_SOURCE_DIR} ${LIBC_INCLUDE_DIR})
   get_fq_deps_list(fq_deps_list ${ADD_ENTRYPOINT_OBJ_DEPENDS})
   set(full_deps_list ${fq_deps_list} libc.src.__support.common)
 
@@ -663,8 +670,7 @@ functi

[Lldb-commits] [lldb] [reland][libc][cmake] Tidy compiler includes (#66783) (PR #66878)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-libc


Changes

This is a reland of #66783 a35a3b75b219247eb9ff6784d1a0fe562f72d415 
fixing the benchmark breakage.



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


6 Files Affected:

- (modified) libc/CMakeLists.txt (+5) 
- (modified) libc/benchmarks/CMakeLists.txt (+3) 
- (modified) libc/cmake/modules/LLVMLibCObjectRules.cmake (+13-18) 
- (modified) libc/cmake/modules/LLVMLibCTestRules.cmake (+8-24) 
- (modified) libc/utils/HdrGen/CMakeLists.txt (+1-1) 
- (modified) libc/utils/LibcTableGenUtil/CMakeLists.txt (+1) 


``diff
diff --git a/libc/CMakeLists.txt b/libc/CMakeLists.txt
index 0cec6fc07d982b4..414be906336bf3f 100644
--- a/libc/CMakeLists.txt
+++ b/libc/CMakeLists.txt
@@ -7,6 +7,11 @@ endif()
 include(${LLVM_COMMON_CMAKE_UTILS}/Modules/CMakePolicy.cmake
   NO_POLICY_SCOPE)
 
+# `llvm-project/llvm/CMakeLists.txt` adds the following directive
+# `include_directories( ${LLVM_INCLUDE_DIR} ${LLVM_MAIN_INCLUDE_DIR})`
+# We undo it to be able to precisely control what is getting included.
+set_directory_properties(PROPERTIES INCLUDE_DIRECTORIES "")
+
 # Default to C++17
 set(CMAKE_CXX_STANDARD 17)
 
diff --git a/libc/benchmarks/CMakeLists.txt b/libc/benchmarks/CMakeLists.txt
index 3d665ce1c6e7198..48f5f48ff832248 100644
--- a/libc/benchmarks/CMakeLists.txt
+++ b/libc/benchmarks/CMakeLists.txt
@@ -85,6 +85,9 @@ add_library(libc-benchmark
 LibcBenchmark.h
 )
 
+target_include_directories(libc-benchmark
+PUBLIC ${LLVM_INCLUDE_DIR} ${LLVM_MAIN_INCLUDE_DIR}
+)
 target_link_libraries(libc-benchmark
 PUBLIC
 benchmark::benchmark
diff --git a/libc/cmake/modules/LLVMLibCObjectRules.cmake 
b/libc/cmake/modules/LLVMLibCObjectRules.cmake
index 994437f55d27407..c10b81f1af8cba3 100644
--- a/libc/cmake/modules/LLVMLibCObjectRules.cmake
+++ b/libc/cmake/modules/LLVMLibCObjectRules.cmake
@@ -151,7 +151,6 @@ function(_build_gpu_objects fq_target_name 
internal_target_name)
 ${ARGN}
   )
 
-  set(include_dirs ${LIBC_SOURCE_DIR} ${LIBC_INCLUDE_DIR})
   set(common_compile_options ${ADD_GPU_OBJ_COMPILE_OPTIONS})
   if(NOT ADD_GPU_OBJ_CXX_STANDARD)
 set(ADD_GPU_OBJ_CXX_STANDARD ${CMAKE_CXX_STANDARD})
@@ -189,13 +188,10 @@ function(_build_gpu_objects fq_target_name 
internal_target_name)
   )
 
   target_compile_options(${gpu_target_name} PRIVATE ${compile_options})
-  target_include_directories(${gpu_target_name} PRIVATE ${include_dirs})
+  target_include_directories(${gpu_target_name} SYSTEM PRIVATE 
${LIBC_INCLUDE_DIR})
+  target_include_directories(${gpu_target_name} PRIVATE ${LIBC_SOURCE_DIR})
   target_compile_definitions(${gpu_target_name} PRIVATE 
LIBC_COPT_PUBLIC_PACKAGING)
-  set_target_properties(
-${gpu_target_name}
-PROPERTIES
-  CXX_STANDARD ${ADD_GPU_OBJ_CXX_STANDARD}
-  )
+  set_target_properties(${gpu_target_name} PROPERTIES CXX_STANDARD 
${ADD_GPU_OBJ_CXX_STANDARD})
   if(ADD_GPU_OBJ_DEPENDS)
 add_dependencies(${gpu_target_name} ${ADD_GPU_OBJ_DEPENDS})
   endif()
@@ -261,7 +257,8 @@ function(_build_gpu_objects fq_target_name 
internal_target_name)
 target_compile_options(${fq_target_name} PRIVATE
"SHELL:-Xclang 
-fembed-offload-object=${packaged_gpu_binary}")
   endforeach()
-  target_include_directories(${fq_target_name} PRIVATE ${include_dirs})
+  target_include_directories(${fq_target_name} SYSTEM PRIVATE 
${LIBC_INCLUDE_DIR})
+  target_include_directories(${fq_target_name} PRIVATE ${LIBC_SOURCE_DIR})
   add_dependencies(${fq_target_name}
${full_deps_list} ${packaged_gpu_names} ${stub_target_name})
 
@@ -285,7 +282,8 @@ function(_build_gpu_objects fq_target_name 
internal_target_name)
   get_nvptx_compile_options(nvptx_options ${LIBC_GPU_TARGET_ARCHITECTURE})
   target_compile_options(${internal_target_name} PRIVATE ${nvptx_options})
 endif()
-target_include_directories(${internal_target_name} PRIVATE ${include_dirs})
+target_include_directories(${internal_target_name} SYSTEM PRIVATE 
${LIBC_INCLUDE_DIR})
+target_include_directories(${internal_target_name} PRIVATE 
${LIBC_SOURCE_DIR})
 if(full_deps_list)
   add_dependencies(${internal_target_name} ${full_deps_list})
 endif()
@@ -369,12 +367,8 @@ function(create_object_library fq_target_name)
   ${ADD_OBJECT_SRCS}
   ${ADD_OBJECT_HDRS}
 )
-target_include_directories(
-  ${fq_target_name}
-  PRIVATE
-${LIBC_SOURCE_DIR}
-${LIBC_INCLUDE_DIR}
-)
+target_include_directories(${fq_target_name} SYSTEM PRIVATE 
${LIBC_INCLUDE_DIR})
+target_include_directories(${fq_target_name} PRIVATE ${LIBC_SOURCE_DIR})
 target_compile_options(${fq_target_name} PRIVATE ${compile_options})
   endif()
 
@@ -633,7 +627,6 @@ function(create_entrypoint_object fq_target_name)
 "${ADD_ENTRYPOINT_OBJ_FLAGS}"
 ${ADD_ENTRYPOINT_OBJ_COMPILE_OPTIONS}
   )
-  set(include_dirs ${

[Lldb-commits] [lldb] d7fab66 - [lldb][AArch64] Add SME's streaming vector control register

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2023-09-20T10:20:45+01:00
New Revision: d7fab666955e9ef0d456b6dfb737f5a18241c97c

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

LOG: [lldb][AArch64] Add SME's streaming vector control register

Software can tell if it is in streaming SVE mode by checking
the Streaming Vector Control Register (SVCR).

"E3.1.9 SVCR, Streaming Vector Control Register" in
"Arm® Architecture Reference Manual Supplement, The Scalable Matrix
Extension (SME), for Armv9-A"

https://developer.arm.com/documentation/ddi0616/latest/

This is especially useful for debug because the names of the
SVE registers are the same betweeen non-streaming and streaming mode.

The Linux Kernel chose to not put this register behind ptrace,
and it can be read from EL0. However, this would mean running code
in process to read it. That can be done but we already know all
the information just from ptrace.

So this is a pseudo register that matches the architectural
content. The name is just "svcr", which aligns with GDB's proposed naming,
and it's added to the existing SME register set.

The SVCR register contains two bits:
0 : Whether streaming SVE mode is enabled (SM)
1 : Whether the array storage is enabled (ZA)

Array storage can be active when streaming mode is not, so this register
can have any permutation of those bits.

This register is currently read only. We can emulate the result of
writing to it, using ptrace. However at this point the utility of that
is not obvious.

Existing tests have been updated to check for appropriate SVCR values
at various points.

Given that this register is a read only pseudo, there is no need
to save and restore it around expressions.

Reviewed By: omjavaid

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

Added: 


Modified: 
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/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py

lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py

lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c

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

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
index 7d246eeb5fc9b7e..b5210c368144206 100644
--- a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -360,6 +360,9 @@ NativeRegisterContextLinux_arm64::ReadRegister(const 
RegisterInfo *reg_info,
   if (error.Fail())
 return error;
 
+  // This is a psuedo so it never fails.
+  ReadSMEControl();
+
   offset = reg_info->byte_offset - GetRegisterInfo().GetSMEOffset();
   assert(offset < GetSMEPseudoBufferSize());
   src = (uint8_t *)GetSMEPseudoBuffer() + offset;
@@ -550,7 +553,7 @@ Status NativeRegisterContextLinux_arm64::WriteRegister(
 return WriteTLS();
   } else if (IsSME(reg)) {
 if (!GetRegisterInfo().IsSMERegZA(reg))
-  return Status("Writing to SVG is not supported.");
+  return Status("Writing to SVG or SVCR is not supported.");
 
 error = ReadZA();
 if (error.Fail())
@@ -1160,6 +1163,24 @@ Status NativeRegisterContextLinux_arm64::WriteAllSVE() {
   return WriteRegisterSet(&ioVec, GetSVEBufferSize(), GetSVERegSet());
 }
 
+Status NativeRegisterContextLinux_arm64::ReadSMEControl() {
+  // The real register is SVCR and is accessible from EL0. However we don't 
want
+  // to have to JIT code into the target process so we'll just recreate it 
using
+  // what we know from ptrace.
+
+  // Bit 0 indicates whether streaming mode is active.
+  m_sme_pseudo_regs.ctrl_reg = m_sve_state == SVEState::Streaming;
+
+  // Bit 1 indicates whether the array storage is active.
+  // It is active if we can read the header and the size field tells us that
+  // there is register data following it.
+  Status error = ReadZAHeader();
+  if (error.Success() && (m_za_header.size > sizeof(m_za_header)))
+m_sme_pseudo_regs.ctrl_reg |= 2;
+
+  return error;
+}
+
 Status NativeRegisterContextLinux_arm64::ReadMTEControl() {
   Status error;
 

diff  --git 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
index 20e262fcd0f3dc9..ed2653485c3e7da 100644
--- a/lldb/source/Plugins/Process/Linux/NativeRegisterCon

[Lldb-commits] [PATCH] D154927: [lldb][AArch64] Add SME's streaming vector control register

[David Spickett via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd7fab666955e: [lldb][AArch64] Add SME's streaming 
vector control register (authored by DavidSpickett).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154927

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/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
  
lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
  
lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
  
lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py

Index: lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py
===
--- lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py
+++ lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py
@@ -164,6 +164,10 @@
 self.runCmd("register read " + sve_reg_names)
 sve_values = self.res.GetOutput()
 
+svcr_value = 1 if sve_mode == Mode.SSVE else 0
+if za_state == ZA.Enabled:
+svcr_value += 2
+
 def check_regs():
 if za_state == ZA.Enabled:
 self.check_za(start_vl)
@@ -175,6 +179,7 @@
 self.assertEqual(start_vg, self.read_vg())
 
 self.expect("register read " + sve_reg_names, substrs=[sve_values])
+self.expect("register read svcr", substrs=["0x{:016x}".format(svcr_value)])
 
 for expr in exprs:
 expr_cmd = "expression {}()".format(expr)
Index: lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
===
--- lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
+++ lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
@@ -9,7 +9,7 @@
 #define PR_SME_SET_VL 63
 #endif
 
-#define SMSTART() asm volatile("msr  s0_3_c4_c7_3, xzr" /*smstart*/)
+#define SMSTART_SM() asm volatile("msr  s0_3_c4_c3_3, xzr" /*smstart sm*/)
 
 void write_sve_regs() {
   // We assume the smefa64 feature is present, which allows ffr access
@@ -130,18 +130,18 @@
   // Note that doing a syscall brings you back to non-streaming mode, so we
   // don't need to SMSTOP here.
   if (streaming)
-SMSTART();
+SMSTART_SM();
   write_sve_regs_expr();
   prctl(SET_VL_OPT, 8 * 4);
   if (streaming)
-SMSTART();
+SMSTART_SM();
   write_sve_regs_expr();
   return 1;
 }
 
 int main() {
 #ifdef START_SSVE
-  SMSTART();
+  SMSTART_SM();
 #endif
   write_sve_regs();
 
Index: lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
===
--- lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
+++ lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
@@ -24,7 +24,15 @@
 reg_value.GetByteSize(), expected, 'Verify "%s" == %i' % (name, expected)
 )
 
-def check_sve_regs_read(self, z_reg_size):
+def check_sve_regs_read(self, z_reg_size, expected_mode):
+if self.isAArch64SME():
+# This test uses SMSTART SM, which only enables streaming mode,
+# leaving ZA disabled.
+expected_value = "1" if expected_mode == Mode.SSVE else "0"
+self.expect(
+"register read svcr", substrs=["0x000" + expected_value]
+)
+
 p_reg_size = int(z_reg_size / 8)
 
 for i in range(32):
@@ -168,7 +176,7 @@
 
 vg_reg_value = sve_registers.GetChildMemberWithName("vg").GetValueAsUnsigned()
 z_reg_size = vg_reg_value * 8
-self.check_sve_regs_read(z_reg_size)
+self.check_sve_regs_read(z_reg_size, start_mode)
 
 # Evaluate simple expression and print function expr_eval_func address.
 self.expect("expression expr_eval_func", substrs=["= 0x"])
@@ -184,7 +192,7 @@
 
 # We called a jitted function above which must not have changed SVE
 # vector length or register values.
-self.check_sve_regs_read(z_reg_size)
+self.check_sve_regs_read(z_reg_size, start_mode)
 
 self.check_sve_regs_read_after_write(z_reg_size)
 
Index: lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64Dyna

[Lldb-commits] [lldb] [reland][libc][cmake] Tidy compiler includes (#66783) (PR #66878)

[Guillaume Chatelet via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][DWARFASTParserClang] Resolve nested types when parsing structures (PR #66879)

[Vlad Serebrennikov via lldb-commits]

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

Migrated from https://reviews.llvm.org/D156774

>From 72f83fb2944829c60bd6f12a079bfba95da4f6e7 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Thu, 14 Sep 2023 09:46:53 +0300
Subject: [PATCH 1/2] Implementation (migrated from Phabricator)

---
 .../SymbolFile/DWARF/DWARFASTParserClang.cpp  | 15 +--
 .../SymbolFile/DWARF/DWARFASTParserClang.h|  2 +-
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 37fb16d4e0351c9..fc340da8eba0763 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -2150,14 +2150,14 @@ bool DWARFASTParserClang::CompleteRecordType(const 
DWARFDIE &die,
 
 std::vector> bases;
 // Parse members and base classes first
-std::vector member_function_dies;
+std::vector member_function_and_type_dies;
 
 DelayedPropertyList delayed_properties;
-ParseChildMembers(die, clang_type, bases, member_function_dies,
+ParseChildMembers(die, clang_type, bases, member_function_and_type_dies,
   delayed_properties, default_accessibility, layout_info);
 
-// Now parse any methods if there were any...
-for (const DWARFDIE &die : member_function_dies)
+// Now parse any methods or nested types if there were any...
+for (const DWARFDIE &die : member_function_and_type_dies)
   dwarf->ResolveType(die);
 
 if (type_is_objc_object_or_interface) {
@@ -3153,7 +3153,7 @@ void DWARFASTParserClang::ParseSingleMember(
 bool DWARFASTParserClang::ParseChildMembers(
 const DWARFDIE &parent_die, CompilerType &class_clang_type,
 std::vector> &base_classes,
-std::vector &member_function_dies,
+std::vector &member_function_and_type_dies,
 DelayedPropertyList &delayed_properties,
 const AccessType default_accessibility,
 ClangASTImporter::LayoutInfo &layout_info) {
@@ -3189,8 +3189,11 @@ bool DWARFASTParserClang::ParseChildMembers(
   break;
 
 case DW_TAG_subprogram:
+case DW_TAG_enumeration_type:
+case DW_TAG_structure_type:
+case DW_TAG_union_type:
   // Let the type parsing code handle this one for us.
-  member_function_dies.push_back(die);
+  member_function_and_type_dies.push_back(die);
   break;
 
 case DW_TAG_inheritance:
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
index 88bfc490e890744..d4218959e61a8fa 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
@@ -157,7 +157,7 @@ class DWARFASTParserClang : public DWARFASTParser {
   bool ParseChildMembers(
   const DWARFDIE &die, lldb_private::CompilerType &class_compiler_type,
   std::vector> &base_classes,
-  std::vector &member_function_dies,
+  std::vector &member_function_and_type_dies,
   DelayedPropertyList &delayed_properties,
   const lldb::AccessType default_accessibility,
   lldb_private::ClangASTImporter::LayoutInfo &layout_info);

>From 4a4aa7ad35124414aafdb7db44c89e51f498aa83 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Wed, 20 Sep 2023 12:32:44 +0300
Subject: [PATCH 2/2] Add an incomplete unit test

---
 .../DWARF/DWARFASTParserClangTests.cpp| 93 +++
 1 file changed, 93 insertions(+)

diff --git a/lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp 
b/lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
index 20a085741f73d00..d47f9b636ec15eb 100644
--- a/lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
+++ b/lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
@@ -462,3 +462,96 @@ TEST_F(DWARFASTParserClangTests, 
TestDefaultTemplateParamParsing) {
 }
   }
 }
+
+TEST_F(DWARFASTParserClangTests, EnsureNestedTypesOfTypeAreParsed) {
+  const char *yamldata = R"(
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_386
+DWARF:
+  debug_str:
+- Info
+- B
+- C
+- Mask
+- Enum
+  debug_abbrev:
+- Table:
+- Code:0x1
+  Tag: DW_TAG_compile_unit
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_language
+  Form:DW_FORM_data2
+- Code:0x2
+  Tag: DW_TAG_structure_type
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x3
+  Tag: DW_TAG_union_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:

[Lldb-commits] [lldb] [lldb][DWARFASTParserClang] Resolve nested types when parsing structures (PR #66879)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb


Changes

Migrated from https://reviews.llvm.org/D156774

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


3 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
(+9-6) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h (+1-1) 
- (modified) lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp (+93) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 37fb16d4e0351c9..fc340da8eba0763 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -2150,14 +2150,14 @@ bool DWARFASTParserClang::CompleteRecordType(const 
DWARFDIE &die,
 
 std::vector> bases;
 // Parse members and base classes first
-std::vector member_function_dies;
+std::vector member_function_and_type_dies;
 
 DelayedPropertyList delayed_properties;
-ParseChildMembers(die, clang_type, bases, member_function_dies,
+ParseChildMembers(die, clang_type, bases, member_function_and_type_dies,
   delayed_properties, default_accessibility, layout_info);
 
-// Now parse any methods if there were any...
-for (const DWARFDIE &die : member_function_dies)
+// Now parse any methods or nested types if there were any...
+for (const DWARFDIE &die : member_function_and_type_dies)
   dwarf->ResolveType(die);
 
 if (type_is_objc_object_or_interface) {
@@ -3153,7 +3153,7 @@ void DWARFASTParserClang::ParseSingleMember(
 bool DWARFASTParserClang::ParseChildMembers(
 const DWARFDIE &parent_die, CompilerType &class_clang_type,
 std::vector> &base_classes,
-std::vector &member_function_dies,
+std::vector &member_function_and_type_dies,
 DelayedPropertyList &delayed_properties,
 const AccessType default_accessibility,
 ClangASTImporter::LayoutInfo &layout_info) {
@@ -3189,8 +3189,11 @@ bool DWARFASTParserClang::ParseChildMembers(
   break;
 
 case DW_TAG_subprogram:
+case DW_TAG_enumeration_type:
+case DW_TAG_structure_type:
+case DW_TAG_union_type:
   // Let the type parsing code handle this one for us.
-  member_function_dies.push_back(die);
+  member_function_and_type_dies.push_back(die);
   break;
 
 case DW_TAG_inheritance:
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
index 88bfc490e890744..d4218959e61a8fa 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
@@ -157,7 +157,7 @@ class DWARFASTParserClang : public DWARFASTParser {
   bool ParseChildMembers(
   const DWARFDIE &die, lldb_private::CompilerType &class_compiler_type,
   std::vector> &base_classes,
-  std::vector &member_function_dies,
+  std::vector &member_function_and_type_dies,
   DelayedPropertyList &delayed_properties,
   const lldb::AccessType default_accessibility,
   lldb_private::ClangASTImporter::LayoutInfo &layout_info);
diff --git a/lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp 
b/lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
index 20a085741f73d00..d47f9b636ec15eb 100644
--- a/lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
+++ b/lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
@@ -462,3 +462,96 @@ TEST_F(DWARFASTParserClangTests, 
TestDefaultTemplateParamParsing) {
 }
   }
 }
+
+TEST_F(DWARFASTParserClangTests, EnsureNestedTypesOfTypeAreParsed) {
+  const char *yamldata = R"(
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_386
+DWARF:
+  debug_str:
+- Info
+- B
+- C
+- Mask
+- Enum
+  debug_abbrev:
+- Table:
+- Code:0x1
+  Tag: DW_TAG_compile_unit
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_language
+  Form:DW_FORM_data2
+- Code:0x2
+  Tag: DW_TAG_structure_type
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x3
+  Tag: DW_TAG_union_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x4
+  Tag: DW_TAG_structure_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x5
+  Tag: DW_TAG

[Lldb-commits] [lldb] [lldb][DWARFASTParserClang] Resolve nested types when parsing structures (PR #66879)

[Vlad Serebrennikov via lldb-commits]

@@ -462,3 +462,96 @@ TEST_F(DWARFASTParserClangTests, 
TestDefaultTemplateParamParsing) {
 }
   }
 }
+
+TEST_F(DWARFASTParserClangTests, EnsureNestedTypesOfTypeAreParsed) {
+  const char *yamldata = R"(

Endilll wrote:

I find this YAML way of describing debug info quite unfriendly, especially 
compared to the output of `llvm-dwarfdump`. Anyway, I tried to encode debug 
info for the following snippet:
```cpp
struct Info {
  enum Mask : uintptr_t {
Enum =  ~(uintptr_t)(((intptr_t)1 << 3) - 1);
  };
  union B {};
  struct C {};
}
```
Filtered out llvm-dwarfdump output:
```
0x000c: DW_TAG_compile_unit
  DW_AT_language [DW_FORM_data2](DW_LANG_C_plus_plus_14)

0x002c:   DW_TAG_structure_type
DW_AT_calling_convention [DW_FORM_data1]
(DW_CC_pass_by_value)
DW_AT_name [DW_FORM_strx1]  ("Info")
DW_AT_byte_size [DW_FORM_data1] (0x04)

0x003a: DW_TAG_union_type
  DW_AT_calling_convention [DW_FORM_data1]  
(DW_CC_pass_by_value)
  DW_AT_name [DW_FORM_strx1]("B")
  DW_AT_byte_size [DW_FORM_data1]   (0x01)

0x0049: DW_TAG_structure_type
  DW_AT_calling_convention [DW_FORM_data1]  
(DW_CC_pass_by_value)
  DW_AT_name [DW_FORM_strx1]("C")
  DW_AT_byte_size [DW_FORM_data1]   (0x01)

0x003b: DW_TAG_enumeration_type
  DW_AT_type [DW_FORM_ref4] (0x005e "uintptr_t")
  DW_AT_name [DW_FORM_strx1]("Mask")
  DW_AT_byte_size [DW_FORM_data1]   (0x08)

0x0044:   DW_TAG_enumerator
DW_AT_name [DW_FORM_strx1]  ("Enum")
DW_AT_const_value [DW_FORM_udata]   (18446744073709551608)
```

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

[Lldb-commits] [lldb] [lldb][DWARFASTParserClang] Resolve nested types when parsing structures (PR #66879)

[Vlad Serebrennikov via lldb-commits]

@@ -462,3 +462,96 @@ TEST_F(DWARFASTParserClangTests, 
TestDefaultTemplateParamParsing) {
 }
   }
 }
+
+TEST_F(DWARFASTParserClangTests, EnsureNestedTypesOfTypeAreParsed) {
+  const char *yamldata = R"(
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_386
+DWARF:
+  debug_str:
+- Info
+- B
+- C
+- Mask
+- Enum
+  debug_abbrev:
+- Table:
+- Code:0x1
+  Tag: DW_TAG_compile_unit
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_language
+  Form:DW_FORM_data2
+- Code:0x2
+  Tag: DW_TAG_structure_type
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x3
+  Tag: DW_TAG_union_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x4
+  Tag: DW_TAG_structure_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x5
+  Tag: DW_TAG_enumeration_type
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x6
+  Tag: DW_TAG_enumerator
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp  
+  debug_info:
+- Version: 5
+  AddrSize:8
+  UnitType:DW_UT_compile
+  Entries:
+- AbbrCode:0x1
+  Values:
+- Value:   0x21
+- AbbrCode:0x2
+  Values:
+- Value:   0x0
+- AbbrCode:0x3
+  Values:
+- Value:   0x5
+- AbbrCode:0x4
+  Values:
+- Value:   0x7
+- AbbrCode:0x5
+  Values:
+- Value:   0x9
+- AbbrCode:0x6
+  Values:
+- Value:   0xE
+)";
+
+  YAMLModuleTester t(yamldata);
+
+  DWARFUnit *unit = t.GetDwarfUnit();
+  ASSERT_NE(unit, nullptr);
+  const DWARFDebugInfoEntry *cu_entry = unit->DIE().GetDIE();
+  ASSERT_EQ(cu_entry->Tag(), DW_TAG_compile_unit);
+  DWARFDIE cu_die(unit, cu_entry);
+
+  auto holder = std::make_unique("ast");
+  auto &ast_ctx = *holder->GetAST();
+  DWARFASTParserClangStub ast_parser(ast_ctx);
+
+  EXPECT_TRUE(false);

Endilll wrote:

@Michael137 Can you help me with the rest of this test? I'm changing function 
that complete (presumably) incomplete CompilerType's, but I'm not sure how to 
gather all required input to call it. Maybe that's not even the right way to 
write the test I need to write. 

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

[Lldb-commits] [lldb] [lldb][DWARFASTParserClang] Resolve nested types when parsing structures (PR #66879)

[Vlad Serebrennikov via lldb-commits]

@@ -462,3 +462,96 @@ TEST_F(DWARFASTParserClangTests, 
TestDefaultTemplateParamParsing) {
 }
   }
 }
+
+TEST_F(DWARFASTParserClangTests, EnsureNestedTypesOfTypeAreParsed) {
+  const char *yamldata = R"(
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_386
+DWARF:
+  debug_str:
+- Info
+- B
+- C
+- Mask
+- Enum
+  debug_abbrev:
+- Table:
+- Code:0x1
+  Tag: DW_TAG_compile_unit
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_language
+  Form:DW_FORM_data2
+- Code:0x2
+  Tag: DW_TAG_structure_type
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x3
+  Tag: DW_TAG_union_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x4
+  Tag: DW_TAG_structure_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x5
+  Tag: DW_TAG_enumeration_type
+  Children:DW_CHILDREN_yes

Endilll wrote:

Apparently I have to encode tree-like structure (see C++ code above) in a flat 
list, which doesn't seem natural. I wonder if YAML I've written is even 
sensible.

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

[Lldb-commits] [PATCH] D156774: [lldb][DWARFASTParserClang] Resolve nested types when parsing structures

[Vlad Serebrennikov via Phabricator via lldb-commits]

Endill added a comment.

@Michael137 I moved this over to GitHub 
, and I need your help there 
writing the unit test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156774

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

[Lldb-commits] [lldb] Fix a bug with cancelling "attach -w" after you have run a process previously (PR #65822)

[David Spickett via lldb-commits]

@@ -127,3 +128,65 @@ def tearDown(self):
 
 # Call super's tearDown().
 TestBase.tearDown(self)
+
+def test_run_then_attach_wait_interrupt(self):
+# Test that having run one process doesn't cause us to be unable
+# to interrupt a subsequent attach attempt.
+self.build()
+exe = self.getBuildArtifact(exe_name)
+
+target = lldbutil.run_to_breakpoint_make_target(self, exe_name, True)
+launch_info = target.GetLaunchInfo()
+launch_info.SetArguments(["q"], True)
+error = lldb.SBError()
+target.Launch(launch_info, error)
+self.assertSuccess(error, "Launched a process")
+self.assertState(target.process.state, lldb.eStateExited, "and it 
exited.") 
+
+# Okay now we've run a process, try to attach/wait to something
+# and make sure that we can interrupt that.
+
+options = lldb.SBCommandInterpreterRunOptions()
+options.SetPrintResults(True)
+options.SetEchoCommands(False)
+
+self.stdin_path = self.getBuildArtifact("stdin.txt")
+
+with open(self.stdin_path, "w") as input_handle:
+input_handle.write("process attach -w -n 
noone_would_use_this_name\nquit")
+
+# Python will close the file descriptor if all references
+# to the filehandle object lapse, so we need to keep one
+# around.
+self.filehandle = open(self.stdin_path, "r")
+self.dbg.SetInputFileHandle(self.filehandle, False)
+
+# No need to track the output
+self.stdout_path = self.getBuildArtifact("stdout.txt")
+self.out_filehandle = open(self.stdout_path, "w")
+self.dbg.SetOutputFileHandle(self.out_filehandle, False)
+self.dbg.SetErrorFileHandle(self.out_filehandle, False)
+
+n_errors, quit_req, crashed = self.dbg.RunCommandInterpreter(
+True, True, options, 0, False, False)
+
+while 1:
+time.sleep(1)
+if target.process.state == lldb.eStateAttaching:
+break
+
+self.dbg.DispatchInputInterrupt()
+self.dbg.DispatchInputInterrupt()
+
+self.out_filehandle.flush()
+reader = open(self.stdout_path, "r")
+results = reader.readlines()
+found_result = False
+for line in results:
+if "Cancelled async attach" in line:
+found_result = True
+break
+self.assertTrue(found_result, "Found async error in results")

DavidSpickett wrote:

This fails if `results` is empty.
```

[]

FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
test_run_then_attach_wait_interrupt (TestProcessAttach.ProcessAttachTestCase)
: success

Restore dir to: /home/david.spickett/build-llvm-aarch64
==
FAIL: test_run_then_attach_wait_interrupt 
(TestProcessAttach.ProcessAttachTestCase)
--
Traceback (most recent call last):
  File 
"/home/david.spickett/llvm-project/lldb/test/API/commands/process/attach/TestProcessAttach.py",
 line 195, in test_run_then_attach_wait_interrupt
self.assertTrue(found_result, "Found async error in results")
AssertionError: False is not True : Found async error in results
Config=aarch64-/home/david.spickett/build-llvm-aarch64/bin/clang
--
```
When the test works the results contain:
```

['error: attach failed: Cancelled async attach.\n', '\n', '... Interrupted.\n']

```
Running it in a loop it took ~40 runs to get a failing one.

I wonder if that is because the attach happens to finish a lot faster 
sometimes, so there's no time to cancel it? If that's down to the OS and 
machine load, I'm not sure how we'd make this predictable.

The ugly option is to say if the results are empty, pass the test and assume 
the other 39 runs will check for the bug.

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

[Lldb-commits] [lldb] 3d422c4 - [lldb][API] Remove debug print in TestRunLocker.py

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2023-09-20T10:01:32Z
New Revision: 3d422c46828387770be07547d335a71719901979

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

LOG: [lldb][API] Remove debug print in TestRunLocker.py

Added: 


Modified: 
lldb/test/API/python_api/run_locker/TestRunLocker.py

Removed: 




diff  --git a/lldb/test/API/python_api/run_locker/TestRunLocker.py 
b/lldb/test/API/python_api/run_locker/TestRunLocker.py
index 786cae10ab555ed..7604754fff57636 100644
--- a/lldb/test/API/python_api/run_locker/TestRunLocker.py
+++ b/lldb/test/API/python_api/run_locker/TestRunLocker.py
@@ -83,7 +83,6 @@ def runlocker_test(self, stop_at_entry):
 val = target.EvaluateExpression("SomethingToCall()")
 error = val.GetError()
 self.assertTrue(error.Fail(), "Failed to run expression")
-print(f"Got Error: {error.GetCString()}")
 self.assertIn(
 "can't evaluate expressions when the process is running",
 error.GetCString(),



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

[Lldb-commits] [lldb] [lldb][DWARFASTParserClang] Resolve nested types when parsing structures (PR #66879)

[Michael Buch via lldb-commits]

@@ -462,3 +462,96 @@ TEST_F(DWARFASTParserClangTests, 
TestDefaultTemplateParamParsing) {
 }
   }
 }
+
+TEST_F(DWARFASTParserClangTests, EnsureNestedTypesOfTypeAreParsed) {
+  const char *yamldata = R"(
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_386
+DWARF:
+  debug_str:
+- Info
+- B
+- C
+- Mask
+- Enum
+  debug_abbrev:
+- Table:
+- Code:0x1
+  Tag: DW_TAG_compile_unit
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_language
+  Form:DW_FORM_data2
+- Code:0x2
+  Tag: DW_TAG_structure_type
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x3
+  Tag: DW_TAG_union_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x4
+  Tag: DW_TAG_structure_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x5
+  Tag: DW_TAG_enumeration_type
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x6
+  Tag: DW_TAG_enumerator
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp  
+  debug_info:
+- Version: 5
+  AddrSize:8
+  UnitType:DW_UT_compile
+  Entries:
+- AbbrCode:0x1
+  Values:
+- Value:   0x21
+- AbbrCode:0x2
+  Values:
+- Value:   0x0
+- AbbrCode:0x3
+  Values:
+- Value:   0x5
+- AbbrCode:0x4
+  Values:
+- Value:   0x7
+- AbbrCode:0x5
+  Values:
+- Value:   0x9
+- AbbrCode:0x6
+  Values:
+- Value:   0xE
+)";
+
+  YAMLModuleTester t(yamldata);
+
+  DWARFUnit *unit = t.GetDwarfUnit();
+  ASSERT_NE(unit, nullptr);
+  const DWARFDebugInfoEntry *cu_entry = unit->DIE().GetDIE();
+  ASSERT_EQ(cu_entry->Tag(), DW_TAG_compile_unit);
+  DWARFDIE cu_die(unit, cu_entry);
+
+  auto holder = std::make_unique("ast");
+  auto &ast_ctx = *holder->GetAST();
+  DWARFASTParserClangStub ast_parser(ast_ctx);
+
+  EXPECT_TRUE(false);

Michael137 wrote:

Thanks for continuing!

I'll have a look at this unit-test locally. We can try doing 
`ParseTypeFromDWARF` on the `Info` DIE to do the DWARF parsing (we do it 
elsewhere in the test too). Then call `CompleteType` on the resulting type to 
go through the new codepath you added.

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

[Lldb-commits] [lldb] 96b1784 - [lldb-vscode] Use auto summaries whenever variables don't have a summary (#66551)

[via lldb-commits]

Author: Walter Erquinigo
Date: 2023-09-20T10:23:41-04:00
New Revision: 96b1784ac8c52fb912150de1387117de62de13ad

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

LOG: [lldb-vscode] Use auto summaries whenever variables don't have a summary 
(#66551)

Auto summaries were only being used when non-pointer/reference variables
didn't have values nor summaries. Greg pointed out that it should be
better to simply use auto summaries when the variable doesn't have a
summary of its own, regardless of other conditions.

This led to code simplification and correct visualization of auto
summaries for pointer/reference types, as seen in this screenshot.

https://github.com/llvm/llvm-project/assets/1613874/d356d579-13f2-487b-ae3a-f3443dce778f";>

Added: 


Modified: 
lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
lldb/tools/lldb-vscode/JSONUtils.cpp

Removed: 




diff  --git a/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py 
b/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
index 3cfe02ef6aa1576..d1b73e1a057e1da 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
@@ -63,8 +63,9 @@ def run_test_evaluate_expressions(
 "struct1", "{foo:15}" if enableAutoVariableSummaries else 
"my_struct @ 0x"
 )
 self.assertEvaluate(
-"struct2", "{foo:16}" if enableAutoVariableSummaries else "0x.*"
+"struct2", "0x.* {foo:16}" if enableAutoVariableSummaries else 
"0x.*"
 )
+self.assertEvaluate("struct3", "0x.*0")
 self.assertEvaluate("struct1.foo", "15")
 self.assertEvaluate("struct2->foo", "16")
 

diff  --git a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp 
b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
index 3a541b21b220828..f09d00e6444bb79 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
@@ -18,6 +18,7 @@ struct my_struct {
 int main(int argc, char const *argv[]) {
   my_struct struct1 = {15};
   my_struct *struct2 = new my_struct{16};
+  my_struct *struct3 = nullptr;
   int var1 = 20;
   int var2 = 21;
   int var3 = static_int; // breakpoint 1
@@ -43,6 +44,6 @@ int main(int argc, char const *argv[]) {
   my_bool_vec.push_back(true);
   my_bool_vec.push_back(false); // breakpoint 6
   my_bool_vec.push_back(true); // breakpoint 7
-  
+
   return 0;
 }

diff  --git a/lldb/tools/lldb-vscode/JSONUtils.cpp 
b/lldb/tools/lldb-vscode/JSONUtils.cpp
index c6b422e4d7a02e6..6cf753170d8429f 100644
--- a/lldb/tools/lldb-vscode/JSONUtils.cpp
+++ b/lldb/tools/lldb-vscode/JSONUtils.cpp
@@ -136,14 +136,14 @@ std::vector GetStrings(const 
llvm::json::Object *obj,
 /// first children, so that the user can get a glimpse of its contents at a
 /// glance.
 static std::optional
-GetSyntheticSummaryForContainer(lldb::SBValue &v) {
+TryCreateAutoSummaryForContainer(lldb::SBValue &v) {
   // We gate this feature because it performs GetNumChildren(), which can
   // cause performance issues because LLDB needs to complete possibly huge
   // types.
   if (!g_vsc.enable_auto_variable_summaries)
 return std::nullopt;
 
-  if (v.TypeIsPointerType() || !v.MightHaveChildren())
+  if (!v.MightHaveChildren())
 return std::nullopt;
   /// As this operation can be potentially slow, we limit the total time spent
   /// fetching children to a few ms.
@@ -194,28 +194,18 @@ GetSyntheticSummaryForContainer(lldb::SBValue &v) {
   return summary;
 }
 
-/// Return whether we should dereference an SBValue in order to generate a more
-/// meaningful summary string.
-static bool ShouldBeDereferencedForSummary(lldb::SBValue &v) {
+/// Try to create a summary string for the given value that doesn't have a
+/// summary of its own.
+static std::optional TryCreateAutoSummary(lldb::SBValue value) {
   if (!g_vsc.enable_auto_variable_summaries)
-return false;
-
-  if (!v.GetType().IsPointerType() && !v.GetType().IsReferenceType())
-return false;
-
-  // If we are referencing a pointer, we don't dereference to avoid confusing
-  // the user with the addresses that could shown in the summary.
-  if (v.Dereference().GetType().IsPointerType())
-return false;
-
-  // If it's synthetic or a pointer to a basic type that provides a summary, we
-  // don't dereference.
-  if ((v.IsSynthetic() || v.GetType().GetPointeeType().GetBasicType() !=
-  lldb::eBasicTypeInvalid) &&
-  !llvm::StringRef(v.GetSummary()).empty()) {
-return false;
-  }
-  return true;
+return std::nullopt;
+
+  // We use the dereferenced value for generating the summary.
+  if (value.

[Lldb-commits] [lldb] [lldb-vscode] Use auto summaries whenever variables don't have a summary (PR #66551)

[Walter Erquinigo via lldb-commits]

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

[Lldb-commits] [lldb] fdc265b - [lldb][AArch64] Invalidate cached VG value before reconfiguring SVE registers

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2023-09-20T16:05:34+01:00
New Revision: fdc265be26483be1e081ea3f1e11d78b8cc488af

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

LOG: [lldb][AArch64] Invalidate cached VG value before reconfiguring SVE 
registers

This fixes 46b961f36bc5b1105356d1701f0c7c9d439be9c8.

Prior to the SME changes the steps were:
* Invalidate all registers.
* Update value of VG and use that to reconfigure the registers.
* Invalidate all registers again.

With the changes for SME I removed the initial invalidate thinking
that it didn't make sense to do if we were going to invalidate them
all anyway after reconfiguring.

Well the reason it made sense was that it forced us to get the
latest value of vg which we needed to reconfigure properly.

Not doing so caused a test failure on our Graviton bot which has SVE
(https://lab.llvm.org/buildbot/#/builders/96/builds/45722). It was
flaky and looping it locally would always fail within a few minutes.
Presumably it was using an invalid value of vg, which caused some offsets
to be calculated incorrectly.

To fix this I've invalided vg in AArch64Reconfigure just before we read
it. This is the same as the fix I have in review for SME's svg register.

Pushing this directly to fix the ongoing test failure.

Added: 


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

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
index 16dde28f6ee5396..b127d3d6213a4aa 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -772,6 +772,8 @@ void GDBRemoteRegisterContext::AArch64Reconfigure() {
   std::optional vg_reg_value;
   const RegisterInfo *vg_reg_info = m_reg_info_sp->GetRegisterInfo("vg");
   if (vg_reg_info) {
+// Make sure we get the latest value of vg from the remote.
+SetRegisterIsValid(vg_reg_info, false);
 uint32_t vg_reg_num = vg_reg_info->kinds[eRegisterKindLLDB];
 uint64_t reg_value = ReadRegisterAsUnsigned(vg_reg_num, fail_value);
 if (reg_value != fail_value && reg_value <= 32)



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

[Lldb-commits] [lldb] [lldb][AArch64] Invalidate SVG prior to reconfiguring ZA regdef (PR #66768)

[David Spickett via lldb-commits]

DavidSpickett wrote:

I've just pushed a similar fix for SVE's VG 
(https://github.com/llvm/llvm-project/commit/fdc265be26483be1e081ea3f1e11d78b8cc488af).
 Fixes some test flakiness so I've pushed it directly.

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

[Lldb-commits] [lldb] [lldb][AArch64] Invalidate SVG prior to reconfiguring ZA regdef (PR #66768)

[David Spickett via lldb-commits]

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

>From 3d4834fd5ab994dd312b28b874e73f0807b117dc Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Tue, 22 Aug 2023 14:42:35 +0100
Subject: [PATCH] [lldb][AArch64] Invalidate SVG prior to reconfiguring ZA
 regdef

This fixes a bug where writing vg during streaming mode
could prevent you reading za directly afterwards.

vg is invalidated just prior to us reading it in AArch64Reconfigure,
but svg was not. This lead to some situations where vg would be
updated or read from fresh, but svg would not be.

This meant it had some undefined value which lead to errors
that prevented us reading ZA. Likely we receieved a lot more
data than we were expecting.

To fix this, invalidate svg before reconfiguring. This ensures
that the value used is the latest one from the remote and matches
the procedure for SVE's VG.

The bug may depend on timing, I could not find a consistent way
to trigger it. I originally found it when checking whether za
is disabled after a vg change, so I've added checks for that
to TestZAThreadedDynamic.

The SVE VG version of the bug did show up on the buildbot,
but not consistently. So it's possible that TestZAThreadedDynamic
does in fact cover this, but I haven't run it enough times to know.
---
 .../Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp  | 5 +
 .../za_dynamic_resize/TestZAThreadedDynamic.py   | 2 ++
 2 files changed, 7 insertions(+)

diff --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
index b127d3d6213a4aa..72280927471f883 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -783,6 +783,11 @@ void GDBRemoteRegisterContext::AArch64Reconfigure() {
   std::optional svg_reg_value;
   const RegisterInfo *svg_reg_info = m_reg_info_sp->GetRegisterInfo("svg");
   if (svg_reg_info) {
+// When vg is written it is automatically made invalid. Writing vg will 
also
+// change svg if we're in streaming mode but it will not be made invalid
+// so do this manually so the following read gets the latest svg value.
+SetRegisterIsValid(svg_reg_info, false);
+
 uint32_t svg_reg_num = svg_reg_info->kinds[eRegisterKindLLDB];
 uint64_t reg_value = ReadRegisterAsUnsigned(svg_reg_num, fail_value);
 if (reg_value != fail_value && reg_value <= 32)
diff --git 
a/lldb/test/API/commands/register/register/aarch64_za_register/za_dynamic_resize/TestZAThreadedDynamic.py
 
b/lldb/test/API/commands/register/register/aarch64_za_register/za_dynamic_resize/TestZAThreadedDynamic.py
index 65d1071c26b2a34..d2a26ce71bde1d8 100644
--- 
a/lldb/test/API/commands/register/register/aarch64_za_register/za_dynamic_resize/TestZAThreadedDynamic.py
+++ 
b/lldb/test/API/commands/register/register/aarch64_za_register/za_dynamic_resize/TestZAThreadedDynamic.py
@@ -125,11 +125,13 @@ def za_test_impl(self, enable_za):
 self.runCmd("thread select %d" % (idx + 1))
 self.check_za_register(4, 2)
 self.runCmd("register write vg 2")
+self.check_disabled_za_register(2)
 
 elif stopped_at_line_number == thY_break_line1:
 self.runCmd("thread select %d" % (idx + 1))
 self.check_za_register(2, 3)
 self.runCmd("register write vg 4")
+self.check_disabled_za_register(4)
 
 self.runCmd("thread continue 2")
 self.runCmd("thread continue 3")

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

[Lldb-commits] [lldb] [lldb][AArch64] Invalidate SVG prior to reconfiguring ZA regdef (PR #66768)

[David Spickett via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][DWARFASTParserClang] Resolve nested types when parsing structures (PR #66879)

[Michael Buch via lldb-commits]

@@ -462,3 +462,96 @@ TEST_F(DWARFASTParserClangTests, 
TestDefaultTemplateParamParsing) {
 }
   }
 }
+
+TEST_F(DWARFASTParserClangTests, EnsureNestedTypesOfTypeAreParsed) {
+  const char *yamldata = R"(
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_386
+DWARF:
+  debug_str:
+- Info
+- B
+- C
+- Mask
+- Enum
+  debug_abbrev:
+- Table:
+- Code:0x1
+  Tag: DW_TAG_compile_unit
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_language
+  Form:DW_FORM_data2
+- Code:0x2
+  Tag: DW_TAG_structure_type
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x3
+  Tag: DW_TAG_union_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x4
+  Tag: DW_TAG_structure_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x5
+  Tag: DW_TAG_enumeration_type
+  Children:DW_CHILDREN_yes

Michael137 wrote:

It might be worth just writing an API test instead. The yaml looks fine to me 
and we could use it to write a unit-test as a follow-up, but we'll have to jump 
through some hoops to get the unit-test down the code-path we want anyway. So 
an API test would be sufficient.

See reference example: 
https://github.com/llvm/llvm-project/blob/main/lldb/test/API/lang/cpp/bool/TestCPPBool.py

Put your test program into a `main.cpp` and call the relevant member types from 
the expression evaluator using `self.expect_expr()` in the python test file. 
E.g., for this change the test would like:
```
class NestedTypesTestCase(TestBase):
   
def test_with_run_command(self):
   
"""Test that referencing nested types work in the expression parser"""  
 
self.build()
   
lldbutil.run_to_source_breakpoint(  
   
self, "// breakpoint 1", lldb.SBFileSpec("main.cpp")
   
)   
   

   
self.expect_expr(   
   
"Info::Mask::Enum", 
result_type=..,
result_value=,  
)   
   
self.expect_expr("Info::B::val", result_type=..., result_value=...)
```

Let me know if you need more details on this.

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

[Lldb-commits] [lldb] [lldb][AArch64] Add release notes and documentation for SME (PR #66767)

[David Spickett via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][DWARFASTParserClang] Resolve nested types when parsing structures (PR #66879)

[Michael Buch via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][AArch64] Add release notes and documentation for SME (PR #66767)

[David Spickett via lldb-commits]

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

>From 705251d8ecbed546f46a5929a298ad88c70cc330 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Tue, 22 Aug 2023 11:12:23 +0100
Subject: [PATCH] [lldb][AArch64] Add release notes and documentation for SME

This adds a release note for all the SME support now in LLDB
and a page where I have documented the user experience (for want
of a better term) when using SVE and SME.

This includes things like which mode transitions can or cannot
be triggered from within LLDB. I hope this will serve to A: document
what I've implemented and B: be a user's guide to these extensions.

(though it is not a design document, read the commits and code
for that sort of detail)
---
 lldb/docs/index.rst |   1 +
 lldb/docs/use/aarch64-linux.rst | 190 
 llvm/docs/ReleaseNotes.rst  |   4 +
 3 files changed, 195 insertions(+)
 create mode 100644 lldb/docs/use/aarch64-linux.rst

diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 2eb57cefbd883ea..2fff25b27b974ea 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -125,6 +125,7 @@ interesting areas to contribute to lldb.
use/qemu-testing
use/intel_pt
use/ondemand
+   use/aarch64-linux
use/troubleshooting
use/links
Man Page 
diff --git a/lldb/docs/use/aarch64-linux.rst b/lldb/docs/use/aarch64-linux.rst
new file mode 100644
index 000..850a5e5a5837cda
--- /dev/null
+++ b/lldb/docs/use/aarch64-linux.rst
@@ -0,0 +1,190 @@
+Using LLDB On AArch64 Linux
+===
+
+This page explains the details of debugging certain AArch64 extensions using
+LLDB. If something is not mentioned here, it likely works as you would expect.
+
+This is not a replacement for ptrace and Linux Kernel documentation. This 
covers
+how LLDB has chosen to use those things and how that effects your experience as
+a user.
+
+Scalable Vector Extension (SVE)
+---
+
+See `here 
`__
+to learn about the extension and `here 
`__
+for the Linux Kernel's handling of it.
+
+In LLDB you will be able to see the following new registers:
+
+* ``z0-z31`` vector registers, each one has size equal to the vector length.
+* ``p0-p15`` predicate registers, each one containing 1 bit per byte in the 
vector
+  length. Making each one vector length / 8 sized.
+* ``ffr`` the first fault register, same size as a predicate register.
+* ``vg``, the vector length in "granules". Each granule is 8 bytes.
+
+.. code-block::
+
+   Scalable Vector Extension Registers:
+ vg = 0x0002
+ z0 = {0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 <...> }
+   <...>
+ p0 = {0xff 0xff}
+   <...>
+ffr = {0xff 0xff}
+
+The example above has a vector length of 16 bytes. Within LLDB you will always
+see "vg" as in the ``vg`` register, which is 2 in this case (8*2 = 16).
+Elsewhere you may see "vq" which is the vector length in quadwords (16 bytes)
+elsewhere. Where you see "vl", it is in bytes.
+
+Changing the Vector Length
+..
+
+While you can count the size of a P or Z register, it is intended that ``vg`` 
be
+used to find the current vector length.
+
+vg can be written. Writing the current vector length changes nothing. If you
+increase the vector length, the registers will likely be reset to 0. If you
+decrease it, LLDB will truncate the Z registers but everything else will be 
reset
+to 0.
+
+Generally you should not assume that SVE state after changing the vector length
+is in any way the same as it was previously. If you need to do it, do it before
+a function's first use of SVE.
+
+Z Register Presentation
+...
+
+LLDB makes no attempt to predict how an SVE Z register will be used. Even if 
the
+next SVE instruction (which may some distance away) would use, for example, 32
+bit elements, LLDB prints ``z0`` as single bytes.
+
+If you know what format you are going to use, give a format option::
+
+  (lldb) register read z0 -f uint32_t[]
+  z0 = {0x01010101 0x01010101 0x01010101 0x01010101}
+
+FPSIMD and SVE Modes
+
+
+Prior to the debugee's first use of SVE, it is in what the Linux Kernel terms
+SIMD mode. Only the FPU is being used. In this state LLDB will still show the
+SVE registers however the values are simply the FPU values zero extended up to
+the vector length.
+
+On first access to SVE, the process goes into SVE mode. Now the Z values are
+in the real Z registers.
+
+You can also trigger this with LLDB by writing to an SVE register. Note that
+there is no way to undo this change from within LLDB. However, the debugee
+itself could do something to end up back in SIMD mode.
+
+Expression evaluation
+.
+
+If you evaluate an expression,

[Lldb-commits] [lldb] [clang][CodeGen] The `eh_typeid_for` intrinsic needs special care too (PR #65699)

[Alex Voicu via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][DWARFASTParserClang] Resolve nested types when parsing structures (PR #66879)

[Vlad Serebrennikov via lldb-commits]

@@ -462,3 +462,96 @@ TEST_F(DWARFASTParserClangTests, 
TestDefaultTemplateParamParsing) {
 }
   }
 }
+
+TEST_F(DWARFASTParserClangTests, EnsureNestedTypesOfTypeAreParsed) {
+  const char *yamldata = R"(
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_386
+DWARF:
+  debug_str:
+- Info
+- B
+- C
+- Mask
+- Enum
+  debug_abbrev:
+- Table:
+- Code:0x1
+  Tag: DW_TAG_compile_unit
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_language
+  Form:DW_FORM_data2
+- Code:0x2
+  Tag: DW_TAG_structure_type
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x3
+  Tag: DW_TAG_union_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x4
+  Tag: DW_TAG_structure_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x5
+  Tag: DW_TAG_enumeration_type
+  Children:DW_CHILDREN_yes

Endilll wrote:

Thank you! I'll give it a try.

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

[Lldb-commits] [lldb] Fix a bug with cancelling "attach -w" after you have run a process previously (PR #65822)

[via lldb-commits]

jimingham wrote:

The way interruption works in lldb is that the first time you dispatch an 
interrupt, it just raises the "voluntary interrupt" flag.  Turns out the 
process attach part of lldb isn't written in a way that makes checking for the 
interrupt flag possible, so that doesn't work.  The second time you issue the 
interrupt, since we've already raised the Debugger interrupt flag, we send the 
Process level interrupt to any running processes.  That's the one that actually 
interrupts the attach attempt.

This is a variant of the scheme gdb used (at least back in the day), where the 
first ^C tries to interrupt the current command, and the second ^C tries to 
interrupt the process connection.  In gdb, on the second ^C you would get a 
prompt "I see you pressed ^C twice, did you really want to interrupt the 
process".  I didn't emulate that part as in my usage I pretty much never 
answered "no" to this question...

Jim


> On Sep 20, 2023, at 2:16 AM, David Spickett ***@***.***> wrote:
> 
> 
> @DavidSpickett commented on this pull request.
> 
> In lldb/test/API/commands/process/attach/TestProcessAttach.py 
> :
> 
> > +# No need to track the output
> +self.stdout_path = self.getBuildArtifact("stdout.txt")
> +self.out_filehandle = open(self.stdout_path, "w")
> +self.dbg.SetOutputFileHandle(self.out_filehandle, False)
> +self.dbg.SetErrorFileHandle(self.out_filehandle, False)
> +
> +n_errors, quit_req, crashed = self.dbg.RunCommandInterpreter(
> +True, True, options, 0, False, False)
> +
> +while 1:
> +time.sleep(1)
> +if target.process.state == lldb.eStateAttaching:
> +break
> +
> +self.dbg.DispatchInputInterrupt()
> +self.dbg.DispatchInputInterrupt()
> Why is this done twice?
> 
> —
> Reply to this email directly, view it on GitHub 
> ,
>  or unsubscribe 
> .
> You are receiving this because you modified the open/close state.
> 



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

[Lldb-commits] [lldb] Fix a bug with cancelling "attach -w" after you have run a process previously (PR #65822)

[via lldb-commits]

jimingham wrote:

The way the test works, we run one real process and let it exit.  Then we do 
"attach -w -n noone_would_use_this_name" because we don't want the second 
attach attempt to be able to succeed.  lldb should just stay stuck till the 
interrupt succeeds, there shouldn't be anything other way to get out of this.  
It sounds like something else is kicking us out of the attach wait loop on 
these systems?

Jim



> On Sep 20, 2023, at 2:56 AM, David Spickett ***@***.***> wrote:
> 
> 
> @DavidSpickett commented on this pull request.
> 
> In lldb/test/API/commands/process/attach/TestProcessAttach.py 
> :
> 
> > +time.sleep(1)
> +if target.process.state == lldb.eStateAttaching:
> +break
> +
> +self.dbg.DispatchInputInterrupt()
> +self.dbg.DispatchInputInterrupt()
> +
> +self.out_filehandle.flush()
> +reader = open(self.stdout_path, "r")
> +results = reader.readlines()
> +found_result = False
> +for line in results:
> +if "Cancelled async attach" in line:
> +found_result = True
> +break
> +self.assertTrue(found_result, "Found async error in results")
> This fails if results is empty.
> 
> 
> []
> 
> FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
> test_run_then_attach_wait_interrupt (TestProcessAttach.ProcessAttachTestCase)
>  0, executable = ProcessAttach>: success
> 
> Restore dir to: /home/david.spickett/build-llvm-aarch64
> ==
> FAIL: test_run_then_attach_wait_interrupt 
> (TestProcessAttach.ProcessAttachTestCase)
> --
> Traceback (most recent call last):
>   File 
> "/home/david.spickett/llvm-project/lldb/test/API/commands/process/attach/TestProcessAttach.py",
>  line 195, in test_run_then_attach_wait_interrupt
> self.assertTrue(found_result, "Found async error in results")
> AssertionError: False is not True : Found async error in results
> Config=aarch64-/home/david.spickett/build-llvm-aarch64/bin/clang
> --
> When the test works the results contain:
> 
> 
> ['error: attach failed: Cancelled async attach.\n', '\n', '... 
> Interrupted.\n']
> 
> Running it in a loop it took ~40 runs to get a failing one.
> 
> I wonder if that is because the attach happens to finish a lot faster 
> sometimes, so there's no time to cancel it? If that's down to the OS and 
> machine load, I'm not sure how we'd make this predictable.
> 
> The ugly option is to say if the results are empty, pass the test and assume 
> the other 39 runs will check for the bug.
> 
> —
> Reply to this email directly, view it on GitHub 
> ,
>  or unsubscribe 
> .
> You are receiving this because you modified the open/close state.
> 



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

[Lldb-commits] [lldb] df93c4f - Remove some raciness from the TestProcessAttach.test_run_then_attach_wait_interrupt

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2023-09-20T13:08:40-07:00
New Revision: df93c4ffdf220630ecceba5c9a7822c0aca7deaa

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

LOG: Remove some raciness from the 
TestProcessAttach.test_run_then_attach_wait_interrupt
command.

We were reading the command output right after sending the interrupt, but
sometimes that wasn't long enough for the command result text to have been 
emitted.
I added a poll for the state change to eStateExited, and then added a bit more 
sleep
to give the command a chance to complete.

Added: 


Modified: 
lldb/test/API/commands/process/attach/TestProcessAttach.py

Removed: 




diff  --git a/lldb/test/API/commands/process/attach/TestProcessAttach.py 
b/lldb/test/API/commands/process/attach/TestProcessAttach.py
index 0e916d2e8e4cbe1..1f5359977480be6 100644
--- a/lldb/test/API/commands/process/attach/TestProcessAttach.py
+++ b/lldb/test/API/commands/process/attach/TestProcessAttach.py
@@ -4,6 +4,8 @@
 
 
 import os
+import threading
+import time
 import lldb
 import shutil
 from lldbsuite.test.decorators import *
@@ -128,3 +130,84 @@ def tearDown(self):
 
 # Call super's tearDown().
 TestBase.tearDown(self)
+
+def test_run_then_attach_wait_interrupt(self):
+# Test that having run one process doesn't cause us to be unable
+# to interrupt a subsequent attach attempt.
+self.build()
+exe = self.getBuildArtifact(exe_name)
+
+target = lldbutil.run_to_breakpoint_make_target(self, exe_name, True)
+launch_info = target.GetLaunchInfo()
+launch_info.SetArguments(["q"], True)
+error = lldb.SBError()
+target.Launch(launch_info, error)
+self.assertSuccess(error, "Launched a process")
+self.assertState(target.process.state, lldb.eStateExited, "and it 
exited.") 
+
+# Okay now we've run a process, try to attach/wait to something
+# and make sure that we can interrupt that.
+
+options = lldb.SBCommandInterpreterRunOptions()
+options.SetPrintResults(True)
+options.SetEchoCommands(False)
+
+self.stdin_path = self.getBuildArtifact("stdin.txt")
+
+with open(self.stdin_path, "w") as input_handle:
+input_handle.write("process attach -w -n 
noone_would_use_this_name\nquit")
+
+# Python will close the file descriptor if all references
+# to the filehandle object lapse, so we need to keep one
+# around.
+self.filehandle = open(self.stdin_path, "r")
+self.dbg.SetInputFileHandle(self.filehandle, False)
+
+# No need to track the output
+self.stdout_path = self.getBuildArtifact("stdout.txt")
+self.out_filehandle = open(self.stdout_path, "w")
+self.dbg.SetOutputFileHandle(self.out_filehandle, False)
+self.dbg.SetErrorFileHandle(self.out_filehandle, False)
+
+n_errors, quit_req, crashed = self.dbg.RunCommandInterpreter(
+True, True, options, 0, False, False)
+
+while 1:
+time.sleep(1)
+if target.process.state == lldb.eStateAttaching:
+break
+
+self.dbg.DispatchInputInterrupt()
+self.dbg.DispatchInputInterrupt()
+
+# cycle waiting for the process state to change before trying
+# to read the command output.  I don't want to spin forever.
+counter = 0
+got_exit = False
+while counter < 20:
+if target.process.state == lldb.eStateExited:
+got_exit = True
+break
+counter += 1
+time.sleep(1)
+
+self.assertTrue(got_exit, "The process never switched to eStateExited")
+# Even if the state has flipped, we still need to wait for the
+# command to complete to see the result.  We don't have a way to
+# synchronize on "command completed" right now, but sleeping just
+# a bit should be enough, all that's left is passing this error
+# result to the command, and printing it to the debugger output.
+time.sleep(1)
+
+self.out_filehandle.flush()
+reader = open(self.stdout_path, "r")
+results = reader.readlines()
+found_result = False
+for line in results:
+if "Cancelled async attach" in line:
+found_result = True
+break
+if not found_result:
+print(f"Results: {results}")
+
+self.assertTrue(found_result, "Found async error in results")



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

[Lldb-commits] [lldb] [lldb] Fix stdcpp type summary mistakenly marked as regex (NFC) (PR #66949)

[Dave Lee via lldb-commits]

https://github.com/kastiglione created 
https://github.com/llvm/llvm-project/pull/66949

`std::basic_string` is not a regex, and treating it as such could 
unintentionally
cause a formatter to substring match a template type parameter, for example:
`std::vector>`.

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


>From b943b22bf585acfa65ec812f3af0d48865c9b8ac Mon Sep 17 00:00:00 2001
From: Dave Lee 
Date: Thu, 17 Aug 2023 16:09:15 -0700
Subject: [PATCH] [lldb] Fix stdcpp type summary mistakenly marked as regex
 (NFC)

`std::basic_string` is not a regex, and treating it as such could 
unintentionally
cause a formatter to substring match a template type parameter, for example:
`std::vector>`.

Differential Revision: https://reviews.llvm.org/D158663
---
 lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
index 3d709e3d6759556..c1743a5e0a418dd 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -1009,7 +1009,7 @@ static void 
LoadLibStdcppFormatters(lldb::TypeCategoryImplSP cpp_category_sp) {
   cpp_category_sp->AddTypeSummary("std::string", eFormatterMatchExact,
   std_string_summary_sp);
   cpp_category_sp->AddTypeSummary("std::basic_string",
-  eFormatterMatchRegex, std_string_summary_sp);
+  eFormatterMatchExact, std_string_summary_sp);
   cpp_category_sp->AddTypeSummary(
   "std::basic_string,std::allocator >",
   eFormatterMatchExact, std_string_summary_sp);

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

[Lldb-commits] [lldb] Fix a bug with cancelling "attach -w" after you have run a process previously (PR #65822)

[via lldb-commits]

jimingham wrote:

You are right, there is a racy bit here - I was also getting ~one fails per 50 
runs.  

The raciness is due to the time it takes between when we send the interrupt and 
when we finish up the command and produce the results.  So we can end up 
reading from the command output before the command has written its result.

I can make this more deterministic by waiting for the process state to shift to 
eStateExited.   But even with that it was still a little flakey because there's 
still some time between when the interrupt is noticed and causes us to switch 
the process state and when lldb makes the command return and prints that to 
stdout.

Unfortunately this is a test of command-line behavior, you don't get the same 
problem with the SB API's directly.  So I have to do it as a "run a 
command-line command" test, and that makes it harder to get direct signals 
about when to look at the result.

If we sent "command completed" events I could wait for that, then the test 
would be deterministic.  That seems like a feature we should design, not jam in 
to fix a test problem..  

However, if I just insert a time.sleep(1) between seeing the state flip to 
eStateExited and looking at the results, I can run this #200 and see no 
failures.  That's just the time to back out of the command execution stack and 
write the result to stdout, so that shouldn't be as variable.  If this still 
ends up failing intermittently, then I'll have to cook up some kind of "command 
completed" event that the test can wait on.

Jim
 


> On Sep 20, 2023, at 11:05 AM, Jim Ingham ***@***.***> wrote:
> 
> The way the test works, we run one real process and let it exit.  Then we do 
> "attach -w -n noone_would_use_this_name" because we don't want the second 
> attach attempt to be able to succeed.  lldb should just stay stuck till the 
> interrupt succeeds, there shouldn't be anything other way to get out of this. 
>  It sounds like something else is kicking us out of the attach wait loop on 
> these systems?
> 
> Jim
> 
> 
> 
>> On Sep 20, 2023, at 2:56 AM, David Spickett ***@***.***> wrote:
>> 
>> 
>> @DavidSpickett commented on this pull request.
>> 
>> In lldb/test/API/commands/process/attach/TestProcessAttach.py 
>> :
>> 
>> > +time.sleep(1)
>> +if target.process.state == lldb.eStateAttaching:
>> +break
>> +
>> +self.dbg.DispatchInputInterrupt()
>> +self.dbg.DispatchInputInterrupt()
>> +
>> +self.out_filehandle.flush()
>> +reader = open(self.stdout_path, "r")
>> +results = reader.readlines()
>> +found_result = False
>> +for line in results:
>> +if "Cancelled async attach" in line:
>> +found_result = True
>> +break
>> +self.assertTrue(found_result, "Found async error in results")
>> This fails if results is empty.
>> 
>> 
>> []
>> 
>> FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
>> test_run_then_attach_wait_interrupt (TestProcessAttach.ProcessAttachTestCase)
>> > = 0, executable = ProcessAttach>: success
>> 
>> Restore dir to: /home/david.spickett/build-llvm-aarch64
>> ==
>> FAIL: test_run_then_attach_wait_interrupt 
>> (TestProcessAttach.ProcessAttachTestCase)
>> --
>> Traceback (most recent call last):
>>   File 
>> "/home/david.spickett/llvm-project/lldb/test/API/commands/process/attach/TestProcessAttach.py",
>>  line 195, in test_run_then_attach_wait_interrupt
>> self.assertTrue(found_result, "Found async error in results")
>> AssertionError: False is not True : Found async error in results
>> Config=aarch64-/home/david.spickett/build-llvm-aarch64/bin/clang
>> --
>> When the test works the results contain:
>> 
>> 
>> ['error: attach failed: Cancelled async attach.\n', '\n', '... 
>> Interrupted.\n']
>> 
>> Running it in a loop it took ~40 runs to get a failing one.
>> 
>> I wonder if that is because the attach happens to finish a lot faster 
>> sometimes, so there's no time to cancel it? If that's down to the OS and 
>> machine load, I'm not sure how we'd make this predictable.
>> 
>> The ugly option is to say if the results are empty, pass the test and assume 
>> the other 39 runs will check for the bug.
>> 
>> —
>> Reply to this email directly, view it on GitHub 
>> ,
>>  or unsubscribe 
>> .
>> You are receiving this because you modified the open/close state.

[Lldb-commits] [lldb] [lldb] Fix stdcpp type summary mistakenly marked as regex (NFC) (PR #66949)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb


Changes

`std::basic_string` is not a regex, and treating it as such could 
unintentionally
cause a formatter to substring match a template type parameter, for example:
`std::vector>`.

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


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


1 Files Affected:

- (modified) lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp 
(+1-1) 


``diff
diff --git a/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
index 3d709e3d6759556..c1743a5e0a418dd 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -1009,7 +1009,7 @@ static void 
LoadLibStdcppFormatters(lldb::TypeCategoryImplSP cpp_category_sp) {
   cpp_category_sp->AddTypeSummary("std::string", eFormatterMatchExact,
   std_string_summary_sp);
   cpp_category_sp->AddTypeSummary("std::basic_string",
-  eFormatterMatchRegex, std_string_summary_sp);
+  eFormatterMatchExact, std_string_summary_sp);
   cpp_category_sp->AddTypeSummary(
   "std::basic_string,std::allocator >",
   eFormatterMatchExact, std_string_summary_sp);

``




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

[Lldb-commits] [lldb] [lldb] Fix stdcpp type summary mistakenly marked as regex (NFC) (PR #66949)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo approved this pull request.

Good catch! I think I have suffered because of this at some point.

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

[Lldb-commits] [lldb] Fix a bug with cancelling "attach -w" after you have run a process previously (PR #65822)

[via lldb-commits]

jimingham wrote:

Interesting...  I split the end stage of the test up into:

(a) wait for up to 20 seconds the state to switch to eStateExited
(b) wait another second, then check the command output file

On macOS, as I said, that seemed to make the test quite robust, but when I 
checked the test in I got a bot failure at stage (a).  That really sounds like 
the underlying feature of interrupting a process in this state doesn't work 
reliably on those systems.  The patch this is testing just changed a bug in 
generic code that prevented us from TRYING to do this interrupt, but didn't 
change any of the underlying process interrupt machinery.  So it looks like the 
test is uncovering underlying flakiness.

I changed the test to be macOS only for now.  We should go back and make the 
feature work reliably on the other platforms when we get a change.

Jim


> On Sep 20, 2023, at 1:14 PM, Jim Ingham ***@***.***> wrote:
> 
> You are right, there is a racy bit here - I was also getting ~one fails per 
> 50 runs.  
> 
> The raciness is due to the time it takes between when we send the interrupt 
> and when we finish up the command and produce the results.  So we can end up 
> reading from the command output before the command has written its result.
> 
> I can make this more deterministic by waiting for the process state to shift 
> to eStateExited.   But even with that it was still a little flakey because 
> there's still some time between when the interrupt is noticed and causes us 
> to switch the process state and when lldb makes the command return and prints 
> that to stdout.
> 
> Unfortunately this is a test of command-line behavior, you don't get the same 
> problem with the SB API's directly.  So I have to do it as a "run a 
> command-line command" test, and that makes it harder to get direct signals 
> about when to look at the result.
> 
> If we sent "command completed" events I could wait for that, then the test 
> would be deterministic.  That seems like a feature we should design, not jam 
> in to fix a test problem..  
> 
> However, if I just insert a time.sleep(1) between seeing the state flip to 
> eStateExited and looking at the results, I can run this #200 and see no 
> failures.  That's just the time to back out of the command execution stack 
> and write the result to stdout, so that shouldn't be as variable.  If this 
> still ends up failing intermittently, then I'll have to cook up some kind of 
> "command completed" event that the test can wait on.
> 
> Jim
>  
> 
> 
>> On Sep 20, 2023, at 11:05 AM, Jim Ingham ***@***.***> wrote:
>> 
>> The way the test works, we run one real process and let it exit.  Then we do 
>> "attach -w -n noone_would_use_this_name" because we don't want the second 
>> attach attempt to be able to succeed.  lldb should just stay stuck till the 
>> interrupt succeeds, there shouldn't be anything other way to get out of 
>> this.  It sounds like something else is kicking us out of the attach wait 
>> loop on these systems?
>> 
>> Jim
>> 
>> 
>> 
>>> On Sep 20, 2023, at 2:56 AM, David Spickett ***@***.***> wrote:
>>> 
>>> 
>>> @DavidSpickett commented on this pull request.
>>> 
>>> In lldb/test/API/commands/process/attach/TestProcessAttach.py 
>>> :
>>> 
>>> > +time.sleep(1)
>>> +if target.process.state == lldb.eStateAttaching:
>>> +break
>>> +
>>> +self.dbg.DispatchInputInterrupt()
>>> +self.dbg.DispatchInputInterrupt()
>>> +
>>> +self.out_filehandle.flush()
>>> +reader = open(self.stdout_path, "r")
>>> +results = reader.readlines()
>>> +found_result = False
>>> +for line in results:
>>> +if "Cancelled async attach" in line:
>>> +found_result = True
>>> +break
>>> +self.assertTrue(found_result, "Found async error in results")
>>> This fails if results is empty.
>>> 
>>> 
>>> []
>>> 
>>> FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
>>> test_run_then_attach_wait_interrupt 
>>> (TestProcessAttach.ProcessAttachTestCase)
>>> >> = 0, executable = ProcessAttach>: success
>>> 
>>> Restore dir to: /home/david.spickett/build-llvm-aarch64
>>> ==
>>> FAIL: test_run_then_attach_wait_interrupt 
>>> (TestProcessAttach.ProcessAttachTestCase)
>>> --
>>> Traceback (most recent call last):
>>>   File 
>>> "/home/david.spickett/llvm-project/lldb/test/API/commands/process/attach/TestProcessAttach.py",
>>>  line 195, in test_run_then_attach_wait_interrupt
>>> self.assertTrue(found_result, "Found async error in results")
>>> AssertionError: False is not True : Found async error in results
>>> Config=aarch64-/home/david.spickett/build-llvm-aarch

[Lldb-commits] [lldb] Fix a bug with cancelling "attach -w" after you have run a process previously (PR #65822)

[via lldb-commits]

jimingham wrote:



> On Sep 20, 2023, at 1:39 PM, Jim Ingham ***@***.***> wrote:
> 
> Interesting...  I split the end stage of the test up into:
> 
> (a) wait for up to 20 seconds the state to switch to eStateExited
> (b) wait another second, then check the command output file
> 
> On macOS, as I said, that seemed to make the test quite robust, but when I 
> checked the test in I got a bot failure at stage (a).

That is, a Linux bot failure...

Jim


>  That really sounds like the underlying feature of interrupting a process in 
> this state doesn't work reliably on those systems.  The patch this is testing 
> just changed a bug in generic code that prevented us from TRYING to do this 
> interrupt, but didn't change any of the underlying process interrupt 
> machinery.  So it looks like the test is uncovering underlying flakiness.
> 
> I changed the test to be macOS only for now.  We should go back and make the 
> feature work reliably on the other platforms when we get a change.
> 
> Jim
> 
> 
>> On Sep 20, 2023, at 1:14 PM, Jim Ingham ***@***.***> wrote:
>> 
>> You are right, there is a racy bit here - I was also getting ~one fails per 
>> 50 runs.  
>> 
>> The raciness is due to the time it takes between when we send the interrupt 
>> and when we finish up the command and produce the results.  So we can end up 
>> reading from the command output before the command has written its result.
>> 
>> I can make this more deterministic by waiting for the process state to shift 
>> to eStateExited.   But even with that it was still a little flakey because 
>> there's still some time between when the interrupt is noticed and causes us 
>> to switch the process state and when lldb makes the command return and 
>> prints that to stdout.
>> 
>> Unfortunately this is a test of command-line behavior, you don't get the 
>> same problem with the SB API's directly.  So I have to do it as a "run a 
>> command-line command" test, and that makes it harder to get direct signals 
>> about when to look at the result.
>> 
>> If we sent "command completed" events I could wait for that, then the test 
>> would be deterministic.  That seems like a feature we should design, not jam 
>> in to fix a test problem..  
>> 
>> However, if I just insert a time.sleep(1) between seeing the state flip to 
>> eStateExited and looking at the results, I can run this #200 and see no 
>> failures.  That's just the time to back out of the command execution stack 
>> and write the result to stdout, so that shouldn't be as variable.  If this 
>> still ends up failing intermittently, then I'll have to cook up some kind of 
>> "command completed" event that the test can wait on.
>> 
>> Jim
>>  
>> 
>> 
>>> On Sep 20, 2023, at 11:05 AM, Jim Ingham ***@***.***> wrote:
>>> 
>>> The way the test works, we run one real process and let it exit.  Then we 
>>> do "attach -w -n noone_would_use_this_name" because we don't want the 
>>> second attach attempt to be able to succeed.  lldb should just stay stuck 
>>> till the interrupt succeeds, there shouldn't be anything other way to get 
>>> out of this.  It sounds like something else is kicking us out of the attach 
>>> wait loop on these systems?
>>> 
>>> Jim
>>> 
>>> 
>>> 
 On Sep 20, 2023, at 2:56 AM, David Spickett ***@***.***> wrote:
 
 
 @DavidSpickett commented on this pull request.
 
 In lldb/test/API/commands/process/attach/TestProcessAttach.py 
 :
 
 > +time.sleep(1)
 +if target.process.state == lldb.eStateAttaching:
 +break
 +
 +self.dbg.DispatchInputInterrupt()
 +self.dbg.DispatchInputInterrupt()
 +
 +self.out_filehandle.flush()
 +reader = open(self.stdout_path, "r")
 +results = reader.readlines()
 +found_result = False
 +for line in results:
 +if "Cancelled async attach" in line:
 +found_result = True
 +break
 +self.assertTrue(found_result, "Found async error in results")
 This fails if results is empty.
 
 
 []
 
 FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
 test_run_then_attach_wait_interrupt 
 (TestProcessAttach.ProcessAttachTestCase)
 >>> threads = 0, executable = ProcessAttach>: success
 
 Restore dir to: /home/david.spickett/build-llvm-aarch64
 ==
 FAIL: test_run_then_attach_wait_interrupt 
 (TestProcessAttach.ProcessAttachTestCase)
 --
 Traceback (most recent call last):
   File 
 "/home/david.spickett/llvm-project/lldb/test/API/commands/process/attach/TestProcessAttach.py",
  

[Lldb-commits] [lldb] 933ad5c - [lldb] Add 'modify' type watchpoints, make it default (#66308)

[Jason Molenda via lldb-commits]

Author: Jason Molenda
Date: 2023-09-20T13:42:16-07:00
New Revision: 933ad5c897ee366759a54869b35b2d7285a92137

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

LOG: [lldb] Add 'modify' type watchpoints, make it default (#66308)

Watchpoints in lldb can be either 'read', 'write', or 'read/write'. This
is exposing the actual behavior of hardware watchpoints. gdb has a
different behavior: a "write" type watchpoint only stops when the
watched memory region *changes*.

A user is using a watchpoint for one of three reasons:

1. Want to find what is changing/corrupting this memory.
2. Want to find what is writing to this memory.
3. Want to find what is reading from this memory.

I believe (1) is the most common use case for watchpoints, and it
currently can't be done in lldb -- the user needs to continue every time
the same value is written to the watched-memory manually. I think gdb's
behavior is the correct one. There are some use cases where a developer
wants to find every function that writes/reads to/from a memory region,
regardless of value, I want to still allow that functionality.

This is also a bit of groundwork for my large watchpoint support
proposal
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
where I will be adding support for AArch64 MASK watchpoints which watch
power-of-2 memory regions. A user might ask to watch 24 bytes, and a
MASK watchpoint stub can do this with a 32-byte MASK watchpoint if it is
properly aligned. And we need to ignore writes to the final 8 bytes of
that watched region, and not show those hits to the user.

This patch adds a new 'modify' watchpoint type and it is the default.

Re-landing this patch after addressing testsuite failures found in CI on
Linux, Intel machines, and windows.

rdar://108234227

Added: 
lldb/bindings/interface/SBWatchpointOptionsDocstrings.i
lldb/include/lldb/API/SBWatchpointOptions.h
lldb/source/API/SBWatchpointOptions.cpp
lldb/test/API/functionalities/watchpoint/modify-watchpoints/Makefile

lldb/test/API/functionalities/watchpoint/modify-watchpoints/TestModifyWatchpoint.py
lldb/test/API/functionalities/watchpoint/modify-watchpoints/main.c

Modified: 
lldb/bindings/headers.swig
lldb/bindings/interfaces.swig
lldb/include/lldb/API/SBTarget.h
lldb/include/lldb/Breakpoint/Watchpoint.h
lldb/include/lldb/Interpreter/OptionGroupWatchpoint.h
lldb/include/lldb/lldb-defines.h
lldb/include/lldb/lldb-enumerations.h
lldb/include/lldb/lldb-forward.h
lldb/source/API/CMakeLists.txt
lldb/source/API/SBTarget.cpp
lldb/source/API/SBValue.cpp
lldb/source/API/SBWatchpoint.cpp
lldb/source/Breakpoint/Watchpoint.cpp
lldb/source/Commands/CommandObjectWatchpoint.cpp
lldb/source/Interpreter/OptionGroupWatchpoint.cpp
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/source/Target/StopInfo.cpp
lldb/source/Target/Target.cpp
lldb/test/API/commands/watchpoints/multiple_hits/main.cpp
lldb/test/API/commands/watchpoints/step_over_watchpoint/main.c
lldb/test/API/commands/watchpoints/unaligned-watchpoint/main.c

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

lldb/test/API/functionalities/watchpoint/large-watchpoint/TestLargeWatchpoint.py

lldb/test/API/functionalities/watchpoint/unaligned-spanning-two-dwords/TestUnalignedSpanningDwords.py
lldb/test/API/python_api/default-constructor/sb_target.py
lldb/test/API/python_api/watchpoint/watchlocation/TestTargetWatchAddress.py

Removed: 




diff  --git a/lldb/bindings/headers.swig b/lldb/bindings/headers.swig
index f7871765624dd31..d392ed43d8c0c9e 100644
--- a/lldb/bindings/headers.swig
+++ b/lldb/bindings/headers.swig
@@ -77,4 +77,5 @@
 #include "lldb/API/SBValueList.h"
 #include "lldb/API/SBVariablesOptions.h"
 #include "lldb/API/SBWatchpoint.h"
+#include "lldb/API/SBWatchpointOptions.h"
 %}

diff  --git a/lldb/bindings/interface/SBWatchpointOptionsDocstrings.i 
b/lldb/bindings/interface/SBWatchpointOptionsDocstrings.i
new file mode 100644
index 000..370bf95401dcb5e
--- /dev/null
+++ b/lldb/bindings/interface/SBWatchpointOptionsDocstrings.i
@@ -0,0 +1,12 @@
+%feature("docstring",
+"A container for options to use when creating watchpoints."
+) lldb::SBWatchpointOptions;
+
+%feature("docstring", "Sets whether the watchpoint should stop on read 
accesses."
+) lldb::SBWatchpointOptions::SetWatchpointTypeRead;
+%feature("docstring", "Gets whether the watchpoint should stop on read 
accesses."
+) lldb::SBWatchpointOptions::GetWatchpointTypeRead;
+%feature("docstring", "Sets whether the watchpoint should stop on write 
accesses. eWatchpointWriteTypeOnModify is the most commonly useful mode, where 
lldb will stop when th

[Lldb-commits] [lldb] [lldb] Fix stdcpp type summary mistakenly marked as regex (NFC) (PR #66949)

[via lldb-commits]

jimingham wrote:

In this case, it's clearly not a regex, so this change is fine.  But ALSO, any 
regex matches against std types should be `^std::whatever` and not just 
`std::whatever` to avoid this sort of unintended matching.

Jim


> On Sep 20, 2023, at 1:37 PM, Walter Erquinigo ***@***.***> wrote:
> 
> 
> @walter-erquinigo approved this pull request.
> 
> Good catch! I think I have suffered because of this at some point.
> 
> —
> Reply to this email directly, view it on GitHub 
> ,
>  or unsubscribe 
> .
> You are receiving this because your review was requested.
> 



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

[Lldb-commits] [lldb] [lldb] Fix stdcpp type summary mistakenly marked as regex (NFC) (PR #66949)

[Dave Lee via lldb-commits]

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

[Lldb-commits] [lldb] 56b148a - [lldb] Fix stdcpp type summary mistakenly marked as regex (NFC) (#66949)

[via lldb-commits]

Author: Dave Lee
Date: 2023-09-20T14:24:04-07:00
New Revision: 56b148aa8d6fcc61f0619d74cf5edca4d842

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

LOG: [lldb] Fix stdcpp type summary mistakenly marked as regex (NFC) (#66949)

`std::basic_string` is not a regex, and treating it as such could
unintentionally
cause a formatter to substring match a template type parameter, for
example:
`std::vector>`.

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

Added: 


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

Removed: 




diff  --git a/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
index 3d709e3d6759556..c1743a5e0a418dd 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -1009,7 +1009,7 @@ static void 
LoadLibStdcppFormatters(lldb::TypeCategoryImplSP cpp_category_sp) {
   cpp_category_sp->AddTypeSummary("std::string", eFormatterMatchExact,
   std_string_summary_sp);
   cpp_category_sp->AddTypeSummary("std::basic_string",
-  eFormatterMatchRegex, std_string_summary_sp);
+  eFormatterMatchExact, std_string_summary_sp);
   cpp_category_sp->AddTypeSummary(
   "std::basic_string,std::allocator >",
   eFormatterMatchExact, std_string_summary_sp);



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

[Lldb-commits] [PATCH] D158663: [lldb] Fix stdcpp type summary mistakenly marked as regex (NFC)

[Phabricator via lldb-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rG56b148aa8d6f: [lldb] Fix stdcpp type summary mistakenly 
marked as regex (NFC) (#66949) (authored by kastiglione, committed by GitHub 
).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158663

Files:
  lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp


Index: lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -1009,7 +1009,7 @@
   cpp_category_sp->AddTypeSummary("std::string", eFormatterMatchExact,
   std_string_summary_sp);
   cpp_category_sp->AddTypeSummary("std::basic_string",
-  eFormatterMatchRegex, std_string_summary_sp);
+  eFormatterMatchExact, std_string_summary_sp);
   cpp_category_sp->AddTypeSummary(
   "std::basic_string,std::allocator >",
   eFormatterMatchExact, std_string_summary_sp);


Index: lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -1009,7 +1009,7 @@
   cpp_category_sp->AddTypeSummary("std::string", eFormatterMatchExact,
   std_string_summary_sp);
   cpp_category_sp->AddTypeSummary("std::basic_string",
-  eFormatterMatchRegex, std_string_summary_sp);
+  eFormatterMatchExact, std_string_summary_sp);
   cpp_category_sp->AddTypeSummary(
   "std::basic_string,std::allocator >",
   eFormatterMatchExact, std_string_summary_sp);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D158663: [lldb] Fix stdcpp type summary mistakenly marked as regex (NFC)

[Dave Lee via Phabricator via lldb-commits]

kastiglione added a comment.

Merged in https://github.com/llvm/llvm-project/pull/66949


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158663

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

[Lldb-commits] [lldb] 7f34674 - Revert "Remove some raciness from the TestProcessAttach.test_run_then_attach_wait_interrupt"

[Daniel Thornburgh via lldb-commits]

Author: Daniel Thornburgh
Date: 2023-09-20T14:30:24-07:00
New Revision: 7f3467412ed52d6749b7c53f7934c4374c6d2a00

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

LOG: Revert "Remove some raciness from the 
TestProcessAttach.test_run_then_attach_wait_interrupt"

This reverts commit df93c4ffdf220630ecceba5c9a7822c0aca7deaa.
This change is breaking the LLDB CI builders, e.g.
https://lab.llvm.org/buildbot/#/builders/68/builds/60350

Added: 


Modified: 
lldb/test/API/commands/process/attach/TestProcessAttach.py

Removed: 




diff  --git a/lldb/test/API/commands/process/attach/TestProcessAttach.py 
b/lldb/test/API/commands/process/attach/TestProcessAttach.py
index 1f5359977480be6..0e916d2e8e4cbe1 100644
--- a/lldb/test/API/commands/process/attach/TestProcessAttach.py
+++ b/lldb/test/API/commands/process/attach/TestProcessAttach.py
@@ -4,8 +4,6 @@
 
 
 import os
-import threading
-import time
 import lldb
 import shutil
 from lldbsuite.test.decorators import *
@@ -130,84 +128,3 @@ def tearDown(self):
 
 # Call super's tearDown().
 TestBase.tearDown(self)
-
-def test_run_then_attach_wait_interrupt(self):
-# Test that having run one process doesn't cause us to be unable
-# to interrupt a subsequent attach attempt.
-self.build()
-exe = self.getBuildArtifact(exe_name)
-
-target = lldbutil.run_to_breakpoint_make_target(self, exe_name, True)
-launch_info = target.GetLaunchInfo()
-launch_info.SetArguments(["q"], True)
-error = lldb.SBError()
-target.Launch(launch_info, error)
-self.assertSuccess(error, "Launched a process")
-self.assertState(target.process.state, lldb.eStateExited, "and it 
exited.") 
-
-# Okay now we've run a process, try to attach/wait to something
-# and make sure that we can interrupt that.
-
-options = lldb.SBCommandInterpreterRunOptions()
-options.SetPrintResults(True)
-options.SetEchoCommands(False)
-
-self.stdin_path = self.getBuildArtifact("stdin.txt")
-
-with open(self.stdin_path, "w") as input_handle:
-input_handle.write("process attach -w -n 
noone_would_use_this_name\nquit")
-
-# Python will close the file descriptor if all references
-# to the filehandle object lapse, so we need to keep one
-# around.
-self.filehandle = open(self.stdin_path, "r")
-self.dbg.SetInputFileHandle(self.filehandle, False)
-
-# No need to track the output
-self.stdout_path = self.getBuildArtifact("stdout.txt")
-self.out_filehandle = open(self.stdout_path, "w")
-self.dbg.SetOutputFileHandle(self.out_filehandle, False)
-self.dbg.SetErrorFileHandle(self.out_filehandle, False)
-
-n_errors, quit_req, crashed = self.dbg.RunCommandInterpreter(
-True, True, options, 0, False, False)
-
-while 1:
-time.sleep(1)
-if target.process.state == lldb.eStateAttaching:
-break
-
-self.dbg.DispatchInputInterrupt()
-self.dbg.DispatchInputInterrupt()
-
-# cycle waiting for the process state to change before trying
-# to read the command output.  I don't want to spin forever.
-counter = 0
-got_exit = False
-while counter < 20:
-if target.process.state == lldb.eStateExited:
-got_exit = True
-break
-counter += 1
-time.sleep(1)
-
-self.assertTrue(got_exit, "The process never switched to eStateExited")
-# Even if the state has flipped, we still need to wait for the
-# command to complete to see the result.  We don't have a way to
-# synchronize on "command completed" right now, but sleeping just
-# a bit should be enough, all that's left is passing this error
-# result to the command, and printing it to the debugger output.
-time.sleep(1)
-
-self.out_filehandle.flush()
-reader = open(self.stdout_path, "r")
-results = reader.readlines()
-found_result = False
-for line in results:
-if "Cancelled async attach" in line:
-found_result = True
-break
-if not found_result:
-print(f"Results: {results}")
-
-self.assertTrue(found_result, "Found async error in results")



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

[Lldb-commits] [lldb] [lldb-vscode] Display a more descriptive summary for containers and pointers (PR #65514)

[David Blaikie via lldb-commits]

@@ -132,6 +132,84 @@ std::vector GetStrings(const 
llvm::json::Object *obj,
   return strs;
 }
 
+/// Create a short summary for a container that contains the summary of its
+/// first children, so that the user can get a glimpse of its contents at a
+/// glance.
+static std::optional
+GetSyntheticSummaryForContainer(lldb::SBValue &v) {
+  if (v.TypeIsPointerType() || !v.MightHaveChildren())
+return std::nullopt;
+  /// As this operation can be potentially slow, we limit the total time spent
+  /// fetching children to a few ms.
+  const auto max_evaluation_time = std::chrono::milliseconds(10);
+  /// We don't want to generate a extremely long summary string, so we limit 
its
+  /// length.
+  const size_t max_length = 32;
+
+  auto start = std::chrono::steady_clock::now();
+  std::string summary;
+  llvm::raw_string_ostream os(summary);
+  os << "{";
+
+  llvm::StringRef separator = "";
+
+  for (size_t i = 0, e = v.GetNumChildren(); i < e; ++i) {

dwblaikie wrote:

What do other debuggers do? (like Visual Studio itself)

& not sure that `GetNumChildren` should cause indefinite recursive expansion - 
could limit this feature to just going one level deep, for instance. But 
certainly worth comparing to other debuggers to see what sort of 
heuristics/rules/guidelines are good in terms of the amount of data expanded by 
default V unexpanded.

(& yeah, if everything's expanded all the way down, that's probably not good)

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

[Lldb-commits] [lldb] Add `target modules dump separate-debug-info` (PR #66035)

[David Blaikie via lldb-commits]

dwblaikie wrote:

(aside: isn't the SBAPI meant to be the thing to use if you want to script 
stuff, rather than having formatted output/scraping that? - but sounds like the 
output has converged on a table rather than JSON anyway? So maybe a moot point)

Re: errors, OSO (what does that stand for anyway) - yeah, maybe separate tables 
for different data? (one table for OSO, one for DWO, one for errors? (or two 
for errors, one for OSO errors and one for DWO errors?))

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

[Lldb-commits] [lldb] Add `target modules dump separate-debug-info` (PR #66035)

[via lldb-commits]

jimingham wrote:

N_SO is the stab moniker for a source file, and N_OSO is the object file 
associated with that source file (N_SO was in Sun's implementation, we made up 
N_OSO).  Most nm''s leave off the N_ when they print stabs, so then this became 
just OSO...

We don't do DWO on Darwin, and nobody but Darwin does OSO's, so for now I don't 
think you need to worry about mixing of the entities in these reports.

Jim

> On Sep 20, 2023, at 3:10 PM, David Blaikie ***@***.***> wrote:
> 
> 
> (aside: isn't the SBAPI meant to be the thing to use if you want to script 
> stuff, rather than having formatted output/scraping that? - but sounds like 
> the output has converged on a table rather than JSON anyway? So maybe a moot 
> point)
> 
> Re: errors, OSO (what does that stand for anyway) - yeah, maybe separate 
> tables for different data? (one table for OSO, one for DWO, one for errors? 
> (or two for errors, one for OSO errors and one for DWO errors?))
> 
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because you were mentioned.
> 



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

[Lldb-commits] [lldb] [libc++] Implement ranges::contains (PR #65148)

[via lldb-commits]

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/65148

>From 02e9afd761228f401df4d9f8dfaaca44ffae0c6e Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Thu, 31 Aug 2023 20:08:32 +
Subject: [PATCH 01/11] [libc++] Implement ranges::contains

Differential Revision: https://reviews.llvm.org/D159232
---
 libcxx/include/CMakeLists.txt |   1 +
 libcxx/include/__algorithm/ranges_contains.h  |  60 ++
 libcxx/include/algorithm  |   9 +
 ...obust_against_copying_projections.pass.cpp |   4 +
 .../alg.contains/ranges.contains.pass.cpp | 190 ++
 .../niebloid.compile.pass.cpp |   1 +
 6 files changed, 265 insertions(+)
 create mode 100644 libcxx/include/__algorithm/ranges_contains.h
 create mode 100644 
libcxx/test/std/algorithms/alg.nonmodifying/alg.contains/ranges.contains.pass.cpp

diff --git a/libcxx/include/CMakeLists.txt b/libcxx/include/CMakeLists.txt
index 77a7269121ec142..024aa8959fb7200 100644
--- a/libcxx/include/CMakeLists.txt
+++ b/libcxx/include/CMakeLists.txt
@@ -104,6 +104,7 @@ set(files
   __algorithm/ranges_any_of.h
   __algorithm/ranges_binary_search.h
   __algorithm/ranges_clamp.h
+  __algorithm/ranges_contains.h
   __algorithm/ranges_copy.h
   __algorithm/ranges_copy_backward.h
   __algorithm/ranges_copy_if.h
diff --git a/libcxx/include/__algorithm/ranges_contains.h 
b/libcxx/include/__algorithm/ranges_contains.h
new file mode 100644
index 000..647b7ea34be3421
--- /dev/null
+++ b/libcxx/include/__algorithm/ranges_contains.h
@@ -0,0 +1,60 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+#define _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+
+#include <__algorithm/in_in_result.h>
+#include <__algorithm/ranges_find.h>
+#include <__config>
+#include <__functional/identity.h>
+#include <__functional/ranges_operations.h>
+#include <__functional/reference_wrapper.h>
+#include <__iterator/concepts.h>
+#include <__iterator/indirectly_comparable.h>
+#include <__iterator/projected.h>
+#include <__ranges/access.h>
+#include <__ranges/concepts.h>
+#include <__utility/move.h>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_STD_VER >= 23
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+namespace ranges {
+namespace __contains {
+struct __fn {
+  template  _Sent, class _Type, 
class _Proj = identity>
+requires indirect_binary_predicate, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Iter __first, _Sent __last, const _Type& __value, _Proj __proj = 
{}) const {
+return ranges::find(std::move(__first), std::move(__last), __value, 
std::ref(__proj)) != __last;
+  }
+
+  template 
+requires indirect_binary_predicate, _Proj>, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Range&& __range, const _Type& __value, _Proj __proj = {}) const {
+return ranges::find(ranges::begin(__range), ranges::end(__range), __value, 
std::ref(__proj)) != ranges::end(__range);
+  }
+};
+} // namespace __contains
+inline namespace __cpo {
+inline constexpr auto contains = __contains::__fn{};
+} // namespace __cpo
+} // namespace ranges
+
+_LIBCPP_END_NAMESPACE_STD
+
+#endif // _LIBCPP_STD_VER >= 23
+
+#endif // _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
diff --git a/libcxx/include/algorithm b/libcxx/include/algorithm
index 76e0d22bf73ef85..003bf132b38b4d8 100644
--- a/libcxx/include/algorithm
+++ b/libcxx/include/algorithm
@@ -226,6 +226,14 @@ namespace ranges {
   template
 using copy_backward_result = in_out_result;
 // since C++20
 
+  template S, class T, class Proj = identity>
+requires indirect_binary_predicate, 
const T*>
+constexpr bool ranges::contains(I first, S last, const T& value, Proj proj 
= {});   // since C++23
+
+  template
+requires indirect_binary_predicate, Proj>, const T*>
+constexpr bool ranges::contains(R&& r, const T& value, Proj proj = {});
 // since C++23
+
   template S, weakly_incrementable O>
 requires indirectly_copyable
 constexpr ranges::copy_result ranges::copy(I first, S last, O 
result);// since C++20
@@ -1827,6 +1835,7 @@ template 
 #include <__algorithm/ranges_any_of.h>
 #include <__algorithm/ranges_binary_search.h>
 #include <__algorithm/ranges_clamp.h>
+#include <__algorithm/ranges_contains.h>
 #include <__algorithm/ranges_copy.h>
 #include <__algorithm/ranges_copy_backward.h>
 #include <__algorithm/ranges_copy_if.h>
diff --git 
a/libcxx/test/libcxx/algorithms/ranges_robust_against_c

[Lldb-commits] [PATCH] D157609: [lldb] Add more ways to find split DWARF files

[David Blaikie via Phabricator via lldb-commits]

dblaikie added a comment.

In D157609#4645298 , @clayborg wrote:

> In D157609#4644194 , @DavidSpickett 
> wrote:
>
>>> Any chance we could simplify this situation and have dwo searches use 
>>> exactly the same/shared logic as source file searches?
>>
>> I'm not sure what exactly this means, can you clarify?
>>
>> I know that DWP and DWO have different search functions, that could 
>> certainly be unified. Not sure how source files work.
>
> Source file search paths and debug info search paths are different in LLDB. 
> GDB had one setting IIRC that handled both. These settings have been in LLDB 
> for a while so I wouldn't recommend changing this up at this point.

I don't think that's a great motivation to diverge them further.

We could make the DWO search fallback to the source search - and add new 
features to the source search if needed. That'd at least align things a bit 
closer, rather than diverging further.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157609

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

[Lldb-commits] [lldb] Add `target modules dump separate-debug-info` (PR #66035)

[David Blaikie via lldb-commits]

dwblaikie wrote:

> N_SO is the stab moniker for a source file, and N_OSO is the object file 
> associated with that source file (N_SO was in Sun's implementation, we made 
> up N_OSO). Most nm''s leave off the N_ when they print stabs, so then this 
> became just OSO... 
> We don't do DWO on Darwin, and nobody but Darwin does OSO's, so for now I 
> don't think you need to worry about mixing of the entities in these reports.

Ah, thanks for the context - makes sense.

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

[Lldb-commits] [lldb] de94c10 - The test: test_run_then_attach_wait_interrupt was flakey on Linux & Windows.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2023-09-20T17:38:27-07:00
New Revision: de94c109b64d098c52ffc6f60daadb3eaa8fb944

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

LOG: The test: test_run_then_attach_wait_interrupt was flakey on Linux & 
Windows.

I changed the test so I could tell whether the problem was sometimes the
interrupt was failing, or maybe the was just racy.  It failed again, but
in the new failures we waited 20 seconds for the attach-wait to get interrupted
and that never happened.

So there seems to be some real raciness in the feature of interrupting an
attach-wait, but only on Linux & Windows.  The bug fix that this test was
testing was for a bug that would cause us to never try to interrupt in this
case.  So it looks like this test is uncovering some flakiness in the underlying
interrupt support when in this state.  That's a separate bug that needs fixing.

For now, I disabled the test except on macOS where it seems to run reliably.

Added: 


Modified: 
lldb/test/API/commands/process/attach/TestProcessAttach.py

Removed: 




diff  --git a/lldb/test/API/commands/process/attach/TestProcessAttach.py 
b/lldb/test/API/commands/process/attach/TestProcessAttach.py
index 0e916d2e8e4cbe1..d821b4128cde019 100644
--- a/lldb/test/API/commands/process/attach/TestProcessAttach.py
+++ b/lldb/test/API/commands/process/attach/TestProcessAttach.py
@@ -128,3 +128,88 @@ def tearDown(self):
 
 # Call super's tearDown().
 TestBase.tearDown(self)
+
+# This test is flakey on Linux & Windows.  The failure mode is
+# that sometimes we miss the interrupt and never succeed in
+# getting out of the attach wait.
+@skipUnlessDarwin
+def test_run_then_attach_wait_interrupt(self):
+# Test that having run one process doesn't cause us to be unable
+# to interrupt a subsequent attach attempt.
+self.build()
+exe = self.getBuildArtifact(exe_name)
+
+target = lldbutil.run_to_breakpoint_make_target(self, exe_name, True)
+launch_info = target.GetLaunchInfo()
+launch_info.SetArguments(["q"], True)
+error = lldb.SBError()
+target.Launch(launch_info, error)
+self.assertSuccess(error, "Launched a process")
+self.assertState(target.process.state, lldb.eStateExited, "and it 
exited.") 
+
+# Okay now we've run a process, try to attach/wait to something
+# and make sure that we can interrupt that.
+
+options = lldb.SBCommandInterpreterRunOptions()
+options.SetPrintResults(True)
+options.SetEchoCommands(False)
+
+self.stdin_path = self.getBuildArtifact("stdin.txt")
+
+with open(self.stdin_path, "w") as input_handle:
+input_handle.write("process attach -w -n 
noone_would_use_this_name\nquit")
+
+# Python will close the file descriptor if all references
+# to the filehandle object lapse, so we need to keep one
+# around.
+self.filehandle = open(self.stdin_path, "r")
+self.dbg.SetInputFileHandle(self.filehandle, False)
+
+# No need to track the output
+self.stdout_path = self.getBuildArtifact("stdout.txt")
+self.out_filehandle = open(self.stdout_path, "w")
+self.dbg.SetOutputFileHandle(self.out_filehandle, False)
+self.dbg.SetErrorFileHandle(self.out_filehandle, False)
+
+n_errors, quit_req, crashed = self.dbg.RunCommandInterpreter(
+True, True, options, 0, False, False)
+
+while 1:
+time.sleep(1)
+if target.process.state == lldb.eStateAttaching:
+break
+
+self.dbg.DispatchInputInterrupt()
+self.dbg.DispatchInputInterrupt()
+
+# cycle waiting for the process state to change before trying
+# to read the command output.  I don't want to spin forever.
+counter = 0
+got_exit = False
+while counter < 20:
+if target.process.state == lldb.eStateExited:
+got_exit = True
+break
+counter += 1
+time.sleep(1)
+
+self.assertTrue(got_exit, "The process never switched to eStateExited")
+# Even if the state has flipped, we still need to wait for the
+# command to complete to see the result.  We don't have a way to
+# synchronize on "command completed" right now, but sleeping just
+# a bit should be enough, all that's left is passing this error
+# result to the command, and printing it to the debugger output.
+time.sleep(1)
+
+self.out_filehandle.flush()
+reader = open(self.stdout_path, "r")
+results = reader.readlines()
+found_result = False
+for line in results:

[Lldb-commits] [lldb] 3c61e4b - Copy and paste error in a file header.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2023-09-20T17:43:44-07:00
New Revision: 3c61e4bf28538f5f267b073634e394dd5000af85

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

LOG: Copy and paste error in a file header.

Added: 


Modified: 
lldb/source/Symbol/SymbolFileOnDemand.cpp

Removed: 




diff  --git a/lldb/source/Symbol/SymbolFileOnDemand.cpp 
b/lldb/source/Symbol/SymbolFileOnDemand.cpp
index d3694580194f34c..19b519c63a8a0b7 100644
--- a/lldb/source/Symbol/SymbolFileOnDemand.cpp
+++ b/lldb/source/Symbol/SymbolFileOnDemand.cpp
@@ -1,4 +1,4 @@
-//===-- SymbolFileDWARFDebugMap.cpp 
---===//
+//===-- SymbolFileOnDemand.cpp ---===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.



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

[Lldb-commits] [lldb] [libc++] Implement ranges::contains_subrange (PR #66963)

[via lldb-commits]

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/66963

>From 5a2c930770cf548c5e3f3451e76b48cb067e6762 Mon Sep 17 00:00:00 2001
From: Zijun Zhao 
Date: Wed, 13 Sep 2023 14:26:01 -0700
Subject: [PATCH] [libc++] Implement ranges::contains_subrange

---
 libcxx/include/CMakeLists.txt |   1 +
 .../__algorithm/ranges_contains_subrange.h| 145 +
 libcxx/include/algorithm  |  14 +
 ...obust_against_copying_projections.pass.cpp |   4 +
 .../ranges.contains_subrange.pass.cpp | 293 ++
 .../niebloid.compile.pass.cpp |   3 +
 6 files changed, 460 insertions(+)
 create mode 100644 libcxx/include/__algorithm/ranges_contains_subrange.h
 create mode 100644 
libcxx/test/std/algorithms/alg.nonmodifying/alg.contains/ranges.contains_subrange.pass.cpp

diff --git a/libcxx/include/CMakeLists.txt b/libcxx/include/CMakeLists.txt
index 2ec755236dbaee2..b096259f85f6ac8 100644
--- a/libcxx/include/CMakeLists.txt
+++ b/libcxx/include/CMakeLists.txt
@@ -104,6 +104,7 @@ set(files
   __algorithm/ranges_any_of.h
   __algorithm/ranges_binary_search.h
   __algorithm/ranges_clamp.h
+  __algorithm/ranges_contains_subrange.h
   __algorithm/ranges_copy.h
   __algorithm/ranges_copy_backward.h
   __algorithm/ranges_copy_if.h
diff --git a/libcxx/include/__algorithm/ranges_contains_subrange.h 
b/libcxx/include/__algorithm/ranges_contains_subrange.h
new file mode 100644
index 000..16de6c29cb2a1a4
--- /dev/null
+++ b/libcxx/include/__algorithm/ranges_contains_subrange.h
@@ -0,0 +1,145 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___ALGORITHM_RANGES_CONTAINS_SUBRANGE_H
+#define _LIBCPP___ALGORITHM_RANGES_CONTAINS_SUBRANGE_H
+
+#include <__algorithm/ranges_starts_with.h>
+#include <__config>
+#include <__functional/identity.h>
+#include <__functional/ranges_operations.h>
+#include <__functional/reference_wrapper.h>
+#include <__iterator/concepts.h>
+#include <__iterator/distance.h>
+#include <__iterator/indirectly_comparable.h>
+#include <__iterator/projected.h>
+#include <__ranges/access.h>
+#include <__ranges/concepts.h>
+#include <__utility/move.h>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_STD_VER >= 23
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+namespace ranges {
+namespace __contains_subrange {
+struct __fn {
+  template  _Sent1,
+input_iterator _Iter2,
+sentinel_for<_Iter2> _Sent2,
+class _Pred,
+class _Proj1,
+class _Proj2,
+class _Offset>
+  static _LIBCPP_HIDE_FROM_ABI constexpr bool __contains_subrange_fn_impl(
+  _Iter1 __first1,
+  _Sent1 __last1,
+  _Iter2 __first2,
+  _Sent2 __last2,
+  _Pred& __pred,
+  _Proj1& __proj1,
+  _Proj2& __proj2,
+  _Offset __offset) {
+if (__offset < 0)
+  return false;
+else {
+  for (; __offset >= 0; __offset--, __first1++) {
+auto result = ranges::starts_with(
+std::move(__first1),
+std::move(__last1),
+std::move(__first2),
+std::move(__last2),
+std::ref(__pred),
+std::ref(__proj1),
+std::ref(__proj2));
+if (result)
+  return true;
+  }
+  return false;
+}
+  }
+
+  template  _Sent1,
+input_iterator _Iter2,
+sentinel_for<_Iter2> _Sent2,
+class _Pred  = ranges::equal_to,
+class _Proj1 = identity,
+class _Proj2 = identity>
+requires indirectly_comparable<_Iter1, _Iter2, _Pred, _Proj1, _Proj2>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool operator()(
+  _Iter1 __first1,
+  _Sent1 __last1,
+  _Iter2 __first2,
+  _Sent2 __last2,
+  _Pred __pred   = {},
+  _Proj1 __proj1 = {},
+  _Proj2 __proj2 = {}) const {
+auto __n1 = ranges::distance(__first1, __last1);
+auto __n2 = ranges::distance(__first2, __last2);
+auto __offset = __n1 - __n2;
+
+return __contains_subrange_fn_impl(
+std::move(__first1),
+std::move(__last1),
+std::move(__first2),
+std::move(__last2),
+__pred,
+__proj1,
+__proj2,
+std::move(__offset));
+  }
+
+  template 
+requires indirectly_comparable, iterator_t<_Range2>, 
_Pred, _Proj1, _Proj2>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool operator()(
+  _Range1&& __range1, _Range2&& __range2, _Pred __pred = {}, _Proj1 
__proj1 = {}, _Proj2 __proj2 = {}) const {
+auto __n1 = 0;
+auto __n2 = 0;
+
+if constexp

[Lldb-commits] [lldb] [libc++] Implement ranges::contains_subrange (PR #66963)

[via lldb-commits]

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/66963

>From 5a2c930770cf548c5e3f3451e76b48cb067e6762 Mon Sep 17 00:00:00 2001
From: Zijun Zhao 
Date: Wed, 13 Sep 2023 14:26:01 -0700
Subject: [PATCH] [libc++] Implement ranges::contains_subrange

---
 libcxx/include/CMakeLists.txt |   1 +
 .../__algorithm/ranges_contains_subrange.h| 145 +
 libcxx/include/algorithm  |  14 +
 ...obust_against_copying_projections.pass.cpp |   4 +
 .../ranges.contains_subrange.pass.cpp | 293 ++
 .../niebloid.compile.pass.cpp |   3 +
 6 files changed, 460 insertions(+)
 create mode 100644 libcxx/include/__algorithm/ranges_contains_subrange.h
 create mode 100644 
libcxx/test/std/algorithms/alg.nonmodifying/alg.contains/ranges.contains_subrange.pass.cpp

diff --git a/libcxx/include/CMakeLists.txt b/libcxx/include/CMakeLists.txt
index 2ec755236dbaee2..b096259f85f6ac8 100644
--- a/libcxx/include/CMakeLists.txt
+++ b/libcxx/include/CMakeLists.txt
@@ -104,6 +104,7 @@ set(files
   __algorithm/ranges_any_of.h
   __algorithm/ranges_binary_search.h
   __algorithm/ranges_clamp.h
+  __algorithm/ranges_contains_subrange.h
   __algorithm/ranges_copy.h
   __algorithm/ranges_copy_backward.h
   __algorithm/ranges_copy_if.h
diff --git a/libcxx/include/__algorithm/ranges_contains_subrange.h 
b/libcxx/include/__algorithm/ranges_contains_subrange.h
new file mode 100644
index 000..16de6c29cb2a1a4
--- /dev/null
+++ b/libcxx/include/__algorithm/ranges_contains_subrange.h
@@ -0,0 +1,145 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___ALGORITHM_RANGES_CONTAINS_SUBRANGE_H
+#define _LIBCPP___ALGORITHM_RANGES_CONTAINS_SUBRANGE_H
+
+#include <__algorithm/ranges_starts_with.h>
+#include <__config>
+#include <__functional/identity.h>
+#include <__functional/ranges_operations.h>
+#include <__functional/reference_wrapper.h>
+#include <__iterator/concepts.h>
+#include <__iterator/distance.h>
+#include <__iterator/indirectly_comparable.h>
+#include <__iterator/projected.h>
+#include <__ranges/access.h>
+#include <__ranges/concepts.h>
+#include <__utility/move.h>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_STD_VER >= 23
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+namespace ranges {
+namespace __contains_subrange {
+struct __fn {
+  template  _Sent1,
+input_iterator _Iter2,
+sentinel_for<_Iter2> _Sent2,
+class _Pred,
+class _Proj1,
+class _Proj2,
+class _Offset>
+  static _LIBCPP_HIDE_FROM_ABI constexpr bool __contains_subrange_fn_impl(
+  _Iter1 __first1,
+  _Sent1 __last1,
+  _Iter2 __first2,
+  _Sent2 __last2,
+  _Pred& __pred,
+  _Proj1& __proj1,
+  _Proj2& __proj2,
+  _Offset __offset) {
+if (__offset < 0)
+  return false;
+else {
+  for (; __offset >= 0; __offset--, __first1++) {
+auto result = ranges::starts_with(
+std::move(__first1),
+std::move(__last1),
+std::move(__first2),
+std::move(__last2),
+std::ref(__pred),
+std::ref(__proj1),
+std::ref(__proj2));
+if (result)
+  return true;
+  }
+  return false;
+}
+  }
+
+  template  _Sent1,
+input_iterator _Iter2,
+sentinel_for<_Iter2> _Sent2,
+class _Pred  = ranges::equal_to,
+class _Proj1 = identity,
+class _Proj2 = identity>
+requires indirectly_comparable<_Iter1, _Iter2, _Pred, _Proj1, _Proj2>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool operator()(
+  _Iter1 __first1,
+  _Sent1 __last1,
+  _Iter2 __first2,
+  _Sent2 __last2,
+  _Pred __pred   = {},
+  _Proj1 __proj1 = {},
+  _Proj2 __proj2 = {}) const {
+auto __n1 = ranges::distance(__first1, __last1);
+auto __n2 = ranges::distance(__first2, __last2);
+auto __offset = __n1 - __n2;
+
+return __contains_subrange_fn_impl(
+std::move(__first1),
+std::move(__last1),
+std::move(__first2),
+std::move(__last2),
+__pred,
+__proj1,
+__proj2,
+std::move(__offset));
+  }
+
+  template 
+requires indirectly_comparable, iterator_t<_Range2>, 
_Pred, _Proj1, _Proj2>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool operator()(
+  _Range1&& __range1, _Range2&& __range2, _Pred __pred = {}, _Proj1 
__proj1 = {}, _Proj2 __proj2 = {}) const {
+auto __n1 = 0;
+auto __n2 = 0;
+
+if constexp

[Lldb-commits] [lldb] [libc++] Implement ranges::contains_subrange (PR #66963)

[via lldb-commits]

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/66963

>From 5a2c930770cf548c5e3f3451e76b48cb067e6762 Mon Sep 17 00:00:00 2001
From: Zijun Zhao 
Date: Wed, 13 Sep 2023 14:26:01 -0700
Subject: [PATCH 1/2] [libc++] Implement ranges::contains_subrange

---
 libcxx/include/CMakeLists.txt |   1 +
 .../__algorithm/ranges_contains_subrange.h| 145 +
 libcxx/include/algorithm  |  14 +
 ...obust_against_copying_projections.pass.cpp |   4 +
 .../ranges.contains_subrange.pass.cpp | 293 ++
 .../niebloid.compile.pass.cpp |   3 +
 6 files changed, 460 insertions(+)
 create mode 100644 libcxx/include/__algorithm/ranges_contains_subrange.h
 create mode 100644 
libcxx/test/std/algorithms/alg.nonmodifying/alg.contains/ranges.contains_subrange.pass.cpp

diff --git a/libcxx/include/CMakeLists.txt b/libcxx/include/CMakeLists.txt
index 2ec755236dbaee2..b096259f85f6ac8 100644
--- a/libcxx/include/CMakeLists.txt
+++ b/libcxx/include/CMakeLists.txt
@@ -104,6 +104,7 @@ set(files
   __algorithm/ranges_any_of.h
   __algorithm/ranges_binary_search.h
   __algorithm/ranges_clamp.h
+  __algorithm/ranges_contains_subrange.h
   __algorithm/ranges_copy.h
   __algorithm/ranges_copy_backward.h
   __algorithm/ranges_copy_if.h
diff --git a/libcxx/include/__algorithm/ranges_contains_subrange.h 
b/libcxx/include/__algorithm/ranges_contains_subrange.h
new file mode 100644
index 000..16de6c29cb2a1a4
--- /dev/null
+++ b/libcxx/include/__algorithm/ranges_contains_subrange.h
@@ -0,0 +1,145 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___ALGORITHM_RANGES_CONTAINS_SUBRANGE_H
+#define _LIBCPP___ALGORITHM_RANGES_CONTAINS_SUBRANGE_H
+
+#include <__algorithm/ranges_starts_with.h>
+#include <__config>
+#include <__functional/identity.h>
+#include <__functional/ranges_operations.h>
+#include <__functional/reference_wrapper.h>
+#include <__iterator/concepts.h>
+#include <__iterator/distance.h>
+#include <__iterator/indirectly_comparable.h>
+#include <__iterator/projected.h>
+#include <__ranges/access.h>
+#include <__ranges/concepts.h>
+#include <__utility/move.h>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_STD_VER >= 23
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+namespace ranges {
+namespace __contains_subrange {
+struct __fn {
+  template  _Sent1,
+input_iterator _Iter2,
+sentinel_for<_Iter2> _Sent2,
+class _Pred,
+class _Proj1,
+class _Proj2,
+class _Offset>
+  static _LIBCPP_HIDE_FROM_ABI constexpr bool __contains_subrange_fn_impl(
+  _Iter1 __first1,
+  _Sent1 __last1,
+  _Iter2 __first2,
+  _Sent2 __last2,
+  _Pred& __pred,
+  _Proj1& __proj1,
+  _Proj2& __proj2,
+  _Offset __offset) {
+if (__offset < 0)
+  return false;
+else {
+  for (; __offset >= 0; __offset--, __first1++) {
+auto result = ranges::starts_with(
+std::move(__first1),
+std::move(__last1),
+std::move(__first2),
+std::move(__last2),
+std::ref(__pred),
+std::ref(__proj1),
+std::ref(__proj2));
+if (result)
+  return true;
+  }
+  return false;
+}
+  }
+
+  template  _Sent1,
+input_iterator _Iter2,
+sentinel_for<_Iter2> _Sent2,
+class _Pred  = ranges::equal_to,
+class _Proj1 = identity,
+class _Proj2 = identity>
+requires indirectly_comparable<_Iter1, _Iter2, _Pred, _Proj1, _Proj2>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool operator()(
+  _Iter1 __first1,
+  _Sent1 __last1,
+  _Iter2 __first2,
+  _Sent2 __last2,
+  _Pred __pred   = {},
+  _Proj1 __proj1 = {},
+  _Proj2 __proj2 = {}) const {
+auto __n1 = ranges::distance(__first1, __last1);
+auto __n2 = ranges::distance(__first2, __last2);
+auto __offset = __n1 - __n2;
+
+return __contains_subrange_fn_impl(
+std::move(__first1),
+std::move(__last1),
+std::move(__first2),
+std::move(__last2),
+__pred,
+__proj1,
+__proj2,
+std::move(__offset));
+  }
+
+  template 
+requires indirectly_comparable, iterator_t<_Range2>, 
_Pred, _Proj1, _Proj2>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool operator()(
+  _Range1&& __range1, _Range2&& __range2, _Pred __pred = {}, _Proj1 
__proj1 = {}, _Proj2 __proj2 = {}) const {
+auto __n1 = 0;
+auto __n2 = 0;
+
+if cons

[Lldb-commits] [lldb] 1a78444 - Temoprarily stop running this test on Intel macs

[Jason Molenda via lldb-commits]

Author: Jason Molenda
Date: 2023-09-20T21:49:15-07:00
New Revision: 1a78b32ce8577b72aad6239525740da271ed

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

LOG: Temoprarily stop running this test on Intel macs

The test is expecting watchpoint hits that are valid on aarch64
systems but not on Intel.  I need to update this test to match the
actual behavior on Intel macs, and don't want the CI bots to stay
broken while I get that figured out.

Added: 


Modified: 

lldb/test/API/functionalities/watchpoint/unaligned-spanning-two-dwords/TestUnalignedSpanningDwords.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/watchpoint/unaligned-spanning-two-dwords/TestUnalignedSpanningDwords.py
 
b/lldb/test/API/functionalities/watchpoint/unaligned-spanning-two-dwords/TestUnalignedSpanningDwords.py
index e37a74f1f5aacc3..9a0f451c64c3026 100644
--- 
a/lldb/test/API/functionalities/watchpoint/unaligned-spanning-two-dwords/TestUnalignedSpanningDwords.py
+++ 
b/lldb/test/API/functionalities/watchpoint/unaligned-spanning-two-dwords/TestUnalignedSpanningDwords.py
@@ -25,7 +25,7 @@ def hit_watchpoint_and_continue(self, process, iter_str):
 NO_DEBUG_INFO_TESTCASE = True
 
 # debugserver on AArch64 has this feature.
-@skipIf(archs=no_match(["x86_64", "arm64", "arm64e", "aarch64"]))
+@skipIf(archs=no_match(["arm64", "arm64e", "aarch64"]))
 @skipUnlessDarwin
 # debugserver only started returning an exception address within
 # a range lldb expects in https://reviews.llvm.org/D147820 2023-04-12.
@@ -41,6 +41,8 @@ def test_unaligned_watchpoint(self):
 self, "break here", self.main_source_file
 )
 
+thread.StepOver()
+
 frame = thread.GetFrameAtIndex(0)
 
 a_bytebuf_6 = frame.GetValueForVariablePath("a.bytebuf[6]")



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