[Lldb-commits] [lldb] [WIP][lldb][test] Add a layout simulator test for std::unique_ptr (PR #98330)

[Michael Buch via lldb-commits]

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

>From a25b3c8a6a36326730d00d1060ff84181bece26e Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Wed, 10 Jul 2024 15:37:45 +0100
Subject: [PATCH 1/6] [WIP][lldb][test] Add a layout simulator test for
 std::unique_ptr

---
 .../libcxx-simulators/compressed_pair.h   | 89 +++
 .../libcxx-simulators/unique_ptr/Makefile |  3 +
 ...stDataFormatterLibcxxUniquePtrSimulator.py | 32 +++
 .../libcxx-simulators/unique_ptr/main.cpp | 43 +
 4 files changed, 167 insertions(+)
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/compressed_pair.h
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/Makefile
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/TestDataFormatterLibcxxUniquePtrSimulator.py
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/main.cpp

diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/compressed_pair.h
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/compressed_pair.h
new file mode 100644
index 0..ec978b8053646
--- /dev/null
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/compressed_pair.h
@@ -0,0 +1,89 @@
+#ifndef STD_LLDB_COMPRESSED_PAIR_H
+#define STD_LLDB_COMPRESSED_PAIR_H
+
+#include <__memory/compressed_pair.h>
+#include 
+
+namespace std {
+namespace __lldb {
+
+#if COMPRESSED_PAIR_REV == 0 // Post-c88580c layout
+struct __value_init_tag {};
+struct __default_init_tag {};
+
+template ::value && !std::is_final<_Tp>::value>
+struct __compressed_pair_elem {
+  explicit __compressed_pair_elem(__default_init_tag) {}
+  explicit __compressed_pair_elem(__value_init_tag) : __value_() {}
+
+  explicit __compressed_pair_elem(_Tp __t) : __value_(__t) {}
+
+  _Tp &__get() { return __value_; }
+
+private:
+  _Tp __value_;
+};
+
+template 
+struct __compressed_pair_elem<_Tp, _Idx, true> : private _Tp {
+  explicit __compressed_pair_elem(_Tp __t) : _Tp(__t) {}
+  explicit __compressed_pair_elem(__default_init_tag) {}
+  explicit __compressed_pair_elem(__value_init_tag) : _Tp() {}
+
+  _Tp &__get() { return *this; }
+};
+
+template 
+class __compressed_pair : private __compressed_pair_elem<_T1, 0>,
+  private __compressed_pair_elem<_T2, 1> {
+public:
+  using _Base1 = __compressed_pair_elem<_T1, 0>;
+  using _Base2 = __compressed_pair_elem<_T2, 1>;
+
+  explicit __compressed_pair(_T1 __t1, _T2 __t2) : _Base1(__t1), _Base2(__t2) 
{}
+  explicit __compressed_pair()
+  : _Base1(__value_init_tag()), _Base2(__value_init_tag()) {}
+
+  template 
+  explicit __compressed_pair(_U1 &&__t1, _U2 &&__t2)
+  : _Base1(std::forward<_U1>(__t1)), _Base2(std::forward<_U2>(__t2)) {}
+
+  _T1 &first() { return static_cast<_Base1 &>(*this).__get(); }
+};
+#elif COMPRESSED_PAIR_REV == 1
+#define _LLDB_COMPRESSED_PAIR(T1, Initializer1, T2, Initializer2)  
\
+  [[__gnu__::__aligned__(alignof(T2))]] [[no_unique_address]] T1 Initializer1; 
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding1_, __LINE__, _);   
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding2_, __LINE__, _)
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Initializer1, T2, Initializer2, T3,
\
+Initializer3)  
\
+  [[using __gnu__: __aligned__(alignof(T2)),   
\
+__aligned__(alignof(T3))]] [[no_unique_address]] T1 Initializer1;  
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding1_, __LINE__, _);   
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding2_, __LINE__, _);   
\
+  [[no_unique_address]] T3 Initializer3;   
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding3_, __LINE__, _)
+#elif COMPRESSED_PAIR_REV == 2
+#define _LLDB_COMPRESSED_PAIR(T1, Name1, T2, Name2)
\
+  [[no_unique_address]] T1 Name1;  
\
+  [[no_unique_address]] T2 Name2
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Name1, T2, Name2, T3, Name3)   
\
+  [[no_unique_address]] T1 Name1; 

[Lldb-commits] [lldb] [WIP][lldb][test] Add a layout simulator test for std::unique_ptr (PR #98330)

[Michael Buch via lldb-commits]

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

>From a25b3c8a6a36326730d00d1060ff84181bece26e Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Wed, 10 Jul 2024 15:37:45 +0100
Subject: [PATCH 1/5] [WIP][lldb][test] Add a layout simulator test for
 std::unique_ptr

---
 .../libcxx-simulators/compressed_pair.h   | 89 +++
 .../libcxx-simulators/unique_ptr/Makefile |  3 +
 ...stDataFormatterLibcxxUniquePtrSimulator.py | 32 +++
 .../libcxx-simulators/unique_ptr/main.cpp | 43 +
 4 files changed, 167 insertions(+)
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/compressed_pair.h
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/Makefile
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/TestDataFormatterLibcxxUniquePtrSimulator.py
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/main.cpp

diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/compressed_pair.h
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/compressed_pair.h
new file mode 100644
index 0..ec978b8053646
--- /dev/null
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/compressed_pair.h
@@ -0,0 +1,89 @@
+#ifndef STD_LLDB_COMPRESSED_PAIR_H
+#define STD_LLDB_COMPRESSED_PAIR_H
+
+#include <__memory/compressed_pair.h>
+#include 
+
+namespace std {
+namespace __lldb {
+
+#if COMPRESSED_PAIR_REV == 0 // Post-c88580c layout
+struct __value_init_tag {};
+struct __default_init_tag {};
+
+template ::value && !std::is_final<_Tp>::value>
+struct __compressed_pair_elem {
+  explicit __compressed_pair_elem(__default_init_tag) {}
+  explicit __compressed_pair_elem(__value_init_tag) : __value_() {}
+
+  explicit __compressed_pair_elem(_Tp __t) : __value_(__t) {}
+
+  _Tp &__get() { return __value_; }
+
+private:
+  _Tp __value_;
+};
+
+template 
+struct __compressed_pair_elem<_Tp, _Idx, true> : private _Tp {
+  explicit __compressed_pair_elem(_Tp __t) : _Tp(__t) {}
+  explicit __compressed_pair_elem(__default_init_tag) {}
+  explicit __compressed_pair_elem(__value_init_tag) : _Tp() {}
+
+  _Tp &__get() { return *this; }
+};
+
+template 
+class __compressed_pair : private __compressed_pair_elem<_T1, 0>,
+  private __compressed_pair_elem<_T2, 1> {
+public:
+  using _Base1 = __compressed_pair_elem<_T1, 0>;
+  using _Base2 = __compressed_pair_elem<_T2, 1>;
+
+  explicit __compressed_pair(_T1 __t1, _T2 __t2) : _Base1(__t1), _Base2(__t2) 
{}
+  explicit __compressed_pair()
+  : _Base1(__value_init_tag()), _Base2(__value_init_tag()) {}
+
+  template 
+  explicit __compressed_pair(_U1 &&__t1, _U2 &&__t2)
+  : _Base1(std::forward<_U1>(__t1)), _Base2(std::forward<_U2>(__t2)) {}
+
+  _T1 &first() { return static_cast<_Base1 &>(*this).__get(); }
+};
+#elif COMPRESSED_PAIR_REV == 1
+#define _LLDB_COMPRESSED_PAIR(T1, Initializer1, T2, Initializer2)  
\
+  [[__gnu__::__aligned__(alignof(T2))]] [[no_unique_address]] T1 Initializer1; 
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding1_, __LINE__, _);   
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding2_, __LINE__, _)
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Initializer1, T2, Initializer2, T3,
\
+Initializer3)  
\
+  [[using __gnu__: __aligned__(alignof(T2)),   
\
+__aligned__(alignof(T3))]] [[no_unique_address]] T1 Initializer1;  
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding1_, __LINE__, _);   
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding2_, __LINE__, _);   
\
+  [[no_unique_address]] T3 Initializer3;   
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding3_, __LINE__, _)
+#elif COMPRESSED_PAIR_REV == 2
+#define _LLDB_COMPRESSED_PAIR(T1, Name1, T2, Name2)
\
+  [[no_unique_address]] T1 Name1;  
\
+  [[no_unique_address]] T2 Name2
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Name1, T2, Name2, T3, Name3)   
\
+  [[no_unique_address]] T1 Name1; 

[Lldb-commits] [lldb] [WIP][lldb][test] Add a layout simulator test for std::unique_ptr (PR #98330)

[Michael Buch via lldb-commits]

Michael137 wrote:

I removed the new compressed_pair layouts from this patch so we can land it in 
isolation. I'll open a separate PR that introduces those back which we can then 
land once libc++ actually introduces those new layouts in-tree.

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

[Lldb-commits] [lldb] [lldb][test] Add a layout simulator test for std::unique_ptr (PR #98330)

[Michael Buch via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][test] Add a layout simulator test for std::unique_ptr (PR #98330)

[Michael Buch via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][test] Fix ComputeClangResourceDirectory test when CLANG_RESOURCE_DIR is set (PR #98464)

[David Spickett via lldb-commits]

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

[Lldb-commits] [lldb] fe97671 - [lldb][test] Fix ComputeClangResourceDirectory test when CLANG_RESOURCE_DIR is set (#98464)

[via lldb-commits]

Author: David Spickett
Date: 2024-07-12T09:30:33+01:00
New Revision: fe9767105af65f0a7345afb6bb2f14e5d4404a15

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

LOG: [lldb][test] Fix ComputeClangResourceDirectory test when 
CLANG_RESOURCE_DIR is set (#98464)

This was found during testing of llvm snapshots for Fedora.

This test was looking for an exact string match of the path calculated
by starting with lib/liblldb and with bin/lldb. However when
CLANG_RESOURCE_DIR is set to something e.g. "../lib/clang/19", the way
the initial path is handled is different.

Instead of taking the parent of the parent of the binary, that is
foo/bin/lldb/ -> foo/, it uses the parent of the binary and appends
CLANG_RESOURCE_DIR to that. As CLANG_RESOURCE_DIR is defined as being a
path relative to the parent dir's of the clang binary.

This means that if you start with foo/lib/lidblldb the resulting path is
lib/../lib/clang/19, but if you start with bin/lldb the result is
bin/../lib/clang/19.

I don't want to change the starting path of
DefaultComputeClangResourceDirectory (which is bin/lldb) as I suspect
that's chosen instead of liblldb for good reason.

So the way to make this test work is to check not for exact path matches
but that the "real" (".." resolved) version of the paths are the same.
That way foo/bin/../lib and foo/lib/../lib will be the same.

Added: 


Modified: 
lldb/unittests/Expression/ClangParserTest.cpp

Removed: 




diff  --git a/lldb/unittests/Expression/ClangParserTest.cpp 
b/lldb/unittests/Expression/ClangParserTest.cpp
index ed5ee323b7d20..6f682f6c97fdb 100644
--- a/lldb/unittests/Expression/ClangParserTest.cpp
+++ b/lldb/unittests/Expression/ClangParserTest.cpp
@@ -44,7 +44,17 @@ TEST_F(ClangHostTest, ComputeClangResourceDirectory) {
 #endif
   std::string path_to_clang_dir = clang::driver::Driver::GetResourcesPath(
   path_to_liblldb + "liblldb", CLANG_RESOURCE_DIR);
-  EXPECT_EQ(ComputeClangResourceDir(path_to_liblldb), path_to_clang_dir);
+  llvm::SmallString<256> path_to_clang_lib_dir_real;
+  llvm::sys::fs::real_path(path_to_clang_dir, path_to_clang_lib_dir_real);
+
+  std::string computed_path = ComputeClangResourceDir(path_to_liblldb);
+  llvm::SmallString<256> computed_path_real;
+  llvm::sys::fs::real_path(computed_path, computed_path_real);
+
+  // When CLANG_RESOURCE_DIR is set, both the functions we use here behave in
+  // such a way that leads to one path being lib/ and the other bin/. Check 
that
+  // they are equivalent after any ".." have been resolved.
+  EXPECT_EQ(path_to_clang_lib_dir_real, computed_path_real);
 
   // The path doesn't really exist, so setting verify to true should make
   // ComputeClangResourceDir not give you path_to_clang_dir.



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

[Lldb-commits] [lldb] [lldb] Add support for displaying `__float128` variables (PR #98369)

[David Spickett via lldb-commits]

@@ -195,10 +199,10 @@ enum Format {
  ///< character arrays that can contain non printable
  ///< characters
   eFormatAddressInfo,///< Describe what an address points to (func + offset
-  ///< with file/line, symbol + offset, data, etc)
-  eFormatHexFloat,///< ISO C99 hex float string
-  eFormatInstruction, ///< Disassemble an opcode
-  eFormatVoid,///< Do not print this
+ ///< with file/line, symbol + offset, data, etc)
+  eFormatHexFloat,   ///< ISO C99 hex float string
+  eFormatInstruction,///< Disassemble an opcode
+  eFormatVoid,   ///< Do not print this

DavidSpickett wrote:

FYI that llvm does squash and merge only, so the commits will become one. So 
you can either push each part of this PR manually or push the formatting change 
separately after the PR goes in.

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

[Lldb-commits] [lldb] [lldb] Add support for displaying `__float128` variables (PR #98369)

[via lldb-commits]

@@ -195,10 +199,10 @@ enum Format {
  ///< character arrays that can contain non printable
  ///< characters
   eFormatAddressInfo,///< Describe what an address points to (func + offset
-  ///< with file/line, symbol + offset, data, etc)
-  eFormatHexFloat,///< ISO C99 hex float string
-  eFormatInstruction, ///< Disassemble an opcode
-  eFormatVoid,///< Do not print this
+ ///< with file/line, symbol + offset, data, etc)
+  eFormatHexFloat,   ///< ISO C99 hex float string
+  eFormatInstruction,///< Disassemble an opcode
+  eFormatVoid,   ///< Do not print this

beetrees wrote:

I'm happy to remove the formatting change from this PR, but that will cause the 
PR CI to fail. Will that be an issue? (I don't have commit access so I can't 
push anything directly.)

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

[Lldb-commits] [lldb] [lldb] Add support for displaying `__float128` variables (PR #98369)

[David Spickett via lldb-commits]

@@ -195,10 +199,10 @@ enum Format {
  ///< character arrays that can contain non printable
  ///< characters
   eFormatAddressInfo,///< Describe what an address points to (func + offset
-  ///< with file/line, symbol + offset, data, etc)
-  eFormatHexFloat,///< ISO C99 hex float string
-  eFormatInstruction, ///< Disassemble an opcode
-  eFormatVoid,///< Do not print this
+ ///< with file/line, symbol + offset, data, etc)
+  eFormatHexFloat,   ///< ISO C99 hex float string
+  eFormatInstruction,///< Disassemble an opcode
+  eFormatVoid,   ///< Do not print this

DavidSpickett wrote:

No, the format check doesn't block merging.

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

[Lldb-commits] [lldb] [lldb] Add support for displaying `__float128` variables (PR #98369)

[via lldb-commits]

https://github.com/beetrees updated 
https://github.com/llvm/llvm-project/pull/98369

>From 4f9774916d3d31f31c810d0930f7961bf348802c Mon Sep 17 00:00:00 2001
From: beetrees 
Date: Wed, 10 Jul 2024 18:49:45 +0100
Subject: [PATCH] [lldb] Add support for displaying `__float128` variables

---
 lldb/bindings/python/python-extensions.swig   |  1 +
 lldb/docs/python_api_enums.rst|  2 ++
 lldb/include/lldb/lldb-enumerations.h |  7 ++-
 lldb/source/Commands/CommandObjectMemory.cpp  |  2 ++
 lldb/source/Core/DumpDataExtractor.cpp|  5 -
 lldb/source/Core/ValueObject.cpp  |  5 +++--
 lldb/source/DataFormatters/FormatManager.cpp  |  1 +
 lldb/source/DataFormatters/VectorType.cpp |  2 ++
 .../TypeSystem/Clang/TypeSystemClang.cpp  | 21 +++
 lldb/unittests/Core/DumpDataExtractorTest.cpp |  6 ++
 lldb/unittests/Symbol/TestTypeSystemClang.cpp |  2 ++
 11 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/lldb/bindings/python/python-extensions.swig 
b/lldb/bindings/python/python-extensions.swig
index 4ba1607c70909..40fa76872ee96 100644
--- a/lldb/bindings/python/python-extensions.swig
+++ b/lldb/bindings/python/python-extensions.swig
@@ -594,6 +594,7 @@ def is_numeric_type(basic_type):
 if basic_type == eBasicTypeFloat: return (True,True)
 if basic_type == eBasicTypeDouble: return (True,True)
 if basic_type == eBasicTypeLongDouble: return (True,True)
+if basic_type == eBasicTypeFloat128: return (True,True)
 if basic_type == eBasicTypeFloatComplex: return (True,True)
 if basic_type == eBasicTypeDoubleComplex: return (True,True)
 if basic_type == eBasicTypeLongDoubleComplex: return (True,True)
diff --git a/lldb/docs/python_api_enums.rst b/lldb/docs/python_api_enums.rst
index b6a2497ea878e..a43a47b8d6985 100644
--- a/lldb/docs/python_api_enums.rst
+++ b/lldb/docs/python_api_enums.rst
@@ -321,6 +321,7 @@ Format
 .. py:data:: eFormatInstruction
 .. py:data:: eFormatVoid
 .. py:data:: eFormatUnicode8
+.. py:data:: eFormatFloat128
 
 
 .. _DescriptionLevel:
@@ -1045,6 +1046,7 @@ BasicType
 .. py:data:: eBasicTypeObjCSel
 .. py:data:: eBasicTypeNullPtr
 .. py:data:: eBasicTypeOther
+.. py:data:: eBasicTypeFloat128
 
 
 .. _TraceType:
diff --git a/lldb/include/lldb/lldb-enumerations.h 
b/lldb/include/lldb/lldb-enumerations.h
index 74ff458bf87de..14d2466a45780 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -200,6 +200,10 @@ enum Format {
   eFormatInstruction, ///< Disassemble an opcode
   eFormatVoid,///< Do not print this
   eFormatUnicode8,
+  eFormatFloat128, //< Disambiguate between 128-bit `long double` (which uses
+   //< `eFormatFloat`) and `__float128` (which uses
+   //< `eFormatFloat128`). If the value being formatted is not
+   //< 128 bits, then this is identical to `eFormatFloat`.
   kNumFormats
 };
 
@@ -826,7 +830,8 @@ enum BasicType {
   eBasicTypeObjCClass,
   eBasicTypeObjCSel,
   eBasicTypeNullPtr,
-  eBasicTypeOther
+  eBasicTypeOther,
+  eBasicTypeFloat128
 };
 
 /// Deprecated
diff --git a/lldb/source/Commands/CommandObjectMemory.cpp 
b/lldb/source/Commands/CommandObjectMemory.cpp
index 137b1ad981073..dde27d2df0fe5 100644
--- a/lldb/source/Commands/CommandObjectMemory.cpp
+++ b/lldb/source/Commands/CommandObjectMemory.cpp
@@ -156,6 +156,7 @@ class OptionGroupReadMemory : public OptionGroup {
 
 case eFormatBinary:
 case eFormatFloat:
+case eFormatFloat128:
 case eFormatOctal:
 case eFormatDecimal:
 case eFormatEnum:
@@ -1329,6 +1330,7 @@ class CommandObjectMemoryWrite : public 
CommandObjectParsed {
   switch (m_format_options.GetFormat()) {
   case kNumFormats:
   case eFormatFloat: // TODO: add support for floats soon
+  case eFormatFloat128:
   case eFormatCharPrintable:
   case eFormatBytesWithASCII:
   case eFormatComplex:
diff --git a/lldb/source/Core/DumpDataExtractor.cpp 
b/lldb/source/Core/DumpDataExtractor.cpp
index 826edd7bab046..805ec5e703cbb 100644
--- a/lldb/source/Core/DumpDataExtractor.cpp
+++ b/lldb/source/Core/DumpDataExtractor.cpp
@@ -652,6 +652,7 @@ lldb::offset_t lldb_private::DumpDataExtractor(
   }
 } break;
 
+case eFormatFloat128:
 case eFormatFloat: {
   TargetSP target_sp;
   if (exe_scope)
@@ -665,7 +666,9 @@ lldb::offset_t lldb_private::DumpDataExtractor(
   const unsigned format_precision = 0;
 
   const llvm::fltSemantics &semantics =
-  GetFloatSemantics(target_sp, item_byte_size);
+  item_format == eFormatFloat128 && item_byte_size == 16
+  ? llvm::APFloat::IEEEquad()
+  : GetFloatSemantics(target_sp, item_byte_size);
 
   // Recalculate the byte size in case of a difference. This is possible
   // when item_byte_size is 16 (128-bit), because you could get back the
diff --git a/lldb/source/Core/ValueObject.cpp b/lldb/source/Co

[Lldb-commits] [lldb] [lldb] Add support for displaying `__float128` variables (PR #98369)

[via lldb-commits]

@@ -195,10 +199,10 @@ enum Format {
  ///< character arrays that can contain non printable
  ///< characters
   eFormatAddressInfo,///< Describe what an address points to (func + offset
-  ///< with file/line, symbol + offset, data, etc)
-  eFormatHexFloat,///< ISO C99 hex float string
-  eFormatInstruction, ///< Disassemble an opcode
-  eFormatVoid,///< Do not print this
+ ///< with file/line, symbol + offset, data, etc)
+  eFormatHexFloat,   ///< ISO C99 hex float string
+  eFormatInstruction,///< Disassemble an opcode
+  eFormatVoid,   ///< Do not print this

beetrees wrote:

I've dropped the formatting changes from this PR.

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

[Lldb-commits] [lldb] [lldb] Add support for displaying `__float128` variables (PR #98369)

[via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][test] Narrow enum test xfail to clang < 19.0 (PR #98616)

[David Spickett via lldb-commits]

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

Sice #98335 clang adds DW_AT_type, unless strict DWARF is requested.

>From 6b21c9e4dc4735dbd1be8c1b125e35c3ee01bbf7 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Fri, 12 Jul 2024 10:29:31 +
Subject: [PATCH] [lldb][test] Narrow enum test xfail to clang < 19.0

Sice #98335 clang adds DW_AT_type, unless strict DWARF is
requested.
---
 .../expression/bitfield_enums/TestBitfieldEnums.py| 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git 
a/lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py 
b/lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py
index dbe9b9241a9ac..05db4075870b8 100644
--- a/lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py
+++ b/lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py
@@ -10,9 +10,11 @@
 
 
 class TestBitfieldEnum(TestBase):
-# clang's DWARF v2 output is missing DW_AT_type which causes unsigned_max 
to
-# appear as -1 instead of the "max" enumerator, whose value is 3.
-@skipIf(dwarf_version=["<", "3"], compiler="clang")
+# Prior to clang-19, clang's DWARF v2 is missing missing DW_AT_type which
+# causes unsigned_max to appear as -1 instead of the "max" enumerator, 
whose
+# value is 3. From 19 onward, DW_AT_type is added as long as strict DWARF
+# is not enabled.
+@skipIf(dwarf_version=["<", "3"], compiler="clang", compiler_version=["<", 
"19.0"])
 def test_bitfield_enums(self):
 self.build()
 

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

[Lldb-commits] [lldb] [lldb][test] Narrow enum test xfail to clang < 19.0 (PR #98616)

[David Spickett via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][test] Narrow enum test xfail to clang < 19.0 (PR #98616)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)


Changes

Since #98335 clang adds DW_AT_type, unless strict DWARF is requested.

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


1 Files Affected:

- (modified) 
lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py (+5-3) 


``diff
diff --git 
a/lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py 
b/lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py
index dbe9b9241a9ac..05db4075870b8 100644
--- a/lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py
+++ b/lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py
@@ -10,9 +10,11 @@
 
 
 class TestBitfieldEnum(TestBase):
-# clang's DWARF v2 output is missing DW_AT_type which causes unsigned_max 
to
-# appear as -1 instead of the "max" enumerator, whose value is 3.
-@skipIf(dwarf_version=["<", "3"], compiler="clang")
+# Prior to clang-19, clang's DWARF v2 is missing missing DW_AT_type which
+# causes unsigned_max to appear as -1 instead of the "max" enumerator, 
whose
+# value is 3. From 19 onward, DW_AT_type is added as long as strict DWARF
+# is not enabled.
+@skipIf(dwarf_version=["<", "3"], compiler="clang", compiler_version=["<", 
"19.0"])
 def test_bitfield_enums(self):
 self.build()
 

``




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

[Lldb-commits] [lldb] [lldb][test] Narrow enum test xfail to clang < 19.0 (PR #98616)

[Michael Buch via lldb-commits]

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


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

[Lldb-commits] [lldb] [lldb] Allow fetching of RA register when above fault handler (PR #98566)

[David Spickett via lldb-commits]

DavidSpickett wrote:

> Without this fix, a frameless function that faults in a firmware environment 
> (that's where we've seen this issue most commonly) hasn't spilled lr to 
> stack, so we need to retrieve it from the fault handler's 
> full-register-context to find the caller of the frameless function that 
> faulted.

So the difference between being interrupted and making a function call is that 
the latter allows you to store the link register then make the call. A signal 
may come in at any time, so there may be no saved lr in the frame record at the 
time the interrupt happens.

And this fix means specifically that if you're inside the function that was 
interrupted, we will read its lr from the fault handler context?

Sounds good to me.

Testing this is in theory possible, tricky bit is guaranteeing a frameless 
function. There is the naked attribute but it's not portable 
https://godbolt.org/z/s9117Gr7a. Or you could write the function in an assembly 
file, or declare and call it inside an inline assembly block, inside a normal C 
function. That function would branch to self waiting for SIGALRM for example.

Maybe that has its own problems, I haven't tried it. Maybe it wouldn't generate 
enough debug info for us to know that the assembly function was there?

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

[Lldb-commits] [lldb] [llvm] [DRAFT][llvm]Added lib/Telemetry (PR #98528)

[Vy Nguyen via lldb-commits]

oontvoo wrote:

> Why does any part of this need to be in llvm/ at all?

Please see comments on the rfc at 
https://discourse.llvm.org/t/rfc-lldb-telemetry-metrics/64588/15

TL;DR : A few people feel that Telemetry is not something unique to LLDB and 
that other tools might be interested in having it too. So rather than having 
mutliple Telemetry libs doing similar things, it might be good to have at least 
a common API

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

[Lldb-commits] [lldb] c471d36 - [lldb][test] Narrow enum test xfail to clang < 19.0 (#98616)

[via lldb-commits]

Author: David Spickett
Date: 2024-07-12T13:12:35+01:00
New Revision: c471d3650aa3c6c1ddab64c029b7b89b12d18938

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

LOG: [lldb][test] Narrow enum test xfail to clang < 19.0 (#98616)

Since #98335 clang adds DW_AT_type, unless strict DWARF is requested.

Added: 


Modified: 
lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py

Removed: 




diff  --git 
a/lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py 
b/lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py
index dbe9b9241a9ac..05db4075870b8 100644
--- a/lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py
+++ b/lldb/test/API/commands/expression/bitfield_enums/TestBitfieldEnums.py
@@ -10,9 +10,11 @@
 
 
 class TestBitfieldEnum(TestBase):
-# clang's DWARF v2 output is missing DW_AT_type which causes unsigned_max 
to
-# appear as -1 instead of the "max" enumerator, whose value is 3.
-@skipIf(dwarf_version=["<", "3"], compiler="clang")
+# Prior to clang-19, clang's DWARF v2 is missing missing DW_AT_type which
+# causes unsigned_max to appear as -1 instead of the "max" enumerator, 
whose
+# value is 3. From 19 onward, DW_AT_type is added as long as strict DWARF
+# is not enabled.
+@skipIf(dwarf_version=["<", "3"], compiler="clang", compiler_version=["<", 
"19.0"])
 def test_bitfield_enums(self):
 self.build()
 



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

[Lldb-commits] [lldb] [lldb][test] Narrow enum test xfail to clang < 19.0 (PR #98616)

[David Spickett via lldb-commits]

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

[Lldb-commits] [lldb] [LLDB] Fix remote executables load and caching (PR #98623)

[Vladislav Dzhidzhoev via lldb-commits]

https://github.com/dzhidzhoev created 
https://github.com/llvm/llvm-project/pull/98623

Seemingly, #96256 removed the only call to
Platform::GetCachedExecutable, which broke the resolution of executable modules 
in the remote debugging mode
(https://github.com/llvm/llvm-project/issues/97410).

This commit fixes that.

>From 3f8a4164ddc06a3faffe61d95e5023d367d757f0 Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev 
Date: Thu, 11 Jul 2024 17:53:08 +0200
Subject: [PATCH] [LLDB] Fix remote executables load and caching

Seemingly, #96256 removed the only call to
Platform::GetCachedExecutable, which broke the resolution of executable
modules in the remote debugging mode
(https://github.com/llvm/llvm-project/issues/97410).

This commit fixes that.
---
 lldb/source/Target/Platform.cpp| 2 +-
 lldb/source/Target/RemoteAwarePlatform.cpp | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/lldb/source/Target/Platform.cpp b/lldb/source/Target/Platform.cpp
index bb90c377d86b2..1900898db6494 100644
--- a/lldb/source/Target/Platform.cpp
+++ b/lldb/source/Target/Platform.cpp
@@ -1446,7 +1446,7 @@ Platform::GetCachedExecutable(ModuleSpec &module_spec,
   Status error = GetRemoteSharedModule(
   module_spec, nullptr, module_sp,
   [&](const ModuleSpec &spec) {
-return ResolveExecutable(spec, module_sp, module_search_paths_ptr);
+return Platform::ResolveExecutable(spec, module_sp, 
module_search_paths_ptr);
   },
   nullptr);
   if (error.Success()) {
diff --git a/lldb/source/Target/RemoteAwarePlatform.cpp 
b/lldb/source/Target/RemoteAwarePlatform.cpp
index 5fc2d63876b92..f3aafb87149c8 100644
--- a/lldb/source/Target/RemoteAwarePlatform.cpp
+++ b/lldb/source/Target/RemoteAwarePlatform.cpp
@@ -46,6 +46,9 @@ Status RemoteAwarePlatform::ResolveExecutable(
 
 if (!FileSystem::Instance().Exists(resolved_file_spec))
   FileSystem::Instance().ResolveExecutableLocation(resolved_file_spec);
+  } else if (m_remote_platform_sp) {
+return GetCachedExecutable(resolved_module_spec, exe_module_sp,
+module_search_paths_ptr);
   }
 
   return Platform::ResolveExecutable(resolved_module_spec, exe_module_sp,

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

[Lldb-commits] [lldb] [LLDB] Fix remote executables load and caching (PR #98623)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Vladislav Dzhidzhoev (dzhidzhoev)


Changes

Seemingly, #96256 removed the only call to
Platform::GetCachedExecutable, which broke the resolution of executable modules 
in the remote debugging mode
(https://github.com/llvm/llvm-project/issues/97410).

This commit fixes that.

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


2 Files Affected:

- (modified) lldb/source/Target/Platform.cpp (+1-1) 
- (modified) lldb/source/Target/RemoteAwarePlatform.cpp (+3) 


``diff
diff --git a/lldb/source/Target/Platform.cpp b/lldb/source/Target/Platform.cpp
index bb90c377d86b2..1900898db6494 100644
--- a/lldb/source/Target/Platform.cpp
+++ b/lldb/source/Target/Platform.cpp
@@ -1446,7 +1446,7 @@ Platform::GetCachedExecutable(ModuleSpec &module_spec,
   Status error = GetRemoteSharedModule(
   module_spec, nullptr, module_sp,
   [&](const ModuleSpec &spec) {
-return ResolveExecutable(spec, module_sp, module_search_paths_ptr);
+return Platform::ResolveExecutable(spec, module_sp, 
module_search_paths_ptr);
   },
   nullptr);
   if (error.Success()) {
diff --git a/lldb/source/Target/RemoteAwarePlatform.cpp 
b/lldb/source/Target/RemoteAwarePlatform.cpp
index 5fc2d63876b92..f3aafb87149c8 100644
--- a/lldb/source/Target/RemoteAwarePlatform.cpp
+++ b/lldb/source/Target/RemoteAwarePlatform.cpp
@@ -46,6 +46,9 @@ Status RemoteAwarePlatform::ResolveExecutable(
 
 if (!FileSystem::Instance().Exists(resolved_file_spec))
   FileSystem::Instance().ResolveExecutableLocation(resolved_file_spec);
+  } else if (m_remote_platform_sp) {
+return GetCachedExecutable(resolved_module_spec, exe_module_sp,
+module_search_paths_ptr);
   }
 
   return Platform::ResolveExecutable(resolved_module_spec, exe_module_sp,

``




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

[Lldb-commits] [lldb] [LLDB] Fix Android debugging (PR #98581)

[Vladislav Dzhidzhoev via lldb-commits]

dzhidzhoev wrote:

Could you take a peak if this solves your issue?
https://github.com/llvm/llvm-project/pull/98623

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

[Lldb-commits] [lldb] [LLDB] Fix remote executables load and caching (PR #98623)

[via lldb-commits]

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff c471d3650aa3c6c1ddab64c029b7b89b12d18938 
3f8a4164ddc06a3faffe61d95e5023d367d757f0 --extensions cpp -- 
lldb/source/Target/Platform.cpp lldb/source/Target/RemoteAwarePlatform.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Target/Platform.cpp b/lldb/source/Target/Platform.cpp
index 1900898db6..ab80fe4c8b 100644
--- a/lldb/source/Target/Platform.cpp
+++ b/lldb/source/Target/Platform.cpp
@@ -1446,7 +1446,8 @@ Platform::GetCachedExecutable(ModuleSpec &module_spec,
   Status error = GetRemoteSharedModule(
   module_spec, nullptr, module_sp,
   [&](const ModuleSpec &spec) {
-return Platform::ResolveExecutable(spec, module_sp, 
module_search_paths_ptr);
+return Platform::ResolveExecutable(spec, module_sp,
+   module_search_paths_ptr);
   },
   nullptr);
   if (error.Success()) {
diff --git a/lldb/source/Target/RemoteAwarePlatform.cpp 
b/lldb/source/Target/RemoteAwarePlatform.cpp
index f3aafb8714..cac738ea67 100644
--- a/lldb/source/Target/RemoteAwarePlatform.cpp
+++ b/lldb/source/Target/RemoteAwarePlatform.cpp
@@ -48,7 +48,7 @@ Status RemoteAwarePlatform::ResolveExecutable(
   FileSystem::Instance().ResolveExecutableLocation(resolved_file_spec);
   } else if (m_remote_platform_sp) {
 return GetCachedExecutable(resolved_module_spec, exe_module_sp,
-module_search_paths_ptr);
+   module_search_paths_ptr);
   }
 
   return Platform::ResolveExecutable(resolved_module_spec, exe_module_sp,

``




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

[Lldb-commits] [lldb] [LLDB] Fix remote executables load and caching (PR #98623)

[Vladislav Dzhidzhoev via lldb-commits]

https://github.com/dzhidzhoev updated 
https://github.com/llvm/llvm-project/pull/98623

>From b86d6f9ea1b54cbd5ac54b8aae8971862c6536b5 Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev 
Date: Thu, 11 Jul 2024 17:53:08 +0200
Subject: [PATCH] [LLDB] Fix remote executables load and caching

Seemingly, #96256 removed the only call to
Platform::GetCachedExecutable, which broke the resolution of executable
modules in the remote debugging mode
(https://github.com/llvm/llvm-project/issues/97410).

This commit fixes that.
---
 lldb/source/Target/Platform.cpp| 3 ++-
 lldb/source/Target/RemoteAwarePlatform.cpp | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/lldb/source/Target/Platform.cpp b/lldb/source/Target/Platform.cpp
index bb90c377d86b2..ab80fe4c8ba24 100644
--- a/lldb/source/Target/Platform.cpp
+++ b/lldb/source/Target/Platform.cpp
@@ -1446,7 +1446,8 @@ Platform::GetCachedExecutable(ModuleSpec &module_spec,
   Status error = GetRemoteSharedModule(
   module_spec, nullptr, module_sp,
   [&](const ModuleSpec &spec) {
-return ResolveExecutable(spec, module_sp, module_search_paths_ptr);
+return Platform::ResolveExecutable(spec, module_sp,
+   module_search_paths_ptr);
   },
   nullptr);
   if (error.Success()) {
diff --git a/lldb/source/Target/RemoteAwarePlatform.cpp 
b/lldb/source/Target/RemoteAwarePlatform.cpp
index 5fc2d63876b92..cac738ea67b4c 100644
--- a/lldb/source/Target/RemoteAwarePlatform.cpp
+++ b/lldb/source/Target/RemoteAwarePlatform.cpp
@@ -46,6 +46,9 @@ Status RemoteAwarePlatform::ResolveExecutable(
 
 if (!FileSystem::Instance().Exists(resolved_file_spec))
   FileSystem::Instance().ResolveExecutableLocation(resolved_file_spec);
+  } else if (m_remote_platform_sp) {
+return GetCachedExecutable(resolved_module_spec, exe_module_sp,
+   module_search_paths_ptr);
   }
 
   return Platform::ResolveExecutable(resolved_module_spec, exe_module_sp,

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

[Lldb-commits] [lldb] Support single stopped event in lldb-dap (PR #98568)

[via lldb-commits]

jimingham wrote:

What is going to happen in this mode if I have 5 threads stop at breakpoints, 
and each have a breakpoint command that prints "I hit breakpoint X on thread 
Y".  I'll see that in the console for all the threads that hit breakpoints.  
But what will I see when I look at the stop reasons for all those other threads 
I know must have stopped?

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

[Lldb-commits] [lldb] Support single stopped event in lldb-dap (PR #98568)

[via lldb-commits]

jeffreytan81 wrote:

> What is going to happen in this mode if I have 5 threads stop at breakpoints, 
> and each have a breakpoint command that prints "I hit breakpoint X on thread 
> Y". I'll see that in the console for all the threads that hit breakpoints. 
> But what will I see when I look at the stop reasons for all those other 
> threads I know must have stopped?

It depends on the IDE client and protocol. For example, "thread list" command 
will still list stop reason for each thread and the VSCode DAP protocol 
"threads" request can return "stop reason" for each thread so that when user 
switch UI to that thread, the stop reason is shown to the end user in VSCode UI.



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

[Lldb-commits] [lldb] Support single stopped event in lldb-dap (PR #98568)

[via lldb-commits]

https://github.com/jeffreytan81 updated 
https://github.com/llvm/llvm-project/pull/98568

>From 13af0ff31688ca0a23f1fec65ca2d5797b65e31f Mon Sep 17 00:00:00 2001
From: jeffreytan81 
Date: Thu, 11 Jul 2024 17:24:41 -0700
Subject: [PATCH 1/3] Support single stopped event in lldb-dap

---
 .../test/tools/lldb-dap/dap_server.py | 21 -
 .../test/tools/lldb-dap/lldbdap_testcase.py   |  5 +-
 .../API/tools/lldb-dap/stop-events/Makefile   |  4 +
 .../stop-events/TestDAP_stopEvents.py | 92 +++
 .../API/tools/lldb-dap/stop-events/main.cpp   | 74 +++
 lldb/tools/lldb-dap/DAP.cpp   |  2 +-
 lldb/tools/lldb-dap/DAP.h |  3 +
 lldb/tools/lldb-dap/lldb-dap.cpp  | 47 +-
 8 files changed, 240 insertions(+), 8 deletions(-)
 create mode 100644 lldb/test/API/tools/lldb-dap/stop-events/Makefile
 create mode 100644 
lldb/test/API/tools/lldb-dap/stop-events/TestDAP_stopEvents.py
 create mode 100644 lldb/test/API/tools/lldb-dap/stop-events/main.cpp

diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index a324af57b61df..84e6fe82a06dc 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -125,6 +125,8 @@ def __init__(self, recv, send, init_commands, 
log_file=None):
 self.initialize_body = None
 self.thread_stop_reasons = {}
 self.breakpoint_events = []
+self.thread_events_body = []
+self.stopped_events = []
 self.progress_events = []
 self.reverse_requests = []
 self.sequence = 1
@@ -227,6 +229,8 @@ def handle_recv_packet(self, packet):
 # When a new process is attached or launched, remember the
 # details that are available in the body of the event
 self.process_event_body = body
+elif event == "continued":
+self.stopped_events = []
 elif event == "stopped":
 # Each thread that stops with a reason will send a
 # 'stopped' event. We need to remember the thread stop
@@ -234,6 +238,7 @@ def handle_recv_packet(self, packet):
 # that information.
 self._process_stopped()
 tid = body["threadId"]
+self.stopped_events.append(packet)
 self.thread_stop_reasons[tid] = body
 elif event == "breakpoint":
 # Breakpoint events come in when a breakpoint has locations
@@ -242,6 +247,10 @@ def handle_recv_packet(self, packet):
 self.breakpoint_events.append(packet)
 # no need to add 'breakpoint' event packets to our packets list
 return keepGoing
+elif event == "thread":
+self.thread_events_body.append(body)
+# no need to add 'thread' event packets to our packets list
+return keepGoing
 elif event.startswith("progress"):
 # Progress events come in as 'progressStart', 'progressUpdate',
 # and 'progressEnd' events. Keep these around in case test
@@ -418,6 +427,15 @@ def get_threads(self):
 self.request_threads()
 return self.threads
 
+def get_thread_events(self, reason=None):
+if reason == None:
+return self.thread_events_body
+else:
+return [body for body in self.thread_events_body if body["reason"] 
== reason]
+
+def get_stopped_events(self):
+return self.stopped_events
+
 def get_thread_id(self, threadIndex=0):
 """Utility function to get the first thread ID in the thread list.
 If the thread list is empty, then fetch the threads.
@@ -707,7 +725,7 @@ def request_evaluate(self, expression, frameIndex=0, 
threadId=None, context=None
 }
 return self.send_recv(command_dict)
 
-def request_initialize(self, sourceInitFile):
+def request_initialize(self, sourceInitFile, singleStoppedEvent=False):
 command_dict = {
 "command": "initialize",
 "type": "request",
@@ -723,6 +741,7 @@ def request_initialize(self, sourceInitFile):
 "supportsVariableType": True,
 "supportsStartDebuggingRequest": True,
 "sourceInitFile": sourceInitFile,
+"singleStoppedEvent": singleStoppedEvent,
 },
 }
 response = self.send_recv(command_dict)
diff --git 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index a312a88ebd7e5..90ab2a8d4898a 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -350,6 +35

[Lldb-commits] [lldb] [LLDB] Fix remote executables load and caching (PR #98623)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

That was an oversight. Thanks for restoring this. LGTM. 

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

[Lldb-commits] [lldb] [LLDB] Fix remote executables load and caching (PR #98623)

[Jonas Devlieghere via lldb-commits]

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


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

[Lldb-commits] [lldb] [LLDB] Fix remote executables load and caching (PR #98623)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

CC @clayborg as this probably explains the Android debugging regression. 

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

[Lldb-commits] [lldb] Support single stopped event in lldb-dap (PR #98568)

[via lldb-commits]

jimingham wrote:

If I have a program with lots of threads - particularly if they are running in 
a small set of work functions - it's very common to have multiple breakpoint 
hits at the same time.  And if there are lots of threads, then in this mode I'm 
going to end up having to scroll down the list every time you stop to make sure 
I'm not missing any breakpoint hits on this stop.
I don't think this is a great solution to the UI problem, but since it's a mode 
you can turn on and off it falls in the you do you category.

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

[Lldb-commits] [lldb] [lldb] Allow fetching of RA register when above fault handler (PR #98566)

[Jason Molenda via lldb-commits]

jasonmolenda wrote:


> Testing this is in theory possible, tricky bit is guaranteeing a frameless 
> function. There is the naked attribute but it's not portable 
> https://godbolt.org/z/s9117Gr7a. Or you could write the function in an 
> assembly file, or define and call it inside an inline assembly block, inside 
> a normal C function. That function would branch to self waiting for SIGALRM 
> for example.
> 
> Maybe that has its own problems, I haven't tried it. Maybe it wouldn't 
> generate enough debug info for us to know that the assembly function was 
> there?

There's (I'd argue) three parts to the unwind system.  First is converting the 
different unwind info formats (eh_frame, debug_frame, compact unwind, arm idx, 
assembly instruciton scanning) into the intermediate representation of 
UnwindPlans.  Second is the unwind engine itself, which encodes rules about 
which type of unwind plan to use for a given stack frame, which registers can 
be passed up the stack, and rules about behavior on the 0th frame or above a 
fault handler/sigtramp.  And third are correctly fetching the register value 
for a row in an UnwindPlan (often, dereferencing memory offset from the 
Canonical Frame Address which is set in terms of another register most often) 
-- these often end up being dwarf expressions.

That middle bit, the unwind engine logic, is hard to test today without making 
hand-written assembly programs that set up specific unwind scenarios with 
metadata (.cfi directives) about what they've done.  Source level tests are at 
the mercy of compiler codegen and not stable, or requires capturing a corefile 
and object binary when the necessary conditions are achieved.

But here's the idea I had the other day.  With a scripted process, an 
ObjectFileJSON to create a fake binary with function start addresses, and a way 
to specify UnwindPlans for those functions, where all of the register rules 
would be "and the value of fp is " instead of "read stack memory to get the 
value of fp", I bet there's a way we could write unwind engine tests entirely 
in these terms.   And honest, the unwind engine method has a lot of very tricky 
corner cases and because it's not directly tested, it's easy to make mistakes - 
I am genuinely not thrilled about the state of it.  And without strong test 
infrastructure, it's going to be very intimidating to try to rewrite if anyone 
wanted to do that some day.

This is only "shower thoughts" level detail, but it's the first time I can see 
a testing strategy that I actually think could work well.

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

[Lldb-commits] [lldb] [lldb] Allow fetching of RA register when above fault handler (PR #98566)

[Jonas Devlieghere via lldb-commits]

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


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

[Lldb-commits] [lldb] Private process events were being delivered to the secondary listener (PR #98571)

[Alex Langford via lldb-commits]

@@ -443,11 +474,17 @@ def test_shadow_listener(self):
 # Put in a counter to make sure we don't spin forever if there is some
 # error in the logic.
 counter = 0
+run_wo_stop = False

bulbazord wrote:

Doesn't look like this is used? Maybe a holdover from a previous implementation?

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

[Lldb-commits] [lldb] Private process events were being delivered to the secondary listener (PR #98571)

[via lldb-commits]

jimingham wrote:

That was actually from a debugging session using the test.  I got rid of all 
the other evidence of that experiment in the test case, but missed this one.

Jim


> On Jul 12, 2024, at 10:34 AM, Alex Langford ***@***.***> wrote:
> 
> 
> @bulbazord commented on this pull request.
> 
> In lldb/test/API/python_api/event/TestEvents.py 
> :
> 
> > @@ -443,11 +474,17 @@ def test_shadow_listener(self):
>  # Put in a counter to make sure we don't spin forever if there is 
> some
>  # error in the logic.
>  counter = 0
> +run_wo_stop = False
> Doesn't look like this is used? Maybe a holdover from a previous 
> implementation?
> 
> —
> Reply to this email directly, view it on GitHub 
> ,
>  or unsubscribe 
> .
> You are receiving this because you authored the thread.
> 



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

[Lldb-commits] [lldb] Fix test assertions in TestDAP_stepInTargets.py (PR #96687)

[Kendal Harland via lldb-commits]

https://github.com/kendalharland updated 
https://github.com/llvm/llvm-project/pull/96687

>From 02f06f90a40cc7ed18a9744918acf4daf6212486 Mon Sep 17 00:00:00 2001
From: kendal 
Date: Mon, 24 Jun 2024 14:01:31 -0700
Subject: [PATCH 1/2] Fix test assertions in TestDAP_stepInTargets.py

---
 .../stepInTargets/TestDAP_stepInTargets.py| 24 +--
 .../API/tools/lldb-dap/stepInTargets/main.cpp |  6 ++---
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git 
a/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py 
b/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
index 6296f6554d07e..6670989a58fe8 100644
--- a/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
+++ b/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
@@ -55,14 +55,24 @@ def test_basic(self):
 self.assertEqual(len(step_in_targets), 3, "expect 3 step in targets")
 
 # Verify the target names are correct.
-self.assertEqual(step_in_targets[0]["label"], "bar()", "expect bar()")
-self.assertEqual(step_in_targets[1]["label"], "bar2()", "expect 
bar2()")
-self.assertEqual(
-step_in_targets[2]["label"], "foo(int, int)", "expect foo(int, 
int)"
-)
+# The order of funcA and funcB may change depending on the compiler 
ABI.
+funcA_target = None
+funcB_target = None
+for target in step_in_targets[0:2]:
+if "funcB" in target["label"]:
+funcB_target = target
+elif "funcA" in target["label"]:
+funcA_target = target
+else:
+self.fail(f"Unexpected step in target: {target}")
+
+self.assertIsNotNone(funcA_target, "expect funcA")
+self.assertIsNotNone(funcB_target, "expect funcB")
+self.assertIn("foo", step_in_targets[2]["label"], "expect foo")
 
-# Choose to step into second target and verify that we are in bar2()
+# Choose to step into second target and verify that we are in the 
second target,
+# be it funcA or funcB.
 self.stepIn(threadId=tid, targetId=step_in_targets[1]["id"], 
waitForStop=True)
 leaf_frame = self.dap_server.get_stackFrame()
 self.assertIsNotNone(leaf_frame, "expect a leaf frame")
-self.assertEqual(leaf_frame["name"], "bar2()")
+self.assertEqual(step_in_targets[1]["label"], leaf_frame["name"])
diff --git a/lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp 
b/lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp
index d3c3dbcc139ef..a48b79af0c760 100644
--- a/lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp
+++ b/lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp
@@ -1,11 +1,11 @@
 
 int foo(int val, int extra) { return val + extra; }
 
-int bar() { return 22; }
+int funcA() { return 22; }
 
-int bar2() { return 54; }
+int funcB() { return 54; }
 
 int main(int argc, char const *argv[]) {
-  foo(bar(), bar2()); // set breakpoint here
+  foo(funcA(), funcB()); // set breakpoint here
   return 0;
 }

>From 4934a0c86272d19202821b126cd7fa99f9b3307d Mon Sep 17 00:00:00 2001
From: kendal 
Date: Thu, 11 Jul 2024 11:52:03 -0700
Subject: [PATCH 2/2] Disable this test on all platforms with issue ID

---
 .../tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py  | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git 
a/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py 
b/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
index 6670989a58fe8..29bcf81dbb306 100644
--- a/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
+++ b/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
@@ -10,9 +10,10 @@
 
 
 class TestDAP_stepInTargets(lldbdap_testcase.DAPTestCaseBase):
-@skipIf(
-archs=no_match(["x86_64"])
-)  # InstructionControlFlowKind for ARM is not supported yet.
+@skipIf
+# InstructionControlFlowKind for ARM is not supported yet.
+# On x86_64 lldb-dap seems to ignore targetId when stepping into functions.
+# For more context, see https://github.com/llvm/llvm-project/issues/98509.
 def test_basic(self):
 """
 Tests the basic stepping in targets with directly calls.

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

[Lldb-commits] [lldb] Fix test assertions in TestDAP_stepInTargets.py (PR #96687)

[Kendal Harland via lldb-commits]

@@ -55,14 +55,23 @@ def test_basic(self):
 self.assertEqual(len(step_in_targets), 3, "expect 3 step in targets")
 
 # Verify the target names are correct.
-self.assertEqual(step_in_targets[0]["label"], "bar()", "expect bar()")
-self.assertEqual(step_in_targets[1]["label"], "bar2()", "expect 
bar2()")
-self.assertEqual(
-step_in_targets[2]["label"], "foo(int, int)", "expect foo(int, 
int)"
-)
+# The order of funcA and funcB may change depending on the compiler 
ABI.
+funcA_target = None
+funcB_target = None
+for target in step_in_targets[0:2]:
+if "funcB" in target["label"]:
+funcB_target = target
+elif "funcA" in target["label"]:
+funcA_target = target
+else:
+self.fail(f"Unexpected step in target: {target}")
+
+self.assertIsNotNone(funcA_target, "expect funcA")
+self.assertIsNotNone(funcB_target, "expect funcB")
+self.assertIn("foo", step_in_targets[2]["label"], "expect foo")
 
-# Choose to step into second target and verify that we are in bar2()
-self.stepIn(threadId=tid, targetId=step_in_targets[1]["id"], 
waitForStop=True)
+# Choose to step into second target and verify that we are in funcB()

kendalharland wrote:

I used @expectFailureAll rather than @skipIf, not realizing that the test 
_must_ fail if the latter is used. Updated in the latest commit. I'll need help 
landing as I don't have write access. Thank you all for the reviews!

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

[Lldb-commits] [lldb] Fix test assertions in TestDAP_stepInTargets.py (PR #96687)

[Kendal Harland via lldb-commits]

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

[Lldb-commits] [lldb] fd42417 - [lldb] Allow fetching of RA register when above fault handler (#98566)

[via lldb-commits]

Author: Jason Molenda
Date: 2024-07-12T10:44:18-07:00
New Revision: fd424179dcb3417fc0675f77d2bf06c750dd1c33

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

LOG: [lldb] Allow fetching of RA register when above fault handler (#98566)

In RegisterContextUnwind::SavedLocationForRegister we have special logic
for retrieving the Return Address register when it has the caller's
return address in it. An example would be the lr register on AArch64.

This register is never retrieved from a newer stack frame because it is
necessarly overwritten by a normal ABI function call. We allow frame 0
to provide its lr value to get the caller's return address, if it has
not been overwritten/saved to stack yet.

When a function is interrupted asynchronously by a POSIX signal
(sigtramp), or a fault handler more generally, the sigtramp/fault
handler has the entire register context available. In this situation, if
the fault handler is frame 0, the function that was async interrupted is
frame 1 and frame 2's return address may still be stored in lr. We need
to get the lr value for frame 1 from the fault handler in frame 0, to
get the return address for frame 2.

Without this fix, a frameless function that faults in a firmware
environment (that's where we've seen this issue most commonly) hasn't
spilled lr to stack, so we need to retrieve it from the fault handler's
full-register-context to find the caller of the frameless function that
faulted.

It's an unsurprising fix, all of the work was finding exactly where in
RegisterContextUnwind we were only allowing RA register use for frame 0,
when it should have been frame 0 or above a fault handler function.

rdar://127518945

Added: 


Modified: 
lldb/source/Target/RegisterContextUnwind.cpp

Removed: 




diff  --git a/lldb/source/Target/RegisterContextUnwind.cpp 
b/lldb/source/Target/RegisterContextUnwind.cpp
index 95e8abd763d53..bc8081f4e3b31 100644
--- a/lldb/source/Target/RegisterContextUnwind.cpp
+++ b/lldb/source/Target/RegisterContextUnwind.cpp
@@ -1401,7 +1401,7 @@ RegisterContextUnwind::SavedLocationForRegister(
   // it's still live in the actual register. Handle this specially.
 
   if (!have_unwindplan_regloc && return_address_reg.IsValid() &&
-  IsFrameZero()) {
+  BehavesLikeZerothFrame()) {
 if (return_address_reg.GetAsKind(eRegisterKindLLDB) !=
 LLDB_INVALID_REGNUM) {
   lldb_private::UnwindLLDB::RegisterLocation new_regloc;



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

[Lldb-commits] [lldb] [lldb] Allow fetching of RA register when above fault handler (PR #98566)

[Jason Molenda via lldb-commits]

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

[Lldb-commits] [lldb] [LLDB] Fix Android debugging (PR #98581)

[Kazuki Sakamoto via lldb-commits]

splhack wrote:

@dzhidzhoev Yes, https://github.com/llvm/llvm-project/pull/98623 fixed the 
ResolveExecutableModule issue, thank you!

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

[Lldb-commits] [lldb] [LLDB] Fix Android debugging (PR #98581)

[Kazuki Sakamoto via lldb-commits]

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

[Lldb-commits] [lldb] Private process events were being delivered to the secondary listener (PR #98571)

[Med Ismail Bennani via lldb-commits]

@@ -4248,7 +4248,21 @@ bool Process::ProcessEventData::ShouldStop(Event 
*event_ptr,
   return still_should_stop;
 }
 
+bool Process::ProcessEventData::ForwardEventToPendingListeners(Event 
*event_ptr) {
+  // STDIO and the other async event notifications should always be forwarded.
+  if (event_ptr->GetType() != Process::eBroadcastBitStateChanged)
+return true;
+
+  // For state changed events, if the update state is one, we are handling 
+  // this on the private state thread.  We should wait for the public event.
+  return m_update_state == 1;

medismailben wrote:

You say:
> // if the update state is one, we are handling this on the private state 
> thread. We should wait for the public event.

Yet:
> return m_update_state == 1;

I'm confused because this would mean we should forward events to pending 
listeners if the update state is one. 

I believe you meant:
```suggestion
  // For state changed events, if the update state is zero, we are handling 
  // this on the private state thread.  We should wait for the public event.
  return m_update_state == 1;
```

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

[Lldb-commits] [lldb] [LLDB] Fix remote executables load and caching (PR #98623)

[Kazuki Sakamoto via lldb-commits]

splhack wrote:

Verified this fixed the ResolveExecutableModule issue with Android target 
reported in https://github.com/llvm/llvm-project/pull/98581

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

[Lldb-commits] [lldb] Private process events were being delivered to the secondary listener (PR #98571)

[via lldb-commits]

https://github.com/jimingham updated 
https://github.com/llvm/llvm-project/pull/98571

>From fb563e516f3a73d508ea7b3a61df4f1bab2f33a6 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Thu, 11 Jul 2024 17:50:08 -0700
Subject: [PATCH 1/2] Fix a bug where process events were being delivered to
 the secondary Listener when the Private event queue was processing the event.
  That meant the secondary listener could get an event before the Primary
 listener did.  That in turn meant the state when the secondary listener got
 the event wasn't right yet.  Plus it meant that the secondary listener saw
 more events than the primary (not all events get forwarded from the private
 to the public Process listener.)

This bug became much more evident when we had a stop hook that did some work,
since that delays the Primary listener event delivery.  So I also added a 
stop-hook
to the test, and put a little delay in as well.
---
 lldb/include/lldb/Target/Process.h   |  3 ++
 lldb/include/lldb/Utility/Event.h| 13 +
 lldb/source/Target/Process.cpp   | 14 ++
 lldb/source/Utility/Event.cpp| 16 --
 lldb/test/API/python_api/event/TestEvents.py | 53 +---
 5 files changed, 86 insertions(+), 13 deletions(-)

diff --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index ceaf547ebddaf..37fc192b4469c 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -465,6 +465,9 @@ class Process : public 
std::enable_shared_from_this,
 static bool SetUpdateStateOnRemoval(Event *event_ptr);
 
   private:
+  
+bool ForwardEventToPendingListeners(Event *event_ptr) override;
+
 void SetUpdateStateOnRemoval() { m_update_state++; }
 
 void SetRestarted(bool new_value) { m_restarted = new_value; }
diff --git a/lldb/include/lldb/Utility/Event.h 
b/lldb/include/lldb/Utility/Event.h
index 461d711b8c3f2..5bea328d1faa9 100644
--- a/lldb/include/lldb/Utility/Event.h
+++ b/lldb/include/lldb/Utility/Event.h
@@ -48,6 +48,19 @@ class EventData {
   virtual void Dump(Stream *s) const;
 
 private:
+  /// This will be queried for a Broadcaster with a primary and some secondary
+  /// listeners after the primary listener pulled the event from the event 
queue
+  /// and ran its DoOnRemoval, right before the event is delivered.  
+  /// If it returns true, the event will also be forwarded to the secondary  
+  /// listeners, and if false, event propagation stops at the primary 
listener. 
+  /// Some broadcasters (particularly the Process broadcaster) fetch events on
+  /// a private Listener, and then forward the event to the Public Listeners
+  /// after some processing.  The Process broadcaster does not want to forward
+  /// to the secondary listeners at the private processing stage.
+  virtual bool ForwardEventToPendingListeners(Event *event_ptr) {
+return true;
+  }
+
   virtual void DoOnRemoval(Event *event_ptr) {}
 
   EventData(const EventData &) = delete;
diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 6fac0df1d7a66..a43684c999641 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -4248,7 +4248,21 @@ bool Process::ProcessEventData::ShouldStop(Event 
*event_ptr,
   return still_should_stop;
 }
 
+bool Process::ProcessEventData::ForwardEventToPendingListeners(Event 
*event_ptr) {
+  // STDIO and the other async event notifications should always be forwarded.
+  if (event_ptr->GetType() != Process::eBroadcastBitStateChanged)
+return true;
+
+  // For state changed events, if the update state is one, we are handling 
+  // this on the private state thread.  We should wait for the public event.
+  return m_update_state == 1;
+}
+
 void Process::ProcessEventData::DoOnRemoval(Event *event_ptr) {
+  // We only have work to do for state changed events:
+  if (event_ptr->GetType() != Process::eBroadcastBitStateChanged)
+return;
+
   ProcessSP process_sp(m_process_wp.lock());
 
   if (!process_sp)
diff --git a/lldb/source/Utility/Event.cpp b/lldb/source/Utility/Event.cpp
index 863167e56bce6..5f431c0a6dd89 100644
--- a/lldb/source/Utility/Event.cpp
+++ b/lldb/source/Utility/Event.cpp
@@ -83,14 +83,20 @@ void Event::Dump(Stream *s) const {
 void Event::DoOnRemoval() {
   std::lock_guard guard(m_listeners_mutex);
 
-  if (m_data_sp)
-m_data_sp->DoOnRemoval(this);
+  if (!m_data_sp)
+return;
+
+  m_data_sp->DoOnRemoval(this);
+
   // Now that the event has been handled by the primary event Listener, forward
   // it to the other Listeners.
+
   EventSP me_sp = shared_from_this();
-  for (auto listener_sp : m_pending_listeners)
-listener_sp->AddEvent(me_sp);
-  m_pending_listeners.clear();
+  if (m_data_sp->ForwardEventToPendingListeners(this)) {
+for (auto listener_sp : m_pending_listeners)
+  listener_sp->AddEvent(me_sp);
+m_pending_listeners.clear();
+  }
 }
 
 #pragma mark -
diff --git a/lldb/test/API/python_api

[Lldb-commits] [lldb] Private process events were being delivered to the secondary listener (PR #98571)

[via lldb-commits]

https://github.com/jimingham updated 
https://github.com/llvm/llvm-project/pull/98571

>From fb563e516f3a73d508ea7b3a61df4f1bab2f33a6 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Thu, 11 Jul 2024 17:50:08 -0700
Subject: [PATCH 1/3] Fix a bug where process events were being delivered to
 the secondary Listener when the Private event queue was processing the event.
  That meant the secondary listener could get an event before the Primary
 listener did.  That in turn meant the state when the secondary listener got
 the event wasn't right yet.  Plus it meant that the secondary listener saw
 more events than the primary (not all events get forwarded from the private
 to the public Process listener.)

This bug became much more evident when we had a stop hook that did some work,
since that delays the Primary listener event delivery.  So I also added a 
stop-hook
to the test, and put a little delay in as well.
---
 lldb/include/lldb/Target/Process.h   |  3 ++
 lldb/include/lldb/Utility/Event.h| 13 +
 lldb/source/Target/Process.cpp   | 14 ++
 lldb/source/Utility/Event.cpp| 16 --
 lldb/test/API/python_api/event/TestEvents.py | 53 +---
 5 files changed, 86 insertions(+), 13 deletions(-)

diff --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index ceaf547ebddaf..37fc192b4469c 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -465,6 +465,9 @@ class Process : public 
std::enable_shared_from_this,
 static bool SetUpdateStateOnRemoval(Event *event_ptr);
 
   private:
+  
+bool ForwardEventToPendingListeners(Event *event_ptr) override;
+
 void SetUpdateStateOnRemoval() { m_update_state++; }
 
 void SetRestarted(bool new_value) { m_restarted = new_value; }
diff --git a/lldb/include/lldb/Utility/Event.h 
b/lldb/include/lldb/Utility/Event.h
index 461d711b8c3f2..5bea328d1faa9 100644
--- a/lldb/include/lldb/Utility/Event.h
+++ b/lldb/include/lldb/Utility/Event.h
@@ -48,6 +48,19 @@ class EventData {
   virtual void Dump(Stream *s) const;
 
 private:
+  /// This will be queried for a Broadcaster with a primary and some secondary
+  /// listeners after the primary listener pulled the event from the event 
queue
+  /// and ran its DoOnRemoval, right before the event is delivered.  
+  /// If it returns true, the event will also be forwarded to the secondary  
+  /// listeners, and if false, event propagation stops at the primary 
listener. 
+  /// Some broadcasters (particularly the Process broadcaster) fetch events on
+  /// a private Listener, and then forward the event to the Public Listeners
+  /// after some processing.  The Process broadcaster does not want to forward
+  /// to the secondary listeners at the private processing stage.
+  virtual bool ForwardEventToPendingListeners(Event *event_ptr) {
+return true;
+  }
+
   virtual void DoOnRemoval(Event *event_ptr) {}
 
   EventData(const EventData &) = delete;
diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 6fac0df1d7a66..a43684c999641 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -4248,7 +4248,21 @@ bool Process::ProcessEventData::ShouldStop(Event 
*event_ptr,
   return still_should_stop;
 }
 
+bool Process::ProcessEventData::ForwardEventToPendingListeners(Event 
*event_ptr) {
+  // STDIO and the other async event notifications should always be forwarded.
+  if (event_ptr->GetType() != Process::eBroadcastBitStateChanged)
+return true;
+
+  // For state changed events, if the update state is one, we are handling 
+  // this on the private state thread.  We should wait for the public event.
+  return m_update_state == 1;
+}
+
 void Process::ProcessEventData::DoOnRemoval(Event *event_ptr) {
+  // We only have work to do for state changed events:
+  if (event_ptr->GetType() != Process::eBroadcastBitStateChanged)
+return;
+
   ProcessSP process_sp(m_process_wp.lock());
 
   if (!process_sp)
diff --git a/lldb/source/Utility/Event.cpp b/lldb/source/Utility/Event.cpp
index 863167e56bce6..5f431c0a6dd89 100644
--- a/lldb/source/Utility/Event.cpp
+++ b/lldb/source/Utility/Event.cpp
@@ -83,14 +83,20 @@ void Event::Dump(Stream *s) const {
 void Event::DoOnRemoval() {
   std::lock_guard guard(m_listeners_mutex);
 
-  if (m_data_sp)
-m_data_sp->DoOnRemoval(this);
+  if (!m_data_sp)
+return;
+
+  m_data_sp->DoOnRemoval(this);
+
   // Now that the event has been handled by the primary event Listener, forward
   // it to the other Listeners.
+
   EventSP me_sp = shared_from_this();
-  for (auto listener_sp : m_pending_listeners)
-listener_sp->AddEvent(me_sp);
-  m_pending_listeners.clear();
+  if (m_data_sp->ForwardEventToPendingListeners(this)) {
+for (auto listener_sp : m_pending_listeners)
+  listener_sp->AddEvent(me_sp);
+m_pending_listeners.clear();
+  }
 }
 
 #pragma mark -
diff --git a/lldb/test/API/python_api

[Lldb-commits] [lldb] [LLDB] Fix remote executables load and caching (PR #98623)

[Kazuki Sakamoto via lldb-commits]

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


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

[Lldb-commits] [lldb] Private process events were being delivered to the secondary listener (PR #98571)

[via lldb-commits]

@@ -4248,7 +4248,21 @@ bool Process::ProcessEventData::ShouldStop(Event 
*event_ptr,
   return still_should_stop;
 }
 
+bool Process::ProcessEventData::ForwardEventToPendingListeners(Event 
*event_ptr) {
+  // STDIO and the other async event notifications should always be forwarded.
+  if (event_ptr->GetType() != Process::eBroadcastBitStateChanged)
+return true;
+
+  // For state changed events, if the update state is one, we are handling 
+  // this on the private state thread.  We should wait for the public event.
+  return m_update_state == 1;

jimingham wrote:

Yup, just wrote the wrong thing in the comment.

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -377,6 +380,26 @@ class Thread : public std::enable_shared_from_this,
 
   virtual void SetQueueLibdispatchQueueAddress(lldb::addr_t dispatch_queue_t) 
{}
 
+  /// When a thread stops at an enabled BreakpointSite that has not exectued,

jimingham wrote:

exectued -> executed

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -377,6 +380,26 @@ class Thread : public std::enable_shared_from_this,
 
   virtual void SetQueueLibdispatchQueueAddress(lldb::addr_t dispatch_queue_t) 
{}
 
+  /// When a thread stops at an enabled BreakpointSite that has not exectued,
+  /// the Process plugin should call SetThreadStoppedAtUnexecutedBP(pc).
+  /// If that BreakpointSite was actually triggered (the instruction was
+  /// executed, for a software breakpoint), regardless of wheether the

jimingham wrote:

wheether -> whether 

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

[Lldb-commits] [lldb] Private process events were being delivered to the secondary listener (PR #98571)

[Med Ismail Bennani via lldb-commits]

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

LGTM

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -377,6 +380,26 @@ class Thread : public std::enable_shared_from_this,
 
   virtual void SetQueueLibdispatchQueueAddress(lldb::addr_t dispatch_queue_t) 
{}
 
+  /// When a thread stops at an enabled BreakpointSite that has not exectued,
+  /// the Process plugin should call SetThreadStoppedAtUnexecutedBP(pc).
+  /// If that BreakpointSite was actually triggered (the instruction was
+  /// executed, for a software breakpoint), regardless of wheether the
+  /// breakpoint is valid for this thread, SetThreadHitBreakpointSite()
+  /// should be called to clear that state.

jimingham wrote:

"to clear that state" is confusing.  A thread could stop because it executed 
the breakpoint trap without ever having stopped "with the PC at the unexecuted 
trap".  That's actually the more common case.  So you won't be clearing that 
state usually.  Maybe "to clear that state" -> "to record that fact".

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -128,6 +128,9 @@ class Thread : public std::enable_shared_from_this,
 register_backup_sp; // You need to restore the registers, of course...
 uint32_t current_inlined_depth;
 lldb::addr_t current_inlined_pc;
+lldb::addr_t stopped_at_unexecuted_bp; // Set to the address of a 
breakpoint

jimingham wrote:

This is the stored version of the Thread ivar with roughly the same name.  It's 
better documented there, maybe here you can just refer to that ivar for docs?

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -1311,6 +1334,16 @@ class Thread : public 
std::enable_shared_from_this,
   bool m_should_run_before_public_stop;  // If this thread has "stop others" 
  // private work to do, then it will
  // set this.
+  lldb::addr_t
+  m_stopped_at_unexecuted_bp; // When the thread stops at a
+  // breakpoint instruction/BreakpointSite
+  // but has not yet hit/exectued it,

jimingham wrote:

executed

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

[Lldb-commits] [lldb] Support single stopped event in lldb-dap (PR #98568)

[via lldb-commits]

jeffreytan81 wrote:

> If I have a program with lots of threads - particularly if they are running 
> in a small set of work functions - it's very common to have multiple 
> breakpoint hits at the same time. And in this mode I'm going to end up having 
> to scroll down the list - which if I have lots of threads will involve some 
> actually scrolling - every time I stop in order to make sure I'm not missing 
> any breakpoint hits I wanted to look at. I don't think this is a great 
> solution to the UI problem, but since it's a mode you can turn on and off it 
> falls in the you do you category.

Thanks for sharing the thoughts. I see your concern. However, this feature has 
been explicitly asked by our internal customers because, without this feature, 
VSCode is showing multiple yellow lines in VSCode editor while stopping which 
makes it almost unusable for them. (I wish I can show you the screenshot). This 
feature has actually been landed as an internal patch and used by them for a 
while.

I have done some more intensive user study about the experience in Xcode and 
Windows Visual Studio. Xcode always sent all stopped events, but putting the 
focused/current thread with different color (green for focused thread, yellow 
for non-current threads) so it is better than VSCode (which does not show 
different color for current vs background thread's stopped events) so stopped 
line is yellow. Visual Studio never sent multiple stopped events, and only one 
public stop is sent. I am not sure if it is ensured by Windows kernel or 
debugger itself.

Ideally, we would like the combination of both world -- default showing one 
stopped event, but providing a UI hint to toggle into Xcode experience by 
showing all stopped threads in editor. And we also talk about extend VSCode UI 
to ad an option "only show threads with stop reasons". 

This is just first step to reduce the major concern for our customers.


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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -633,171 +613,142 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
 }
 break;
 
+  // [exc_type, exc_code, exc_sub_code, exc_sub_sub_code]
+  //
+  // Instruction step:
+  //   [6, 1, 0]
+  //   Intel KDP [6, 3, ??]
+  //   armv7 [6, 0x102, ]  Same as software breakpoint!
+  //
+  // Software breakpoint:
+  //   x86 [6, 2, 0]
+  //   Intel KDP [6, 2, ]
+  //   arm64 [6, 1, ]
+  //   armv7 [6, 0x102, ]  Same as instruction step!
+  //
+  // Hardware breakpoint:
+  //   x86 [6, 1, , 0]
+  //   x86/Rosetta not implemented, see software breakpoint
+  //   arm64 [6, 1, ]
+  //   armv7 not implemented, see software breakpoint
+  //
+  // Hardware watchpoint:
+  //   x86 [6, 1, , 0] (both Intel hw and Rosetta)
+  //   arm64 [6, 0x102, , 0]
+  //   armv7 [6, 0x102, , 0]
+  //
+  // arm64 BRK instruction (imm arg not reflected in the ME)
+  //   [ 6, 1, ]
+  //
+  // In order of codes mach exceptions:
+  //   [6, 1, 0] - instruction step
+  //   [6, 1, ] - hardware breakpoint or watchpoint
+  //
+  //   [6, 2, 0] - software breakpoint
+  //   [6, 2, ] - software breakpoint
+  //
+  //   [6, 3] - instruction step
+  //
+  //   [6, 0x102, ] armv7 instruction step
+  //   [6, 0x102, ] armv7 software breakpoint
+  //   [6, 0x102, , 0] arm64/armv7 watchpoint
   case 6: // EXC_BREAKPOINT
   {
-bool is_actual_breakpoint = false;
-bool is_trace_if_actual_breakpoint_missing = false;
-switch (cpu) {
-case llvm::Triple::x86:
-case llvm::Triple::x86_64:
-  if (exc_code == 1) // EXC_I386_SGL
-  {
-if (!exc_sub_code) {
-  // This looks like a plain trap.
-  // Have to check if there is a breakpoint here as well.  When you
-  // single-step onto a trap, the single step stops you not to trap.
-  // Since we also do that check below, let's just use that logic.
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-} else {
-  if (StopInfoSP stop_info =
-  GetStopInfoForHardwareBP(thread, target, exc_data_count,
-   exc_sub_code, exc_sub_sub_code))
-return stop_info;
-}
-  } else if (exc_code == 2 || // EXC_I386_BPT
- exc_code == 3)   // EXC_I386_BPTFLT
-  {
-// KDP returns EXC_I386_BPTFLT for trace breakpoints
-if (exc_code == 3)
-  is_trace_if_actual_breakpoint_missing = true;
-
-is_actual_breakpoint = true;
-if (!pc_already_adjusted)
-  pc_decrement = 1;
-  }
-  break;
-
-case llvm::Triple::arm:
-case llvm::Triple::thumb:
-  if (exc_code == 0x102) // EXC_ARM_DA_DEBUG
-  {
-// LWP_TODO: We need to find the WatchpointResource that matches
-// the address, and evaluate its Watchpoints.
-
-// It's a watchpoint, then, if the exc_sub_code indicates a
-// known/enabled data break address from our watchpoint list.
-lldb::WatchpointSP wp_sp;
-if (target)
-  wp_sp = target->GetWatchpointList().FindByAddress(
-  (lldb::addr_t)exc_sub_code);
-if (wp_sp && wp_sp->IsEnabled()) {
-  return StopInfo::CreateStopReasonWithWatchpointID(thread,
-wp_sp->GetID());
-} else {
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-}
-  } else if (exc_code == 1) // EXC_ARM_BREAKPOINT
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  } else if (exc_code == 0) // FIXME not EXC_ARM_BREAKPOINT but a kernel
-// is currently returning this so accept it
-// as indicating a breakpoint until the
-// kernel is fixed
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  }
-  break;
+bool stopped_by_hitting_breakpoint = false;
+bool stopped_by_completing_stepi = false;
+bool stopped_watchpoint = false;
+std::optional value;

jimingham wrote:

Is there a better name for this than "value" - that's pretty generic.

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

[Lldb-commits] [lldb] 73dad7a - [LLDB] Fix remote executables load and caching (#98623)

[via lldb-commits]

Author: Vladislav Dzhidzhoev
Date: 2024-07-12T20:43:08+02:00
New Revision: 73dad7a765226bd7ade98f85d050e80f411f6dad

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

LOG: [LLDB] Fix remote executables load and caching (#98623)

Seemingly, #96256 removed the only call to
Platform::GetCachedExecutable, which broke the resolution of executable
modules in the remote debugging mode
(https://github.com/llvm/llvm-project/issues/97410).

This commit fixes that.

Added: 


Modified: 
lldb/source/Target/Platform.cpp
lldb/source/Target/RemoteAwarePlatform.cpp

Removed: 




diff  --git a/lldb/source/Target/Platform.cpp b/lldb/source/Target/Platform.cpp
index bb90c377d86b2..ab80fe4c8ba24 100644
--- a/lldb/source/Target/Platform.cpp
+++ b/lldb/source/Target/Platform.cpp
@@ -1446,7 +1446,8 @@ Platform::GetCachedExecutable(ModuleSpec &module_spec,
   Status error = GetRemoteSharedModule(
   module_spec, nullptr, module_sp,
   [&](const ModuleSpec &spec) {
-return ResolveExecutable(spec, module_sp, module_search_paths_ptr);
+return Platform::ResolveExecutable(spec, module_sp,
+   module_search_paths_ptr);
   },
   nullptr);
   if (error.Success()) {

diff  --git a/lldb/source/Target/RemoteAwarePlatform.cpp 
b/lldb/source/Target/RemoteAwarePlatform.cpp
index 5fc2d63876b92..cac738ea67b4c 100644
--- a/lldb/source/Target/RemoteAwarePlatform.cpp
+++ b/lldb/source/Target/RemoteAwarePlatform.cpp
@@ -46,6 +46,9 @@ Status RemoteAwarePlatform::ResolveExecutable(
 
 if (!FileSystem::Instance().Exists(resolved_file_spec))
   FileSystem::Instance().ResolveExecutableLocation(resolved_file_spec);
+  } else if (m_remote_platform_sp) {
+return GetCachedExecutable(resolved_module_spec, exe_module_sp,
+   module_search_paths_ptr);
   }
 
   return Platform::ResolveExecutable(resolved_module_spec, exe_module_sp,



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

[Lldb-commits] [lldb] [LLDB] Fix remote executables load and caching (PR #98623)

[Vladislav Dzhidzhoev via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -633,171 +613,142 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
 }
 break;
 
+  // [exc_type, exc_code, exc_sub_code, exc_sub_sub_code]
+  //
+  // Instruction step:
+  //   [6, 1, 0]
+  //   Intel KDP [6, 3, ??]
+  //   armv7 [6, 0x102, ]  Same as software breakpoint!
+  //
+  // Software breakpoint:
+  //   x86 [6, 2, 0]
+  //   Intel KDP [6, 2, ]
+  //   arm64 [6, 1, ]
+  //   armv7 [6, 0x102, ]  Same as instruction step!
+  //
+  // Hardware breakpoint:
+  //   x86 [6, 1, , 0]
+  //   x86/Rosetta not implemented, see software breakpoint
+  //   arm64 [6, 1, ]
+  //   armv7 not implemented, see software breakpoint
+  //
+  // Hardware watchpoint:
+  //   x86 [6, 1, , 0] (both Intel hw and Rosetta)
+  //   arm64 [6, 0x102, , 0]
+  //   armv7 [6, 0x102, , 0]
+  //
+  // arm64 BRK instruction (imm arg not reflected in the ME)
+  //   [ 6, 1, ]
+  //
+  // In order of codes mach exceptions:
+  //   [6, 1, 0] - instruction step
+  //   [6, 1, ] - hardware breakpoint or watchpoint
+  //
+  //   [6, 2, 0] - software breakpoint
+  //   [6, 2, ] - software breakpoint
+  //
+  //   [6, 3] - instruction step
+  //
+  //   [6, 0x102, ] armv7 instruction step
+  //   [6, 0x102, ] armv7 software breakpoint
+  //   [6, 0x102, , 0] arm64/armv7 watchpoint
   case 6: // EXC_BREAKPOINT
   {
-bool is_actual_breakpoint = false;
-bool is_trace_if_actual_breakpoint_missing = false;
-switch (cpu) {
-case llvm::Triple::x86:
-case llvm::Triple::x86_64:
-  if (exc_code == 1) // EXC_I386_SGL
-  {
-if (!exc_sub_code) {
-  // This looks like a plain trap.
-  // Have to check if there is a breakpoint here as well.  When you
-  // single-step onto a trap, the single step stops you not to trap.
-  // Since we also do that check below, let's just use that logic.
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-} else {
-  if (StopInfoSP stop_info =
-  GetStopInfoForHardwareBP(thread, target, exc_data_count,
-   exc_sub_code, exc_sub_sub_code))
-return stop_info;
-}
-  } else if (exc_code == 2 || // EXC_I386_BPT
- exc_code == 3)   // EXC_I386_BPTFLT
-  {
-// KDP returns EXC_I386_BPTFLT for trace breakpoints
-if (exc_code == 3)
-  is_trace_if_actual_breakpoint_missing = true;
-
-is_actual_breakpoint = true;
-if (!pc_already_adjusted)
-  pc_decrement = 1;
-  }
-  break;
-
-case llvm::Triple::arm:
-case llvm::Triple::thumb:
-  if (exc_code == 0x102) // EXC_ARM_DA_DEBUG
-  {
-// LWP_TODO: We need to find the WatchpointResource that matches
-// the address, and evaluate its Watchpoints.
-
-// It's a watchpoint, then, if the exc_sub_code indicates a
-// known/enabled data break address from our watchpoint list.
-lldb::WatchpointSP wp_sp;
-if (target)
-  wp_sp = target->GetWatchpointList().FindByAddress(
-  (lldb::addr_t)exc_sub_code);
-if (wp_sp && wp_sp->IsEnabled()) {
-  return StopInfo::CreateStopReasonWithWatchpointID(thread,
-wp_sp->GetID());
-} else {
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-}
-  } else if (exc_code == 1) // EXC_ARM_BREAKPOINT
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  } else if (exc_code == 0) // FIXME not EXC_ARM_BREAKPOINT but a kernel
-// is currently returning this so accept it
-// as indicating a breakpoint until the
-// kernel is fixed
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  }
-  break;
+bool stopped_by_hitting_breakpoint = false;
+bool stopped_by_completing_stepi = false;
+bool stopped_watchpoint = false;
+std::optional value;
+
+// exc_code 1
+if (exc_code == 1 && exc_sub_code == 0)

jimingham wrote:

Despite our fear of indentation, since the two if's exhaust the exe_code == 1 
possibilities, this would be clearer as:

if (exc_code == 1) {
  if (exc_sub_code == 0) {
  } else {
  }
}
   

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

[Lldb-commits] [lldb] Reapply [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #98361)

[Zequan Wu via lldb-commits]

https://github.com/ZequanWu updated 
https://github.com/llvm/llvm-project/pull/98361

>From 37b6878b9125c314c75053f7d5b0ba520111e9a3 Mon Sep 17 00:00:00 2001
From: Zequan Wu 
Date: Tue, 9 Jul 2024 15:28:19 -0700
Subject: [PATCH 1/3] Reapply [lldb][DWARF] Delay struct/class/union definition
 DIE searching when parsing declaration DIEs.

---
 .../SymbolFile/DWARF/DWARFASTParserClang.cpp  | 279 --
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  |  67 +++--
 .../SymbolFile/DWARF/SymbolFileDWARF.h|  15 +-
 .../DWARF/SymbolFileDWARFDebugMap.h   |   9 +
 .../SymbolFile/DWARF/SymbolFileDWARFDwo.cpp   |   2 +-
 .../SymbolFile/DWARF/SymbolFileDWARFDwo.h |   3 +-
 .../SymbolFile/DWARF/UniqueDWARFASTType.cpp   | 117 
 .../SymbolFile/DWARF/UniqueDWARFASTType.h |  36 +--
 .../delayed-definition-die-searching.test |  36 +++
 .../x86/simple-template-names-context.cpp |   4 +-
 10 files changed, 301 insertions(+), 267 deletions(-)
 create mode 100644 
lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 8e297141f4e13..7b93f6941ddda 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -1603,41 +1603,74 @@ DWARFASTParserClang::GetCPlusPlusQualifiedName(const 
DWARFDIE &die) {
 
 TypeSP
 DWARFASTParserClang::ParseStructureLikeDIE(const SymbolContext &sc,
-   const DWARFDIE &decl_die,
+   const DWARFDIE &die,
ParsedDWARFTypeAttributes &attrs) {
   CompilerType clang_type;
-  const dw_tag_t tag = decl_die.Tag();
-  SymbolFileDWARF *dwarf = decl_die.GetDWARF();
-  LanguageType cu_language = SymbolFileDWARF::GetLanguage(*decl_die.GetCU());
+  const dw_tag_t tag = die.Tag();
+  SymbolFileDWARF *dwarf = die.GetDWARF();
+  LanguageType cu_language = SymbolFileDWARF::GetLanguage(*die.GetCU());
   Log *log = GetLog(DWARFLog::TypeCompletion | DWARFLog::Lookups);
 
-  // UniqueDWARFASTType is large, so don't create a local variables on the
-  // stack, put it on the heap. This function is often called recursively and
-  // clang isn't good at sharing the stack space for variables in different
-  // blocks.
-  auto unique_ast_entry_up = std::make_unique();
-
   ConstString unique_typename(attrs.name);
   Declaration unique_decl(attrs.decl);
+  uint64_t byte_size = attrs.byte_size.value_or(0);
+  if (attrs.byte_size && *attrs.byte_size == 0 && attrs.name &&
+  !die.HasChildren() && cu_language == eLanguageTypeObjC) {
+// Work around an issue with clang at the moment where forward
+// declarations for objective C classes are emitted as:
+//  DW_TAG_structure_type [2]
+//  DW_AT_name( "ForwardObjcClass" )
+//  DW_AT_byte_size( 0x00 )
+//  DW_AT_decl_file( "..." )
+//  DW_AT_decl_line( 1 )
+//
+// Note that there is no DW_AT_declaration and there are no children,
+// and the byte size is zero.
+attrs.is_forward_declaration = true;
+  }
 
   if (attrs.name) {
 if (Language::LanguageIsCPlusPlus(cu_language)) {
   // For C++, we rely solely upon the one definition rule that says
   // only one thing can exist at a given decl context. We ignore the
   // file and line that things are declared on.
-  std::string qualified_name = GetCPlusPlusQualifiedName(decl_die);
+  std::string qualified_name = GetCPlusPlusQualifiedName(die);
   if (!qualified_name.empty())
 unique_typename = ConstString(qualified_name);
   unique_decl.Clear();
 }
 
-if (dwarf->GetUniqueDWARFASTTypeMap().Find(
-unique_typename, decl_die, unique_decl,
-attrs.byte_size.value_or(-1), *unique_ast_entry_up)) {
-  if (TypeSP type_sp = unique_ast_entry_up->m_type_sp) {
+if (UniqueDWARFASTType *unique_ast_entry_type =
+dwarf->GetUniqueDWARFASTTypeMap().Find(
+unique_typename, die, unique_decl, byte_size,
+attrs.is_forward_declaration)) {
+  if (TypeSP type_sp = unique_ast_entry_type->m_type_sp) {
+dwarf->GetDIEToType()[die.GetDIE()] = type_sp.get();
 LinkDeclContextToDIE(
-GetCachedClangDeclContextForDIE(unique_ast_entry_up->m_die),
-decl_die);
+GetCachedClangDeclContextForDIE(unique_ast_entry_type->m_die), 
die);
+// If the DIE being parsed in this function is a definition and the
+// entry in the map is a declaration, then we need to update the entry
+// to point to the definition DIE.
+if (!attrs.is_forward_declaration &&
+unique_ast_entry_type->m_is_forward_declaration) {
+  unique_ast_entry_type->m_die = die;
+  unique_ast_entry_type->m_byte_size = byte_size;
+  un

[Lldb-commits] [lldb] Reapply [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #98361)

[Zequan Wu via lldb-commits]

@@ -824,6 +824,36 @@ DWARFASTParserClang::GetDIEClassTemplateParams(const 
DWARFDIE &die) {
   return {};
 }
 
+void DWARFASTParserClang::MappingDeclDIEToDefDIE(
+const lldb_private::plugin::dwarf::DWARFDIE &decl_die,
+const lldb_private::plugin::dwarf::DWARFDIE &def_die) {
+  LinkDeclContextToDIE(GetCachedClangDeclContextForDIE(decl_die), def_die);
+  SymbolFileDWARF *dwarf = def_die.GetDWARF();
+  ParsedDWARFTypeAttributes decl_attrs(decl_die);
+  ParsedDWARFTypeAttributes def_attrs(def_die);
+  ConstString unique_typename(decl_attrs.name);
+  Declaration decl_declaration(decl_attrs.decl);
+  if (Language::LanguageIsCPlusPlus(
+  SymbolFileDWARF::GetLanguage(*decl_die.GetCU( {
+std::string qualified_name = GetCPlusPlusQualifiedName(decl_die);
+if (!qualified_name.empty())
+  unique_typename = ConstString(qualified_name);
+decl_declaration.Clear();
+  }

ZequanWu wrote:

I don't see any equivalent code in here and ParseTypeFromDWARF.

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

[Lldb-commits] [lldb] Reapply [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #98361)

[Zequan Wu via lldb-commits]

@@ -824,6 +824,36 @@ DWARFASTParserClang::GetDIEClassTemplateParams(const 
DWARFDIE &die) {
   return {};
 }
 
+void DWARFASTParserClang::MappingDeclDIEToDefDIE(
+const lldb_private::plugin::dwarf::DWARFDIE &decl_die,
+const lldb_private::plugin::dwarf::DWARFDIE &def_die) {
+  LinkDeclContextToDIE(GetCachedClangDeclContextForDIE(decl_die), def_die);
+  SymbolFileDWARF *dwarf = def_die.GetDWARF();
+  ParsedDWARFTypeAttributes decl_attrs(decl_die);
+  ParsedDWARFTypeAttributes def_attrs(def_die);
+  ConstString unique_typename(decl_attrs.name);
+  Declaration decl_declaration(decl_attrs.decl);
+  if (Language::LanguageIsCPlusPlus(
+  SymbolFileDWARF::GetLanguage(*decl_die.GetCU( {
+std::string qualified_name = GetCPlusPlusQualifiedName(decl_die);
+if (!qualified_name.empty())
+  unique_typename = ConstString(qualified_name);
+decl_declaration.Clear();
+  }
+  if (UniqueDWARFASTType *unique_ast_entry_type =

ZequanWu wrote:

Yes, this should always be true. Added a log.

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

[Lldb-commits] [lldb] Reapply [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #98361)

[Zequan Wu via lldb-commits]

@@ -4,8 +4,8 @@
 
 // REQUIRES: lld
 
-// RUN: %clang --target=x86_64-pc-linux -c %s -o %t-a.o -g 
-gsimple-template-names -DFILE_A
-// RUN: %clang --target=x86_64-pc-linux -c %s -o %t-b.o -g 
-gsimple-template-names -DFILE_B

ZequanWu wrote:

Added another set of RUN for -fdebug-types-section

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

[Lldb-commits] [lldb] Reapply [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #98361)

[Zequan Wu via lldb-commits]

@@ -824,6 +824,36 @@ DWARFASTParserClang::GetDIEClassTemplateParams(const 
DWARFDIE &die) {
   return {};
 }
 
+void DWARFASTParserClang::MappingDeclDIEToDefDIE(

ZequanWu wrote:

Done.

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

[Lldb-commits] [lldb] Reapply [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #98361)

[Zequan Wu via lldb-commits]

@@ -1631,27 +1638,49 @@ bool SymbolFileDWARF::CompleteType(CompilerType 
&compiler_type) {
 return true;
   }
 
-  DWARFDIE dwarf_die = GetDIE(die_it->getSecond());
-  if (dwarf_die) {
-// Once we start resolving this type, remove it from the forward
-// declaration map in case anyone child members or other types require this
-// type to get resolved. The type will get resolved when all of the calls
-// to SymbolFileDWARF::ResolveClangOpaqueTypeDefinition are done.
-GetForwardDeclCompilerTypeToDIE().erase(die_it);
-
-Type *type = GetDIEToType().lookup(dwarf_die.GetDIE());
+  DWARFDIE decl_die = GetDIE(die_it->getSecond());
+  // Once we start resolving this type, remove it from the forward
+  // declaration map in case anyone's child members or other types require this
+  // type to get resolved.
+  GetForwardDeclCompilerTypeToDIE().erase(die_it);
+  DWARFDIE def_die = FindDefinitionDIE(decl_die);
+  if (!def_die) {
+SymbolFileDWARFDebugMap *debug_map_symfile = GetDebugMapSymfile();
+if (debug_map_symfile) {
+  // We weren't able to find a full declaration in this DWARF, see
+  // if we have a declaration anywhere else...
+  def_die = debug_map_symfile->FindDefinitionDIE(decl_die);
+}
+  }
+  if (!def_die) {
+// If we don't have definition DIE, CompleteTypeFromDWARF will forcefully
+// complete this type.
+def_die = decl_die;
+  }
 
-Log *log = GetLog(DWARFLog::DebugInfo | DWARFLog::TypeCompletion);
-if (log)
-  GetObjectFile()->GetModule()->LogMessageVerboseBacktrace(
-  log, "{0:x8}: {1} ({2}) '{3}' resolving forward declaration...",
-  dwarf_die.GetID(), DW_TAG_value_to_name(dwarf_die.Tag()),
-  dwarf_die.Tag(), type->GetName().AsCString());
-assert(compiler_type);
-if (DWARFASTParser *dwarf_ast = GetDWARFParser(*dwarf_die.GetCU()))
-  return dwarf_ast->CompleteTypeFromDWARF(dwarf_die, type, compiler_type);
+  DWARFASTParser *dwarf_ast = GetDWARFParser(*def_die.GetCU());
+  if (!dwarf_ast)
+return false;
+  Type *type = GetDIEToType().lookup(decl_die.GetDIE());
+  if (decl_die != def_die) {
+GetDIEToType()[def_die.GetDIE()] = type;
+// Need to update Type ID to refer to the definition DIE. because
+// it's used in ParseCXXMethod to determine if we need to copy cxx
+// method types from a declaration DIE to this definition DIE.
+type->SetID(def_die.GetID());
+if (DWARFASTParserClang *ast_parser =
+static_cast(dwarf_ast))

ZequanWu wrote:

Removed.

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

[Lldb-commits] [lldb] Reapply [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #98361)

[Zequan Wu via lldb-commits]

@@ -1603,41 +1633,76 @@ DWARFASTParserClang::GetCPlusPlusQualifiedName(const 
DWARFDIE &die) {
 
 TypeSP
 DWARFASTParserClang::ParseStructureLikeDIE(const SymbolContext &sc,
-   const DWARFDIE &decl_die,
+   const DWARFDIE &die,
ParsedDWARFTypeAttributes &attrs) {
   CompilerType clang_type;
-  const dw_tag_t tag = decl_die.Tag();
-  SymbolFileDWARF *dwarf = decl_die.GetDWARF();
-  LanguageType cu_language = SymbolFileDWARF::GetLanguage(*decl_die.GetCU());
+  const dw_tag_t tag = die.Tag();
+  SymbolFileDWARF *dwarf = die.GetDWARF();
+  LanguageType cu_language = SymbolFileDWARF::GetLanguage(*die.GetCU());
   Log *log = GetLog(DWARFLog::TypeCompletion | DWARFLog::Lookups);
 
-  // UniqueDWARFASTType is large, so don't create a local variables on the
-  // stack, put it on the heap. This function is often called recursively and
-  // clang isn't good at sharing the stack space for variables in different
-  // blocks.
-  auto unique_ast_entry_up = std::make_unique();
-
   ConstString unique_typename(attrs.name);
   Declaration unique_decl(attrs.decl);
+  uint64_t byte_size = attrs.byte_size.value_or(0);
+  if (attrs.byte_size && *attrs.byte_size == 0 && attrs.name &&
+  !die.HasChildren() && cu_language == eLanguageTypeObjC) {
+// Work around an issue with clang at the moment where forward
+// declarations for objective C classes are emitted as:
+//  DW_TAG_structure_type [2]
+//  DW_AT_name( "ForwardObjcClass" )
+//  DW_AT_byte_size( 0x00 )
+//  DW_AT_decl_file( "..." )
+//  DW_AT_decl_line( 1 )
+//
+// Note that there is no DW_AT_declaration and there are no children,
+// and the byte size is zero.
+attrs.is_forward_declaration = true;
+  }
 
   if (attrs.name) {
 if (Language::LanguageIsCPlusPlus(cu_language)) {
   // For C++, we rely solely upon the one definition rule that says
   // only one thing can exist at a given decl context. We ignore the
   // file and line that things are declared on.
-  std::string qualified_name = GetCPlusPlusQualifiedName(decl_die);
+  std::string qualified_name = GetCPlusPlusQualifiedName(die);
   if (!qualified_name.empty())
 unique_typename = ConstString(qualified_name);
   unique_decl.Clear();
 }
 
-if (dwarf->GetUniqueDWARFASTTypeMap().Find(
-unique_typename, decl_die, unique_decl,
-attrs.byte_size.value_or(-1), *unique_ast_entry_up)) {
-  if (TypeSP type_sp = unique_ast_entry_up->m_type_sp) {
+if (UniqueDWARFASTType *unique_ast_entry_type =
+dwarf->GetUniqueDWARFASTTypeMap().Find(
+unique_typename, die, unique_decl, byte_size,
+attrs.is_forward_declaration)) {
+  if (TypeSP type_sp = unique_ast_entry_type->m_type_sp) {
+dwarf->GetDIEToType()[die.GetDIE()] = type_sp.get();
 LinkDeclContextToDIE(
-GetCachedClangDeclContextForDIE(unique_ast_entry_up->m_die),
-decl_die);
+GetCachedClangDeclContextForDIE(unique_ast_entry_type->m_die), 
die);
+// If the DIE being parsed in this function is a definition and the
+// entry in the map is a declaration, then we need to update the entry
+// to point to the definition DIE.
+if (!attrs.is_forward_declaration &&
+unique_ast_entry_type->m_is_forward_declaration) {
+  unique_ast_entry_type->m_die = die;
+  if (byte_size)
+unique_ast_entry_type->m_byte_size = byte_size;
+  if (unique_decl.IsValid())
+unique_ast_entry_type->m_declaration = unique_decl;
+  unique_ast_entry_type->m_is_forward_declaration = false;
+  // Need to update Type ID to refer to the definition DIE. because
+  // it's used in ParseCXXMethod to determine if we need to copy cxx
+  // method types from a declaration DIE to this definition DIE.
+  type_sp->SetID(die.GetID());

ZequanWu wrote:

Done.

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -633,171 +613,142 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
 }
 break;
 
+  // [exc_type, exc_code, exc_sub_code, exc_sub_sub_code]
+  //
+  // Instruction step:
+  //   [6, 1, 0]
+  //   Intel KDP [6, 3, ??]
+  //   armv7 [6, 0x102, ]  Same as software breakpoint!
+  //
+  // Software breakpoint:
+  //   x86 [6, 2, 0]
+  //   Intel KDP [6, 2, ]
+  //   arm64 [6, 1, ]
+  //   armv7 [6, 0x102, ]  Same as instruction step!
+  //
+  // Hardware breakpoint:
+  //   x86 [6, 1, , 0]
+  //   x86/Rosetta not implemented, see software breakpoint
+  //   arm64 [6, 1, ]
+  //   armv7 not implemented, see software breakpoint
+  //
+  // Hardware watchpoint:
+  //   x86 [6, 1, , 0] (both Intel hw and Rosetta)
+  //   arm64 [6, 0x102, , 0]
+  //   armv7 [6, 0x102, , 0]
+  //
+  // arm64 BRK instruction (imm arg not reflected in the ME)
+  //   [ 6, 1, ]
+  //
+  // In order of codes mach exceptions:
+  //   [6, 1, 0] - instruction step
+  //   [6, 1, ] - hardware breakpoint or watchpoint
+  //
+  //   [6, 2, 0] - software breakpoint
+  //   [6, 2, ] - software breakpoint
+  //
+  //   [6, 3] - instruction step
+  //
+  //   [6, 0x102, ] armv7 instruction step
+  //   [6, 0x102, ] armv7 software breakpoint
+  //   [6, 0x102, , 0] arm64/armv7 watchpoint
   case 6: // EXC_BREAKPOINT
   {
-bool is_actual_breakpoint = false;
-bool is_trace_if_actual_breakpoint_missing = false;
-switch (cpu) {
-case llvm::Triple::x86:
-case llvm::Triple::x86_64:
-  if (exc_code == 1) // EXC_I386_SGL
-  {
-if (!exc_sub_code) {
-  // This looks like a plain trap.
-  // Have to check if there is a breakpoint here as well.  When you
-  // single-step onto a trap, the single step stops you not to trap.
-  // Since we also do that check below, let's just use that logic.
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-} else {
-  if (StopInfoSP stop_info =
-  GetStopInfoForHardwareBP(thread, target, exc_data_count,
-   exc_sub_code, exc_sub_sub_code))
-return stop_info;
-}
-  } else if (exc_code == 2 || // EXC_I386_BPT
- exc_code == 3)   // EXC_I386_BPTFLT
-  {
-// KDP returns EXC_I386_BPTFLT for trace breakpoints
-if (exc_code == 3)
-  is_trace_if_actual_breakpoint_missing = true;
-
-is_actual_breakpoint = true;
-if (!pc_already_adjusted)
-  pc_decrement = 1;
-  }
-  break;
-
-case llvm::Triple::arm:
-case llvm::Triple::thumb:
-  if (exc_code == 0x102) // EXC_ARM_DA_DEBUG
-  {
-// LWP_TODO: We need to find the WatchpointResource that matches
-// the address, and evaluate its Watchpoints.
-
-// It's a watchpoint, then, if the exc_sub_code indicates a
-// known/enabled data break address from our watchpoint list.
-lldb::WatchpointSP wp_sp;
-if (target)
-  wp_sp = target->GetWatchpointList().FindByAddress(
-  (lldb::addr_t)exc_sub_code);
-if (wp_sp && wp_sp->IsEnabled()) {
-  return StopInfo::CreateStopReasonWithWatchpointID(thread,
-wp_sp->GetID());
-} else {
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-}
-  } else if (exc_code == 1) // EXC_ARM_BREAKPOINT
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  } else if (exc_code == 0) // FIXME not EXC_ARM_BREAKPOINT but a kernel
-// is currently returning this so accept it
-// as indicating a breakpoint until the
-// kernel is fixed
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  }
-  break;
+bool stopped_by_hitting_breakpoint = false;
+bool stopped_by_completing_stepi = false;
+bool stopped_watchpoint = false;
+std::optional value;
+
+// exc_code 1
+if (exc_code == 1 && exc_sub_code == 0)
+  stopped_by_completing_stepi = true;
+if (exc_code == 1 && exc_sub_code != 0) {
+  stopped_by_hitting_breakpoint = true;

jimingham wrote:

On the face of it, it seems weird that you are asserting that this is both a 
"breakpoint" and a "watchpoint" hit.  Later on you'll tell the difference based 
on the exe_sub_code stored in value.  This would be easier to read if there 
were a comment explaining that.

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -633,171 +613,142 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
 }
 break;
 
+  // [exc_type, exc_code, exc_sub_code, exc_sub_sub_code]

jimingham wrote:

This table is great, but it deserves a line saying what it is.

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -633,171 +613,142 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
 }
 break;
 
+  // [exc_type, exc_code, exc_sub_code, exc_sub_sub_code]
+  //
+  // Instruction step:
+  //   [6, 1, 0]
+  //   Intel KDP [6, 3, ??]
+  //   armv7 [6, 0x102, ]  Same as software breakpoint!
+  //
+  // Software breakpoint:
+  //   x86 [6, 2, 0]
+  //   Intel KDP [6, 2, ]
+  //   arm64 [6, 1, ]
+  //   armv7 [6, 0x102, ]  Same as instruction step!
+  //
+  // Hardware breakpoint:
+  //   x86 [6, 1, , 0]
+  //   x86/Rosetta not implemented, see software breakpoint
+  //   arm64 [6, 1, ]
+  //   armv7 not implemented, see software breakpoint
+  //
+  // Hardware watchpoint:
+  //   x86 [6, 1, , 0] (both Intel hw and Rosetta)
+  //   arm64 [6, 0x102, , 0]
+  //   armv7 [6, 0x102, , 0]
+  //
+  // arm64 BRK instruction (imm arg not reflected in the ME)
+  //   [ 6, 1, ]
+  //
+  // In order of codes mach exceptions:
+  //   [6, 1, 0] - instruction step
+  //   [6, 1, ] - hardware breakpoint or watchpoint
+  //
+  //   [6, 2, 0] - software breakpoint
+  //   [6, 2, ] - software breakpoint
+  //
+  //   [6, 3] - instruction step
+  //
+  //   [6, 0x102, ] armv7 instruction step
+  //   [6, 0x102, ] armv7 software breakpoint
+  //   [6, 0x102, , 0] arm64/armv7 watchpoint
   case 6: // EXC_BREAKPOINT
   {
-bool is_actual_breakpoint = false;
-bool is_trace_if_actual_breakpoint_missing = false;
-switch (cpu) {
-case llvm::Triple::x86:
-case llvm::Triple::x86_64:
-  if (exc_code == 1) // EXC_I386_SGL
-  {
-if (!exc_sub_code) {
-  // This looks like a plain trap.
-  // Have to check if there is a breakpoint here as well.  When you
-  // single-step onto a trap, the single step stops you not to trap.
-  // Since we also do that check below, let's just use that logic.
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-} else {
-  if (StopInfoSP stop_info =
-  GetStopInfoForHardwareBP(thread, target, exc_data_count,
-   exc_sub_code, exc_sub_sub_code))
-return stop_info;
-}
-  } else if (exc_code == 2 || // EXC_I386_BPT
- exc_code == 3)   // EXC_I386_BPTFLT
-  {
-// KDP returns EXC_I386_BPTFLT for trace breakpoints
-if (exc_code == 3)
-  is_trace_if_actual_breakpoint_missing = true;
-
-is_actual_breakpoint = true;
-if (!pc_already_adjusted)
-  pc_decrement = 1;
-  }
-  break;
-
-case llvm::Triple::arm:
-case llvm::Triple::thumb:
-  if (exc_code == 0x102) // EXC_ARM_DA_DEBUG
-  {
-// LWP_TODO: We need to find the WatchpointResource that matches
-// the address, and evaluate its Watchpoints.
-
-// It's a watchpoint, then, if the exc_sub_code indicates a
-// known/enabled data break address from our watchpoint list.
-lldb::WatchpointSP wp_sp;
-if (target)
-  wp_sp = target->GetWatchpointList().FindByAddress(
-  (lldb::addr_t)exc_sub_code);
-if (wp_sp && wp_sp->IsEnabled()) {
-  return StopInfo::CreateStopReasonWithWatchpointID(thread,
-wp_sp->GetID());
-} else {
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-}
-  } else if (exc_code == 1) // EXC_ARM_BREAKPOINT
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  } else if (exc_code == 0) // FIXME not EXC_ARM_BREAKPOINT but a kernel
-// is currently returning this so accept it
-// as indicating a breakpoint until the
-// kernel is fixed
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  }
-  break;
+bool stopped_by_hitting_breakpoint = false;
+bool stopped_by_completing_stepi = false;
+bool stopped_watchpoint = false;
+std::optional value;
+
+// exc_code 1
+if (exc_code == 1 && exc_sub_code == 0)
+  stopped_by_completing_stepi = true;
+if (exc_code == 1 && exc_sub_code != 0) {
+  stopped_by_hitting_breakpoint = true;
+  stopped_watchpoint = true;
+  value = exc_sub_code;
+}
 
-case llvm::Triple::aarch64_32:
-case llvm::Triple::aarch64: {
-  // xnu describes three things with type EXC_BREAKPOINT:
-  //
-  //   exc_code 0x102 [EXC_ARM_DA_DEBUG], exc_sub_code addr-of-insn
-  //  Watchpoint access.  exc_sub_code is the address of the
-  //  instruction which trigged the watchpoint trap.
-  //  debugserver may add the watchpoint number that was triggered
-  //  in exc_sub_sub_code.
-  //
-  //   exc_code 1 [EXC_ARM_BREAKPOI

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -633,171 +613,142 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
 }
 break;
 
+  // [exc_type, exc_code, exc_sub_code, exc_sub_sub_code]
+  //
+  // Instruction step:
+  //   [6, 1, 0]
+  //   Intel KDP [6, 3, ??]
+  //   armv7 [6, 0x102, ]  Same as software breakpoint!
+  //
+  // Software breakpoint:
+  //   x86 [6, 2, 0]
+  //   Intel KDP [6, 2, ]
+  //   arm64 [6, 1, ]
+  //   armv7 [6, 0x102, ]  Same as instruction step!
+  //
+  // Hardware breakpoint:
+  //   x86 [6, 1, , 0]
+  //   x86/Rosetta not implemented, see software breakpoint
+  //   arm64 [6, 1, ]
+  //   armv7 not implemented, see software breakpoint
+  //
+  // Hardware watchpoint:
+  //   x86 [6, 1, , 0] (both Intel hw and Rosetta)
+  //   arm64 [6, 0x102, , 0]
+  //   armv7 [6, 0x102, , 0]
+  //
+  // arm64 BRK instruction (imm arg not reflected in the ME)
+  //   [ 6, 1, ]
+  //
+  // In order of codes mach exceptions:
+  //   [6, 1, 0] - instruction step
+  //   [6, 1, ] - hardware breakpoint or watchpoint
+  //
+  //   [6, 2, 0] - software breakpoint
+  //   [6, 2, ] - software breakpoint
+  //
+  //   [6, 3] - instruction step
+  //
+  //   [6, 0x102, ] armv7 instruction step
+  //   [6, 0x102, ] armv7 software breakpoint
+  //   [6, 0x102, , 0] arm64/armv7 watchpoint
   case 6: // EXC_BREAKPOINT
   {
-bool is_actual_breakpoint = false;
-bool is_trace_if_actual_breakpoint_missing = false;
-switch (cpu) {
-case llvm::Triple::x86:
-case llvm::Triple::x86_64:
-  if (exc_code == 1) // EXC_I386_SGL
-  {
-if (!exc_sub_code) {
-  // This looks like a plain trap.
-  // Have to check if there is a breakpoint here as well.  When you
-  // single-step onto a trap, the single step stops you not to trap.
-  // Since we also do that check below, let's just use that logic.
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-} else {
-  if (StopInfoSP stop_info =
-  GetStopInfoForHardwareBP(thread, target, exc_data_count,
-   exc_sub_code, exc_sub_sub_code))
-return stop_info;
-}
-  } else if (exc_code == 2 || // EXC_I386_BPT
- exc_code == 3)   // EXC_I386_BPTFLT
-  {
-// KDP returns EXC_I386_BPTFLT for trace breakpoints
-if (exc_code == 3)
-  is_trace_if_actual_breakpoint_missing = true;
-
-is_actual_breakpoint = true;
-if (!pc_already_adjusted)
-  pc_decrement = 1;
-  }
-  break;
-
-case llvm::Triple::arm:
-case llvm::Triple::thumb:
-  if (exc_code == 0x102) // EXC_ARM_DA_DEBUG
-  {
-// LWP_TODO: We need to find the WatchpointResource that matches
-// the address, and evaluate its Watchpoints.
-
-// It's a watchpoint, then, if the exc_sub_code indicates a
-// known/enabled data break address from our watchpoint list.
-lldb::WatchpointSP wp_sp;
-if (target)
-  wp_sp = target->GetWatchpointList().FindByAddress(
-  (lldb::addr_t)exc_sub_code);
-if (wp_sp && wp_sp->IsEnabled()) {
-  return StopInfo::CreateStopReasonWithWatchpointID(thread,
-wp_sp->GetID());
-} else {
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-}
-  } else if (exc_code == 1) // EXC_ARM_BREAKPOINT
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  } else if (exc_code == 0) // FIXME not EXC_ARM_BREAKPOINT but a kernel
-// is currently returning this so accept it
-// as indicating a breakpoint until the
-// kernel is fixed
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  }
-  break;
+bool stopped_by_hitting_breakpoint = false;
+bool stopped_by_completing_stepi = false;
+bool stopped_watchpoint = false;
+std::optional value;
+
+// exc_code 1
+if (exc_code == 1 && exc_sub_code == 0)
+  stopped_by_completing_stepi = true;
+if (exc_code == 1 && exc_sub_code != 0) {
+  stopped_by_hitting_breakpoint = true;
+  stopped_watchpoint = true;
+  value = exc_sub_code;
+}
 
-case llvm::Triple::aarch64_32:
-case llvm::Triple::aarch64: {
-  // xnu describes three things with type EXC_BREAKPOINT:
-  //
-  //   exc_code 0x102 [EXC_ARM_DA_DEBUG], exc_sub_code addr-of-insn
-  //  Watchpoint access.  exc_sub_code is the address of the
-  //  instruction which trigged the watchpoint trap.
-  //  debugserver may add the watchpoint number that was triggered
-  //  in exc_sub_sub_code.
-  //
-  //   exc_code 1 [EXC_ARM_BREAKPOI

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -633,171 +613,142 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
 }
 break;
 
+  // [exc_type, exc_code, exc_sub_code, exc_sub_sub_code]
+  //
+  // Instruction step:
+  //   [6, 1, 0]
+  //   Intel KDP [6, 3, ??]
+  //   armv7 [6, 0x102, ]  Same as software breakpoint!
+  //
+  // Software breakpoint:
+  //   x86 [6, 2, 0]
+  //   Intel KDP [6, 2, ]
+  //   arm64 [6, 1, ]
+  //   armv7 [6, 0x102, ]  Same as instruction step!
+  //
+  // Hardware breakpoint:
+  //   x86 [6, 1, , 0]
+  //   x86/Rosetta not implemented, see software breakpoint
+  //   arm64 [6, 1, ]
+  //   armv7 not implemented, see software breakpoint
+  //
+  // Hardware watchpoint:
+  //   x86 [6, 1, , 0] (both Intel hw and Rosetta)
+  //   arm64 [6, 0x102, , 0]
+  //   armv7 [6, 0x102, , 0]
+  //
+  // arm64 BRK instruction (imm arg not reflected in the ME)
+  //   [ 6, 1, ]
+  //
+  // In order of codes mach exceptions:
+  //   [6, 1, 0] - instruction step
+  //   [6, 1, ] - hardware breakpoint or watchpoint
+  //
+  //   [6, 2, 0] - software breakpoint
+  //   [6, 2, ] - software breakpoint
+  //
+  //   [6, 3] - instruction step
+  //
+  //   [6, 0x102, ] armv7 instruction step
+  //   [6, 0x102, ] armv7 software breakpoint
+  //   [6, 0x102, , 0] arm64/armv7 watchpoint
   case 6: // EXC_BREAKPOINT
   {
-bool is_actual_breakpoint = false;
-bool is_trace_if_actual_breakpoint_missing = false;
-switch (cpu) {
-case llvm::Triple::x86:
-case llvm::Triple::x86_64:
-  if (exc_code == 1) // EXC_I386_SGL
-  {
-if (!exc_sub_code) {
-  // This looks like a plain trap.
-  // Have to check if there is a breakpoint here as well.  When you
-  // single-step onto a trap, the single step stops you not to trap.
-  // Since we also do that check below, let's just use that logic.
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-} else {
-  if (StopInfoSP stop_info =
-  GetStopInfoForHardwareBP(thread, target, exc_data_count,
-   exc_sub_code, exc_sub_sub_code))
-return stop_info;
-}
-  } else if (exc_code == 2 || // EXC_I386_BPT
- exc_code == 3)   // EXC_I386_BPTFLT
-  {
-// KDP returns EXC_I386_BPTFLT for trace breakpoints
-if (exc_code == 3)
-  is_trace_if_actual_breakpoint_missing = true;
-
-is_actual_breakpoint = true;
-if (!pc_already_adjusted)
-  pc_decrement = 1;
-  }
-  break;
-
-case llvm::Triple::arm:
-case llvm::Triple::thumb:
-  if (exc_code == 0x102) // EXC_ARM_DA_DEBUG
-  {
-// LWP_TODO: We need to find the WatchpointResource that matches
-// the address, and evaluate its Watchpoints.
-
-// It's a watchpoint, then, if the exc_sub_code indicates a
-// known/enabled data break address from our watchpoint list.
-lldb::WatchpointSP wp_sp;
-if (target)
-  wp_sp = target->GetWatchpointList().FindByAddress(
-  (lldb::addr_t)exc_sub_code);
-if (wp_sp && wp_sp->IsEnabled()) {
-  return StopInfo::CreateStopReasonWithWatchpointID(thread,
-wp_sp->GetID());
-} else {
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-}
-  } else if (exc_code == 1) // EXC_ARM_BREAKPOINT
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  } else if (exc_code == 0) // FIXME not EXC_ARM_BREAKPOINT but a kernel
-// is currently returning this so accept it
-// as indicating a breakpoint until the
-// kernel is fixed
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  }
-  break;
+bool stopped_by_hitting_breakpoint = false;
+bool stopped_by_completing_stepi = false;
+bool stopped_watchpoint = false;
+std::optional value;
+
+// exc_code 1
+if (exc_code == 1 && exc_sub_code == 0)
+  stopped_by_completing_stepi = true;
+if (exc_code == 1 && exc_sub_code != 0) {
+  stopped_by_hitting_breakpoint = true;
+  stopped_watchpoint = true;
+  value = exc_sub_code;
+}
 
-case llvm::Triple::aarch64_32:
-case llvm::Triple::aarch64: {
-  // xnu describes three things with type EXC_BREAKPOINT:
-  //
-  //   exc_code 0x102 [EXC_ARM_DA_DEBUG], exc_sub_code addr-of-insn
-  //  Watchpoint access.  exc_sub_code is the address of the
-  //  instruction which trigged the watchpoint trap.
-  //  debugserver may add the watchpoint number that was triggered
-  //  in exc_sub_sub_code.
-  //
-  //   exc_code 1 [EXC_ARM_BREAKPOI

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -633,171 +613,142 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
 }
 break;
 
+  // [exc_type, exc_code, exc_sub_code, exc_sub_sub_code]
+  //
+  // Instruction step:
+  //   [6, 1, 0]
+  //   Intel KDP [6, 3, ??]
+  //   armv7 [6, 0x102, ]  Same as software breakpoint!
+  //
+  // Software breakpoint:
+  //   x86 [6, 2, 0]
+  //   Intel KDP [6, 2, ]
+  //   arm64 [6, 1, ]
+  //   armv7 [6, 0x102, ]  Same as instruction step!
+  //
+  // Hardware breakpoint:
+  //   x86 [6, 1, , 0]
+  //   x86/Rosetta not implemented, see software breakpoint
+  //   arm64 [6, 1, ]
+  //   armv7 not implemented, see software breakpoint
+  //
+  // Hardware watchpoint:
+  //   x86 [6, 1, , 0] (both Intel hw and Rosetta)
+  //   arm64 [6, 0x102, , 0]
+  //   armv7 [6, 0x102, , 0]
+  //
+  // arm64 BRK instruction (imm arg not reflected in the ME)
+  //   [ 6, 1, ]
+  //
+  // In order of codes mach exceptions:
+  //   [6, 1, 0] - instruction step
+  //   [6, 1, ] - hardware breakpoint or watchpoint
+  //
+  //   [6, 2, 0] - software breakpoint
+  //   [6, 2, ] - software breakpoint
+  //
+  //   [6, 3] - instruction step
+  //
+  //   [6, 0x102, ] armv7 instruction step
+  //   [6, 0x102, ] armv7 software breakpoint
+  //   [6, 0x102, , 0] arm64/armv7 watchpoint
   case 6: // EXC_BREAKPOINT
   {
-bool is_actual_breakpoint = false;
-bool is_trace_if_actual_breakpoint_missing = false;
-switch (cpu) {
-case llvm::Triple::x86:
-case llvm::Triple::x86_64:
-  if (exc_code == 1) // EXC_I386_SGL
-  {
-if (!exc_sub_code) {
-  // This looks like a plain trap.
-  // Have to check if there is a breakpoint here as well.  When you
-  // single-step onto a trap, the single step stops you not to trap.
-  // Since we also do that check below, let's just use that logic.
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-} else {
-  if (StopInfoSP stop_info =
-  GetStopInfoForHardwareBP(thread, target, exc_data_count,
-   exc_sub_code, exc_sub_sub_code))
-return stop_info;
-}
-  } else if (exc_code == 2 || // EXC_I386_BPT
- exc_code == 3)   // EXC_I386_BPTFLT
-  {
-// KDP returns EXC_I386_BPTFLT for trace breakpoints
-if (exc_code == 3)
-  is_trace_if_actual_breakpoint_missing = true;
-
-is_actual_breakpoint = true;
-if (!pc_already_adjusted)
-  pc_decrement = 1;
-  }
-  break;
-
-case llvm::Triple::arm:
-case llvm::Triple::thumb:
-  if (exc_code == 0x102) // EXC_ARM_DA_DEBUG
-  {
-// LWP_TODO: We need to find the WatchpointResource that matches
-// the address, and evaluate its Watchpoints.
-
-// It's a watchpoint, then, if the exc_sub_code indicates a
-// known/enabled data break address from our watchpoint list.
-lldb::WatchpointSP wp_sp;
-if (target)
-  wp_sp = target->GetWatchpointList().FindByAddress(
-  (lldb::addr_t)exc_sub_code);
-if (wp_sp && wp_sp->IsEnabled()) {
-  return StopInfo::CreateStopReasonWithWatchpointID(thread,
-wp_sp->GetID());
-} else {
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-}
-  } else if (exc_code == 1) // EXC_ARM_BREAKPOINT
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  } else if (exc_code == 0) // FIXME not EXC_ARM_BREAKPOINT but a kernel
-// is currently returning this so accept it
-// as indicating a breakpoint until the
-// kernel is fixed
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  }
-  break;
+bool stopped_by_hitting_breakpoint = false;
+bool stopped_by_completing_stepi = false;
+bool stopped_watchpoint = false;
+std::optional value;
+
+// exc_code 1
+if (exc_code == 1 && exc_sub_code == 0)
+  stopped_by_completing_stepi = true;
+if (exc_code == 1 && exc_sub_code != 0) {
+  stopped_by_hitting_breakpoint = true;
+  stopped_watchpoint = true;
+  value = exc_sub_code;
+}
 
-case llvm::Triple::aarch64_32:
-case llvm::Triple::aarch64: {
-  // xnu describes three things with type EXC_BREAKPOINT:
-  //
-  //   exc_code 0x102 [EXC_ARM_DA_DEBUG], exc_sub_code addr-of-insn
-  //  Watchpoint access.  exc_sub_code is the address of the
-  //  instruction which trigged the watchpoint trap.
-  //  debugserver may add the watchpoint number that was triggered
-  //  in exc_sub_sub_code.
-  //
-  //   exc_code 1 [EXC_ARM_BREAKPOI

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -607,6 +575,18 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
   target ? target->GetArchitecture().GetMachine()
  : llvm::Triple::UnknownArch;
 
+  ProcessSP process_sp(thread.GetProcess());
+  RegisterContextSP reg_ctx_sp(thread.GetRegisterContext());
+  BreakpointSiteSP bp_site_sp;
+  addr_t pc = LLDB_INVALID_ADDRESS;
+  if (reg_ctx_sp) {

jimingham wrote:

When would you ever not have a register context?

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -633,171 +613,142 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
 }
 break;
 
+  // [exc_type, exc_code, exc_sub_code, exc_sub_sub_code]
+  //
+  // Instruction step:
+  //   [6, 1, 0]
+  //   Intel KDP [6, 3, ??]
+  //   armv7 [6, 0x102, ]  Same as software breakpoint!
+  //
+  // Software breakpoint:
+  //   x86 [6, 2, 0]
+  //   Intel KDP [6, 2, ]
+  //   arm64 [6, 1, ]
+  //   armv7 [6, 0x102, ]  Same as instruction step!
+  //
+  // Hardware breakpoint:
+  //   x86 [6, 1, , 0]
+  //   x86/Rosetta not implemented, see software breakpoint
+  //   arm64 [6, 1, ]
+  //   armv7 not implemented, see software breakpoint
+  //
+  // Hardware watchpoint:
+  //   x86 [6, 1, , 0] (both Intel hw and Rosetta)
+  //   arm64 [6, 0x102, , 0]
+  //   armv7 [6, 0x102, , 0]
+  //
+  // arm64 BRK instruction (imm arg not reflected in the ME)
+  //   [ 6, 1, ]
+  //
+  // In order of codes mach exceptions:
+  //   [6, 1, 0] - instruction step
+  //   [6, 1, ] - hardware breakpoint or watchpoint
+  //
+  //   [6, 2, 0] - software breakpoint
+  //   [6, 2, ] - software breakpoint
+  //
+  //   [6, 3] - instruction step
+  //
+  //   [6, 0x102, ] armv7 instruction step
+  //   [6, 0x102, ] armv7 software breakpoint
+  //   [6, 0x102, , 0] arm64/armv7 watchpoint
   case 6: // EXC_BREAKPOINT
   {
-bool is_actual_breakpoint = false;
-bool is_trace_if_actual_breakpoint_missing = false;
-switch (cpu) {
-case llvm::Triple::x86:
-case llvm::Triple::x86_64:
-  if (exc_code == 1) // EXC_I386_SGL
-  {
-if (!exc_sub_code) {
-  // This looks like a plain trap.
-  // Have to check if there is a breakpoint here as well.  When you
-  // single-step onto a trap, the single step stops you not to trap.
-  // Since we also do that check below, let's just use that logic.
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-} else {
-  if (StopInfoSP stop_info =
-  GetStopInfoForHardwareBP(thread, target, exc_data_count,
-   exc_sub_code, exc_sub_sub_code))
-return stop_info;
-}
-  } else if (exc_code == 2 || // EXC_I386_BPT
- exc_code == 3)   // EXC_I386_BPTFLT
-  {
-// KDP returns EXC_I386_BPTFLT for trace breakpoints
-if (exc_code == 3)
-  is_trace_if_actual_breakpoint_missing = true;
-
-is_actual_breakpoint = true;
-if (!pc_already_adjusted)
-  pc_decrement = 1;
-  }
-  break;
-
-case llvm::Triple::arm:
-case llvm::Triple::thumb:
-  if (exc_code == 0x102) // EXC_ARM_DA_DEBUG
-  {
-// LWP_TODO: We need to find the WatchpointResource that matches
-// the address, and evaluate its Watchpoints.
-
-// It's a watchpoint, then, if the exc_sub_code indicates a
-// known/enabled data break address from our watchpoint list.
-lldb::WatchpointSP wp_sp;
-if (target)
-  wp_sp = target->GetWatchpointList().FindByAddress(
-  (lldb::addr_t)exc_sub_code);
-if (wp_sp && wp_sp->IsEnabled()) {
-  return StopInfo::CreateStopReasonWithWatchpointID(thread,
-wp_sp->GetID());
-} else {
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-}
-  } else if (exc_code == 1) // EXC_ARM_BREAKPOINT
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  } else if (exc_code == 0) // FIXME not EXC_ARM_BREAKPOINT but a kernel
-// is currently returning this so accept it
-// as indicating a breakpoint until the
-// kernel is fixed
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  }
-  break;
+bool stopped_by_hitting_breakpoint = false;
+bool stopped_by_completing_stepi = false;
+bool stopped_watchpoint = false;
+std::optional value;
+
+// exc_code 1
+if (exc_code == 1 && exc_sub_code == 0)
+  stopped_by_completing_stepi = true;
+if (exc_code == 1 && exc_sub_code != 0) {
+  stopped_by_hitting_breakpoint = true;
+  stopped_watchpoint = true;
+  value = exc_sub_code;
+}
 
-case llvm::Triple::aarch64_32:
-case llvm::Triple::aarch64: {
-  // xnu describes three things with type EXC_BREAKPOINT:
-  //
-  //   exc_code 0x102 [EXC_ARM_DA_DEBUG], exc_sub_code addr-of-insn
-  //  Watchpoint access.  exc_sub_code is the address of the
-  //  instruction which trigged the watchpoint trap.
-  //  debugserver may add the watchpoint number that was triggered
-  //  in exc_sub_sub_code.
-  //
-  //   exc_code 1 [EXC_ARM_BREAKPOI

[Lldb-commits] [lldb] [LLDB] Make 'process load' take remote os path delimiter into account (PR #98690)

[Vladislav Dzhidzhoev via lldb-commits]

https://github.com/dzhidzhoev created 
https://github.com/llvm/llvm-project/pull/98690

Currently, if we execute 'process load' with remote debugging, it uses the 
host's path delimiter to look up files on a target machine. If we run remote 
debugging of Linux target on Windows and execute process load C:\foo\a.so, 
lldb-server tries to load \foo\a.so instead of /foo/a.so.

It affects several API tests.

This commit fixes that error. Also, it contains minor fixes for 
TestLoadUnload.py for testing on Windows host and Linux target.

>From 98b75927878e35ca556ecbbecb1125621a63fea9 Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev 
Date: Tue, 23 Apr 2024 05:44:49 +
Subject: [PATCH] [LLDB] Make 'process load' take remote os path delimiter into
 account

Currently, if we execute 'process load' with remote debugging,
it uses host's path delimiter to lookup files on target machine.
If we run remote debugging of Linux target on Windows and execute
process load C:\foo\a.so, lldb-server tries to load \foo\a.so
instead of /foo/a.so.

It affects several API tests.

This commit fixes that error. Also, it contains minor fixes for
TestLoadUnload.py for testing on Windows host and Linux target.
---
 lldb/source/Commands/CommandObjectProcess.cpp  | 3 ++-
 .../test/API/functionalities/load_unload/TestLoadUnload.py | 7 ---
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/lldb/source/Commands/CommandObjectProcess.cpp 
b/lldb/source/Commands/CommandObjectProcess.cpp
index 3587a8f529e4a..bdcd58c0da785 100644
--- a/lldb/source/Commands/CommandObjectProcess.cpp
+++ b/lldb/source/Commands/CommandObjectProcess.cpp
@@ -950,11 +950,12 @@ class CommandObjectProcessLoad : public 
CommandObjectParsed {
   ExecutionContext *execution_context) override {
   Status error;
   const int short_option = m_getopt_table[option_idx].val;
+  ArchSpec arch = 
execution_context->GetProcessPtr()->GetSystemArchitecture();
   switch (short_option) {
   case 'i':
 do_install = true;
 if (!option_arg.empty())
-  install_path.SetFile(option_arg, FileSpec::Style::native);
+  install_path.SetFile(option_arg, arch.GetTriple());
 break;
   default:
 llvm_unreachable("Unimplemented option");
diff --git a/lldb/test/API/functionalities/load_unload/TestLoadUnload.py 
b/lldb/test/API/functionalities/load_unload/TestLoadUnload.py
index e52fb8c87377f..cc4060d48cc86 100644
--- a/lldb/test/API/functionalities/load_unload/TestLoadUnload.py
+++ b/lldb/test/API/functionalities/load_unload/TestLoadUnload.py
@@ -62,7 +62,7 @@ def copy_shlibs_to_remote(self, hidden_dir=False):
 for f in shlibs:
 err = lldb.remote_platform.Put(
 lldb.SBFileSpec(self.getBuildArtifact(f)),
-lldb.SBFileSpec(os.path.join(wd, f)),
+lldb.SBFileSpec(lldbutil.join_remote_paths(wd, f)),
 )
 if err.Fail():
 raise RuntimeError(
@@ -71,7 +71,7 @@ def copy_shlibs_to_remote(self, hidden_dir=False):
 if hidden_dir:
 shlib = "libloadunload_d." + ext
 hidden_dir = os.path.join(wd, "hidden")
-hidden_file = os.path.join(hidden_dir, shlib)
+hidden_file = lldbutil.join_remote_paths(hidden_dir, shlib)
 err = lldb.remote_platform.MakeDirectory(hidden_dir)
 if err.Fail():
 raise RuntimeError(
@@ -405,8 +405,9 @@ def run_step_over_load(self):
 
 # We can't find a breakpoint location for d_init before launching because
 # executable dependencies are resolved relative to the debuggers PWD. Bug?
+# The remote lldb server resolves the executable dependencies correctly.
 @expectedFailureAll(
-oslist=["freebsd", "linux", "netbsd"], 
triple=no_match("aarch64-.*-android")
+oslist=["freebsd", "linux", "netbsd"], 
triple=no_match("aarch64-.*-android"), remote=False
 )
 @expectedFailureAll(oslist=["windows"], archs=["aarch64"])
 def test_static_init_during_load(self):

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

[Lldb-commits] [lldb] [LLDB] Make 'process load' take remote os path delimiter into account (PR #98690)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Vladislav Dzhidzhoev (dzhidzhoev)


Changes

Currently, if we execute 'process load' with remote debugging, it uses the 
host's path delimiter to look up files on a target machine. If we run remote 
debugging of Linux target on Windows and execute process load C:\foo\a.so, 
lldb-server tries to load \foo\a.so instead of /foo/a.so.

It affects several API tests.

This commit fixes that error. Also, it contains minor fixes for 
TestLoadUnload.py for testing on Windows host and Linux target.

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


2 Files Affected:

- (modified) lldb/source/Commands/CommandObjectProcess.cpp (+2-1) 
- (modified) lldb/test/API/functionalities/load_unload/TestLoadUnload.py (+4-3) 


``diff
diff --git a/lldb/source/Commands/CommandObjectProcess.cpp 
b/lldb/source/Commands/CommandObjectProcess.cpp
index 3587a8f529e4a..bdcd58c0da785 100644
--- a/lldb/source/Commands/CommandObjectProcess.cpp
+++ b/lldb/source/Commands/CommandObjectProcess.cpp
@@ -950,11 +950,12 @@ class CommandObjectProcessLoad : public 
CommandObjectParsed {
   ExecutionContext *execution_context) override {
   Status error;
   const int short_option = m_getopt_table[option_idx].val;
+  ArchSpec arch = 
execution_context->GetProcessPtr()->GetSystemArchitecture();
   switch (short_option) {
   case 'i':
 do_install = true;
 if (!option_arg.empty())
-  install_path.SetFile(option_arg, FileSpec::Style::native);
+  install_path.SetFile(option_arg, arch.GetTriple());
 break;
   default:
 llvm_unreachable("Unimplemented option");
diff --git a/lldb/test/API/functionalities/load_unload/TestLoadUnload.py 
b/lldb/test/API/functionalities/load_unload/TestLoadUnload.py
index e52fb8c87377f..cc4060d48cc86 100644
--- a/lldb/test/API/functionalities/load_unload/TestLoadUnload.py
+++ b/lldb/test/API/functionalities/load_unload/TestLoadUnload.py
@@ -62,7 +62,7 @@ def copy_shlibs_to_remote(self, hidden_dir=False):
 for f in shlibs:
 err = lldb.remote_platform.Put(
 lldb.SBFileSpec(self.getBuildArtifact(f)),
-lldb.SBFileSpec(os.path.join(wd, f)),
+lldb.SBFileSpec(lldbutil.join_remote_paths(wd, f)),
 )
 if err.Fail():
 raise RuntimeError(
@@ -71,7 +71,7 @@ def copy_shlibs_to_remote(self, hidden_dir=False):
 if hidden_dir:
 shlib = "libloadunload_d." + ext
 hidden_dir = os.path.join(wd, "hidden")
-hidden_file = os.path.join(hidden_dir, shlib)
+hidden_file = lldbutil.join_remote_paths(hidden_dir, shlib)
 err = lldb.remote_platform.MakeDirectory(hidden_dir)
 if err.Fail():
 raise RuntimeError(
@@ -405,8 +405,9 @@ def run_step_over_load(self):
 
 # We can't find a breakpoint location for d_init before launching because
 # executable dependencies are resolved relative to the debuggers PWD. Bug?
+# The remote lldb server resolves the executable dependencies correctly.
 @expectedFailureAll(
-oslist=["freebsd", "linux", "netbsd"], 
triple=no_match("aarch64-.*-android")
+oslist=["freebsd", "linux", "netbsd"], 
triple=no_match("aarch64-.*-android"), remote=False
 )
 @expectedFailureAll(oslist=["windows"], archs=["aarch64"])
 def test_static_init_during_load(self):

``




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

[Lldb-commits] [lldb] [LLDB] Make 'process load' take remote os path delimiter into account (PR #98690)

[Vladislav Dzhidzhoev via lldb-commits]

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

[Lldb-commits] [lldb] [LLDB] Make 'process load' take remote os path delimiter into account (PR #98690)

[via lldb-commits]

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff 73dad7a765226bd7ade98f85d050e80f411f6dad 
98b75927878e35ca556ecbbecb1125621a63fea9 --extensions cpp -- 
lldb/source/Commands/CommandObjectProcess.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Commands/CommandObjectProcess.cpp 
b/lldb/source/Commands/CommandObjectProcess.cpp
index bdcd58c0da..8685d57615 100644
--- a/lldb/source/Commands/CommandObjectProcess.cpp
+++ b/lldb/source/Commands/CommandObjectProcess.cpp
@@ -950,7 +950,8 @@ public:
   ExecutionContext *execution_context) override {
   Status error;
   const int short_option = m_getopt_table[option_idx].val;
-  ArchSpec arch = 
execution_context->GetProcessPtr()->GetSystemArchitecture();
+  ArchSpec arch =
+  execution_context->GetProcessPtr()->GetSystemArchitecture();
   switch (short_option) {
   case 'i':
 do_install = true;

``




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

[Lldb-commits] [lldb] [LLDB] Make 'process load' take remote os path delimiter into account (PR #98690)

[via lldb-commits]

github-actions[bot] wrote:




:warning: Python code formatter, darker found issues in your code. :warning:



You can test this locally with the following command:


``bash
darker --check --diff -r 
73dad7a765226bd7ade98f85d050e80f411f6dad...98b75927878e35ca556ecbbecb1125621a63fea9
 lldb/test/API/functionalities/load_unload/TestLoadUnload.py
``





View the diff from darker here.


``diff
--- TestLoadUnload.py   2024-07-12 18:56:56.00 +
+++ TestLoadUnload.py   2024-07-12 20:24:37.513638 +
@@ -405,11 +405,13 @@
 
 # We can't find a breakpoint location for d_init before launching because
 # executable dependencies are resolved relative to the debuggers PWD. Bug?
 # The remote lldb server resolves the executable dependencies correctly.
 @expectedFailureAll(
-oslist=["freebsd", "linux", "netbsd"], 
triple=no_match("aarch64-.*-android"), remote=False
+oslist=["freebsd", "linux", "netbsd"],
+triple=no_match("aarch64-.*-android"),
+remote=False,
 )
 @expectedFailureAll(oslist=["windows"], archs=["aarch64"])
 def test_static_init_during_load(self):
 """Test that we can set breakpoints correctly in static initializers"""
 self.copy_shlibs_to_remote()

``




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

[Lldb-commits] [lldb] [LLDB] Make 'process load' take remote os path delimiter into account (PR #98690)

[Vladislav Dzhidzhoev via lldb-commits]

https://github.com/dzhidzhoev updated 
https://github.com/llvm/llvm-project/pull/98690

>From aee177b86c61ab8a3ad1b2c4d1fa32239875e10f Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev 
Date: Tue, 23 Apr 2024 05:44:49 +
Subject: [PATCH] [LLDB] Make 'process load' take remote os path delimiter into
 account

Currently, if we execute 'process load' with remote debugging,
it uses host's path delimiter to lookup files on target machine.
If we run remote debugging of Linux target on Windows and execute
'process load C:\foo\a.so', lldb-server tries to load \foo\a.so
instead of /foo/a.so.

It affects several API tests.

This commit fixes that error. Also, it contains minor fixes for
TestLoadUnload.py for testing on Windows host and Linux target.
---
 lldb/source/Commands/CommandObjectProcess.cpp| 4 +++-
 .../API/functionalities/load_unload/TestLoadUnload.py| 9 ++---
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/lldb/source/Commands/CommandObjectProcess.cpp 
b/lldb/source/Commands/CommandObjectProcess.cpp
index 3587a8f529e4a..8685d5761557b 100644
--- a/lldb/source/Commands/CommandObjectProcess.cpp
+++ b/lldb/source/Commands/CommandObjectProcess.cpp
@@ -950,11 +950,13 @@ class CommandObjectProcessLoad : public 
CommandObjectParsed {
   ExecutionContext *execution_context) override {
   Status error;
   const int short_option = m_getopt_table[option_idx].val;
+  ArchSpec arch =
+  execution_context->GetProcessPtr()->GetSystemArchitecture();
   switch (short_option) {
   case 'i':
 do_install = true;
 if (!option_arg.empty())
-  install_path.SetFile(option_arg, FileSpec::Style::native);
+  install_path.SetFile(option_arg, arch.GetTriple());
 break;
   default:
 llvm_unreachable("Unimplemented option");
diff --git a/lldb/test/API/functionalities/load_unload/TestLoadUnload.py 
b/lldb/test/API/functionalities/load_unload/TestLoadUnload.py
index e52fb8c87377f..d0246f9491d48 100644
--- a/lldb/test/API/functionalities/load_unload/TestLoadUnload.py
+++ b/lldb/test/API/functionalities/load_unload/TestLoadUnload.py
@@ -62,7 +62,7 @@ def copy_shlibs_to_remote(self, hidden_dir=False):
 for f in shlibs:
 err = lldb.remote_platform.Put(
 lldb.SBFileSpec(self.getBuildArtifact(f)),
-lldb.SBFileSpec(os.path.join(wd, f)),
+lldb.SBFileSpec(lldbutil.join_remote_paths(wd, f)),
 )
 if err.Fail():
 raise RuntimeError(
@@ -71,7 +71,7 @@ def copy_shlibs_to_remote(self, hidden_dir=False):
 if hidden_dir:
 shlib = "libloadunload_d." + ext
 hidden_dir = os.path.join(wd, "hidden")
-hidden_file = os.path.join(hidden_dir, shlib)
+hidden_file = lldbutil.join_remote_paths(hidden_dir, shlib)
 err = lldb.remote_platform.MakeDirectory(hidden_dir)
 if err.Fail():
 raise RuntimeError(
@@ -405,8 +405,11 @@ def run_step_over_load(self):
 
 # We can't find a breakpoint location for d_init before launching because
 # executable dependencies are resolved relative to the debuggers PWD. Bug?
+# The remote lldb server resolves the executable dependencies correctly.
 @expectedFailureAll(
-oslist=["freebsd", "linux", "netbsd"], 
triple=no_match("aarch64-.*-android")
+oslist=["freebsd", "linux", "netbsd"],
+triple=no_match("aarch64-.*-android"),
+remote=False,
 )
 @expectedFailureAll(oslist=["windows"], archs=["aarch64"])
 def test_static_init_during_load(self):

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

[Lldb-commits] [lldb] [lldb][test] Fix TestStdCXXDisassembly test for case when tests are linked with libc++ statically (PR #98694)

[Vladislav Dzhidzhoev via lldb-commits]

https://github.com/dzhidzhoev created 
https://github.com/llvm/llvm-project/pull/98694

The test expects 'libstdc++' or 'libc++' SO module in the module list. In case 
when static linking with libc++ is on by default, none of them may be present.

Thus, USE_SYSTEM_STDLIB is added to ensure the presence of any of them.

>From e98b2f73269ba4e8f1a980ffb2b2765d1de5f655 Mon Sep 17 00:00:00 2001
From: Vladimir Vereschaka 
Date: Thu, 30 May 2024 03:04:58 +
Subject: [PATCH] [lldb][test] Fix TestStdCXXDisassembly test when tests are
 linked with libc++ statically

The test expects 'libstdc++' or 'libc++' SO module in the module list.
In case when static linking with libc++ is on by default, none of them
may be present.

Thus, USE_SYSTEM_STDLIB is added to ensure presence of any of them.
---
 lldb/test/API/lang/cpp/stl/Makefile | 2 ++
 lldb/test/API/lang/cpp/stl/TestStdCXXDisassembly.py | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/lldb/test/API/lang/cpp/stl/Makefile 
b/lldb/test/API/lang/cpp/stl/Makefile
index 8b20bcb05..8534fa9b00209 100644
--- a/lldb/test/API/lang/cpp/stl/Makefile
+++ b/lldb/test/API/lang/cpp/stl/Makefile
@@ -1,3 +1,5 @@
 CXX_SOURCES := main.cpp
 
+USE_SYSTEM_STDLIB := 1
+
 include Makefile.rules
diff --git a/lldb/test/API/lang/cpp/stl/TestStdCXXDisassembly.py 
b/lldb/test/API/lang/cpp/stl/TestStdCXXDisassembly.py
index 1e1b0a4d621f0..cc46989f984b2 100644
--- a/lldb/test/API/lang/cpp/stl/TestStdCXXDisassembly.py
+++ b/lldb/test/API/lang/cpp/stl/TestStdCXXDisassembly.py
@@ -44,7 +44,7 @@ def test_stdcxx_disasm(self):
 # module is the corresponding SBModule.
 
 self.expect(
-lib_stdcxx, "Libraray StdC++ is located", exe=False, 
substrs=["lib"]
+lib_stdcxx, "Library StdC++ is located", exe=False, substrs=["lib"]
 )
 
 self.runCmd("image dump symtab '%s'" % lib_stdcxx)

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

[Lldb-commits] [lldb] [lldb][test] Fix TestStdCXXDisassembly test for case when tests are linked with libc++ statically (PR #98694)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Vladislav Dzhidzhoev (dzhidzhoev)


Changes

The test expects 'libstdc++' or 'libc++' SO module in the module list. In case 
when static linking with libc++ is on by default, none of them may be present.

Thus, USE_SYSTEM_STDLIB is added to ensure the presence of any of them.

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


2 Files Affected:

- (modified) lldb/test/API/lang/cpp/stl/Makefile (+2) 
- (modified) lldb/test/API/lang/cpp/stl/TestStdCXXDisassembly.py (+1-1) 


``diff
diff --git a/lldb/test/API/lang/cpp/stl/Makefile 
b/lldb/test/API/lang/cpp/stl/Makefile
index 8b20bcb05..8534fa9b00209 100644
--- a/lldb/test/API/lang/cpp/stl/Makefile
+++ b/lldb/test/API/lang/cpp/stl/Makefile
@@ -1,3 +1,5 @@
 CXX_SOURCES := main.cpp
 
+USE_SYSTEM_STDLIB := 1
+
 include Makefile.rules
diff --git a/lldb/test/API/lang/cpp/stl/TestStdCXXDisassembly.py 
b/lldb/test/API/lang/cpp/stl/TestStdCXXDisassembly.py
index 1e1b0a4d621f0..cc46989f984b2 100644
--- a/lldb/test/API/lang/cpp/stl/TestStdCXXDisassembly.py
+++ b/lldb/test/API/lang/cpp/stl/TestStdCXXDisassembly.py
@@ -44,7 +44,7 @@ def test_stdcxx_disasm(self):
 # module is the corresponding SBModule.
 
 self.expect(
-lib_stdcxx, "Libraray StdC++ is located", exe=False, 
substrs=["lib"]
+lib_stdcxx, "Library StdC++ is located", exe=False, substrs=["lib"]
 )
 
 self.runCmd("image dump symtab '%s'" % lib_stdcxx)

``




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

[Lldb-commits] [lldb] [lldb][test] Fix TestStdCXXDisassembly test for case when tests are linked with libc++ statically (PR #98694)

[via lldb-commits]

github-actions[bot] wrote:




:warning: Python code formatter, darker found issues in your code. :warning:



You can test this locally with the following command:


``bash
darker --check --diff -r 
bee240367cc48bbc93fe5eb57d537968dfe4419f...e98b2f73269ba4e8f1a980ffb2b2765d1de5f655
 lldb/test/API/lang/cpp/stl/TestStdCXXDisassembly.py
``





View the diff from darker here.


``diff
--- TestStdCXXDisassembly.py2024-07-12 20:42:23.00 +
+++ TestStdCXXDisassembly.py2024-07-12 20:52:55.924613 +
@@ -41,13 +41,11 @@
 break
 
 # At this point, lib_stdcxx is the full path to the stdc++ library and
 # module is the corresponding SBModule.
 
-self.expect(
-lib_stdcxx, "Library StdC++ is located", exe=False, substrs=["lib"]
-)
+self.expect(lib_stdcxx, "Library StdC++ is located", exe=False, 
substrs=["lib"])
 
 self.runCmd("image dump symtab '%s'" % lib_stdcxx)
 raw_output = self.res.GetOutput()
 # Now, look for every 'Code' symbol and feed its load address into the
 # command: 'disassemble -s load_address -e end_address', where the

``




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

[Lldb-commits] [lldb] [lldb][test] Fix TestStdCXXDisassembly test for case when tests are linked with libc++ statically (PR #98694)

[Vladislav Dzhidzhoev via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -633,171 +613,142 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
 }
 break;
 
+  // [exc_type, exc_code, exc_sub_code, exc_sub_sub_code]
+  //
+  // Instruction step:
+  //   [6, 1, 0]
+  //   Intel KDP [6, 3, ??]
+  //   armv7 [6, 0x102, ]  Same as software breakpoint!
+  //
+  // Software breakpoint:
+  //   x86 [6, 2, 0]
+  //   Intel KDP [6, 2, ]
+  //   arm64 [6, 1, ]
+  //   armv7 [6, 0x102, ]  Same as instruction step!
+  //
+  // Hardware breakpoint:
+  //   x86 [6, 1, , 0]
+  //   x86/Rosetta not implemented, see software breakpoint
+  //   arm64 [6, 1, ]
+  //   armv7 not implemented, see software breakpoint
+  //
+  // Hardware watchpoint:
+  //   x86 [6, 1, , 0] (both Intel hw and Rosetta)
+  //   arm64 [6, 0x102, , 0]
+  //   armv7 [6, 0x102, , 0]
+  //
+  // arm64 BRK instruction (imm arg not reflected in the ME)
+  //   [ 6, 1, ]
+  //
+  // In order of codes mach exceptions:
+  //   [6, 1, 0] - instruction step
+  //   [6, 1, ] - hardware breakpoint or watchpoint
+  //
+  //   [6, 2, 0] - software breakpoint
+  //   [6, 2, ] - software breakpoint
+  //
+  //   [6, 3] - instruction step
+  //
+  //   [6, 0x102, ] armv7 instruction step
+  //   [6, 0x102, ] armv7 software breakpoint
+  //   [6, 0x102, , 0] arm64/armv7 watchpoint
   case 6: // EXC_BREAKPOINT
   {
-bool is_actual_breakpoint = false;
-bool is_trace_if_actual_breakpoint_missing = false;
-switch (cpu) {
-case llvm::Triple::x86:
-case llvm::Triple::x86_64:
-  if (exc_code == 1) // EXC_I386_SGL
-  {
-if (!exc_sub_code) {
-  // This looks like a plain trap.
-  // Have to check if there is a breakpoint here as well.  When you
-  // single-step onto a trap, the single step stops you not to trap.
-  // Since we also do that check below, let's just use that logic.
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-} else {
-  if (StopInfoSP stop_info =
-  GetStopInfoForHardwareBP(thread, target, exc_data_count,
-   exc_sub_code, exc_sub_sub_code))
-return stop_info;
-}
-  } else if (exc_code == 2 || // EXC_I386_BPT
- exc_code == 3)   // EXC_I386_BPTFLT
-  {
-// KDP returns EXC_I386_BPTFLT for trace breakpoints
-if (exc_code == 3)
-  is_trace_if_actual_breakpoint_missing = true;
-
-is_actual_breakpoint = true;
-if (!pc_already_adjusted)
-  pc_decrement = 1;
-  }
-  break;
-
-case llvm::Triple::arm:
-case llvm::Triple::thumb:
-  if (exc_code == 0x102) // EXC_ARM_DA_DEBUG
-  {
-// LWP_TODO: We need to find the WatchpointResource that matches
-// the address, and evaluate its Watchpoints.
-
-// It's a watchpoint, then, if the exc_sub_code indicates a
-// known/enabled data break address from our watchpoint list.
-lldb::WatchpointSP wp_sp;
-if (target)
-  wp_sp = target->GetWatchpointList().FindByAddress(
-  (lldb::addr_t)exc_sub_code);
-if (wp_sp && wp_sp->IsEnabled()) {
-  return StopInfo::CreateStopReasonWithWatchpointID(thread,
-wp_sp->GetID());
-} else {
-  is_actual_breakpoint = true;
-  is_trace_if_actual_breakpoint_missing = true;
-}
-  } else if (exc_code == 1) // EXC_ARM_BREAKPOINT
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  } else if (exc_code == 0) // FIXME not EXC_ARM_BREAKPOINT but a kernel
-// is currently returning this so accept it
-// as indicating a breakpoint until the
-// kernel is fixed
-  {
-is_actual_breakpoint = true;
-is_trace_if_actual_breakpoint_missing = true;
-  }
-  break;
+bool stopped_by_hitting_breakpoint = false;
+bool stopped_by_completing_stepi = false;
+bool stopped_watchpoint = false;
+std::optional value;
+
+// exc_code 1
+if (exc_code == 1 && exc_sub_code == 0)
+  stopped_by_completing_stepi = true;
+if (exc_code == 1 && exc_sub_code != 0) {
+  stopped_by_hitting_breakpoint = true;
+  stopped_watchpoint = true;
+  value = exc_sub_code;
+}
 
-case llvm::Triple::aarch64_32:
-case llvm::Triple::aarch64: {
-  // xnu describes three things with type EXC_BREAKPOINT:
-  //
-  //   exc_code 0x102 [EXC_ARM_DA_DEBUG], exc_sub_code addr-of-insn
-  //  Watchpoint access.  exc_sub_code is the address of the
-  //  instruction which trigged the watchpoint trap.
-  //  debugserver may add the watchpoint number that was triggered
-  //  in exc_sub_sub_code.
-  //
-  //   exc_code 1 [EXC_ARM_BREAKPOI

[Lldb-commits] [lldb] [LLDB] Fix Android debugging (PR #98581)

[Vladislav Dzhidzhoev via lldb-commits]

dzhidzhoev wrote:

> @dzhidzhoev Yes, #98623 fixed the ResolveExecutableModule issue, thank you!

May I ask you: are there any public builders available for remote Android lldb 
testing? It will come in handy to know if there are any.

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -1880,60 +1849,40 @@ ThreadSP ProcessGDBRemote::SetThreadStopInfo(
   StopInfo::CreateStopReasonVForkDone(*thread_sp));
   handled = true;
 }
-  } else if (!signo) {
-addr_t pc = thread_sp->GetRegisterContext()->GetPC();
-lldb::BreakpointSiteSP bp_site_sp =
-thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
-
-// If a thread is stopped at a breakpoint site, set that as the stop
-// reason even if it hasn't executed the breakpoint instruction yet.
-// We will silently step over the breakpoint when we resume execution
-// and miss the fact that this thread hit the breakpoint.
-if (bp_site_sp && bp_site_sp->ValidForThisThread(*thread_sp)) {
-  
thread_sp->SetStopInfo(StopInfo::CreateStopReasonWithBreakpointSiteID(
-  *thread_sp, bp_site_sp->GetID()));
-  handled = true;
-}
   }
 
   if (!handled && signo && !did_exec) {
 if (signo == SIGTRAP) {
   // Currently we are going to assume SIGTRAP means we are either
   // hitting a breakpoint or hardware single stepping.
-  handled = true;
-  addr_t pc =
-  thread_sp->GetRegisterContext()->GetPC() + 
m_breakpoint_pc_offset;
-  lldb::BreakpointSiteSP bp_site_sp =
-  thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(
-  pc);
 
-  if (bp_site_sp) {
-// If the breakpoint is for this thread, then we'll report the hit,
-// but if it is for another thread, we can just report no reason.
-// We don't need to worry about stepping over the breakpoint here,
-// that will be taken care of when the thread resumes and notices
-// that there's a breakpoint under the pc.
-if (bp_site_sp->ValidForThisThread(*thread_sp)) {
-  if (m_breakpoint_pc_offset != 0)
-thread_sp->GetRegisterContext()->SetPC(pc);
-  thread_sp->SetStopInfo(
-  StopInfo::CreateStopReasonWithBreakpointSiteID(
-  *thread_sp, bp_site_sp->GetID()));
-} else {
-  StopInfoSP invalid_stop_info_sp;
-  thread_sp->SetStopInfo(invalid_stop_info_sp);
-}
+  // If we were stepping then assume the stop was the result of the

jimingham wrote:

The previous algorithm reversed this assumption.  It first checked for the 
breakpoint, and if a breakpoint was at the site, then returned either a 
breakpoint hit (if it was for this thread) or no reason, and only if there 
wasn't a breakpoint there did it return the trace result.

There was also another case that I don't see handled here anymore, if we 
weren't at a breakpoint, and we weren't stepping, then we made a 
"StopReasonSignal.

I don't understand why it was right to switch the order of attributing causes 
here, or why we no longer need the Signal fallback.

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[via lldb-commits]

@@ -229,6 +229,17 @@ bool ScriptedThread::CalculateStopInfo() {
 LLVM_PRETTY_FUNCTION, "Failed to get scripted thread stop info.", 
error,
 LLDBLog::Thread);
 
+  // If we're at a BreakpointSite, mark that we stopped there and

jimingham wrote:

Is this the code that's doing what the:

} else if (!signo) {
}

branch at 1883 in the old code was doing?

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

[Lldb-commits] [lldb] [lldb] Add frame recognizer for __builtin_verbose_trap (PR #80368)

[Michael Buch via lldb-commits]

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

>From d7c77e6ae69449985300c3909e835e35be3ba3e9 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Thu, 25 Jan 2024 11:05:02 +
Subject: [PATCH 1/5] [lldb] Add frame recognizer for __builtin_verbose_trap

This patch adds a frame recognizer for Clang's
`__builtin_verbose_trap`, which behaves like a
`__builtin_trap`, but emits a failure-reason string
into debug-info in order for debuggers to display
it to a user.

The frame recognizer triggers when we encounter
a frame with a function name that begins with
`__llvm_verbose_trap`, which is the magic prefix
Clang emits into debug-info for verbose traps.
Once such frame is encountered we display the
frame function name as the `Stop Reason` and display
that frame to the user.

Example output:
```
(lldb) run
warning: a.out was compiled with optimization - stepping may behave oddly; 
variables may not be available.
Process 35942 launched: 'a.out' (arm64)
Process 35942 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = 
__llvm_verbose_trap: Function is not implemented
frame #1: 0x00013fa4 a.out`main [inlined] 
Dummy::func(this=) at verbose_trap.cpp:3:5 [opt]
   1struct Dummy {
   2  void func() {
-> 3__builtin_verbose_trap("Function is not implemented");
   4  }
   5};
   6
   7int main() {
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = 
__llvm_verbose_trap: Function is not implemented
frame #0: 0x00013fa4 a.out`main [inlined] __llvm_verbose_trap: 
Function is not implemented at verbose_trap.cpp:0 [opt]
  * frame #1: 0x00013fa4 a.out`main [inlined] 
Dummy::func(this=) at verbose_trap.cpp:3:5 [opt]
frame #2: 0x00013fa4 a.out`main at verbose_trap.cpp:8:13 [opt]
frame #3: 0x000189d518b4 dyld`start + 1988
```
---
 .../lldb/Target/VerboseTrapFrameRecognizer.h  | 39 +
 lldb/source/Target/CMakeLists.txt |  1 +
 lldb/source/Target/Process.cpp|  2 +
 .../Target/VerboseTrapFrameRecognizer.cpp | 85 +++
 .../Shell/Recognizer/Inputs/verbose_trap.cpp  |  8 ++
 lldb/test/Shell/Recognizer/verbose_trap.test  |  9 ++
 6 files changed, 144 insertions(+)
 create mode 100644 lldb/include/lldb/Target/VerboseTrapFrameRecognizer.h
 create mode 100644 lldb/source/Target/VerboseTrapFrameRecognizer.cpp
 create mode 100644 lldb/test/Shell/Recognizer/Inputs/verbose_trap.cpp
 create mode 100644 lldb/test/Shell/Recognizer/verbose_trap.test

diff --git a/lldb/include/lldb/Target/VerboseTrapFrameRecognizer.h 
b/lldb/include/lldb/Target/VerboseTrapFrameRecognizer.h
new file mode 100644
index ..7e045760a28b
--- /dev/null
+++ b/lldb/include/lldb/Target/VerboseTrapFrameRecognizer.h
@@ -0,0 +1,39 @@
+#ifndef LLDB_TARGET_VERBOSETRAPFRAMERECOGNIZER_H
+#define LLDB_TARGET_VERBOSETRAPFRAMERECOGNIZER_H
+
+#include "lldb/Target/StackFrameRecognizer.h"
+
+namespace lldb_private {
+
+void RegisterVerboseTrapFrameRecognizer(Process &process);
+
+/// Holds the stack frame that caused the Verbose trap and the inlined stop
+/// reason message.
+class VerboseTrapRecognizedStackFrame : public RecognizedStackFrame {
+public:
+  VerboseTrapRecognizedStackFrame(lldb::StackFrameSP most_relevant_frame_sp,
+  std::string stop_desc);
+
+  lldb::StackFrameSP GetMostRelevantFrame() override;
+
+private:
+  lldb::StackFrameSP m_most_relevant_frame;
+};
+
+/// When a thread stops, it checks the current frame contains a
+/// Verbose Trap diagnostic. If so, it returns a \a
+/// VerboseTrapRecognizedStackFrame holding the diagnostic a stop reason
+/// description with and the parent frame as the most relavant frame.
+class VerboseTrapFrameRecognizer : public StackFrameRecognizer {
+public:
+  std::string GetName() override {
+return "Verbose Trap StackFrame Recognizer";
+  }
+
+  lldb::RecognizedStackFrameSP
+  RecognizeFrame(lldb::StackFrameSP frame) override;
+};
+
+} // namespace lldb_private
+
+#endif // LLDB_TARGET_VERBOSETRAPFRAMERECOGNIZER_H
diff --git a/lldb/source/Target/CMakeLists.txt 
b/lldb/source/Target/CMakeLists.txt
index cf4818eae3eb..8186ccbea27d 100644
--- a/lldb/source/Target/CMakeLists.txt
+++ b/lldb/source/Target/CMakeLists.txt
@@ -78,6 +78,7 @@ add_lldb_library(lldbTarget
   UnixSignals.cpp
   UnwindAssembly.cpp
   UnwindLLDB.cpp
+  VerboseTrapFrameRecognizer.cpp
 
   LINK_LIBS
 lldbBreakpoint
diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index dc7f6c9e86a4..e72982db987a 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -63,6 +63,7 @@
 #include "lldb/Target/ThreadPlanCallFunction.h"
 #include "lldb/Target/ThreadPlanStack.h"
 #include "lldb/Target/UnixSignals.h"
+#include "lldb/Target/VerboseTrapFrameRecognizer.h"
 #include "lldb/Utility/AddressableBits.h"
 #include "lldb/Utility/Event.h"
 #include "lldb/Utility/LLDBLog.h"
@@ -525,6 

[Lldb-commits] [lldb] Support single stopped event in lldb-dap (PR #98568)

[Walter Erquinigo via lldb-commits]

@@ -0,0 +1,91 @@
+"""
+Test lldb-dap setBreakpoints request
+"""
+
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+import lldbdap_testcase
+from lldbsuite.test import lldbutil
+
+
+class TestDAP_stopEvents(lldbdap_testcase.DAPTestCaseBase):
+@skipIfWindows
+@skipIfRemote

walter-erquinigo wrote:

You don't need `@skipIfRemote`. That decorator is automatically applied to all 
DAP functions.

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

[Lldb-commits] [lldb] [lldb][test] Enable static linking with libcxx for import-std-module tests (PR #98701)

[Vladislav Dzhidzhoev via lldb-commits]

https://github.com/dzhidzhoev created 
https://github.com/llvm/llvm-project/pull/98701

--whole-archive and --allow-multiple-definition options has been added to 
linker flags of these import-std-module tests in order to make them pass with 
libcxx static linking enabled.

Darwin has been excluded since it doesn't seem to build in this configuration.

Also, some tests were switched from system stdlib to libcxx since the problem 
described in https://reviews.llvm.org/D139361 seems to be fixed.

>From 47f541c99485e4970c4219044aae5c117e63865c Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev 
Date: Fri, 14 Jun 2024 19:00:39 +
Subject: [PATCH] [lldb][test] Enable static linking with libcxx for
 import-std-module tests

--whole-archive and --allow-multiple-definition options has been added
to linker flags of these import-std-module tests in order to make them
pass with libcxx static linking enabled.

Darwin has been excluded since it doesn't seem to build in such
configuration.

Also, some tests were switched from system stdlib to libcxx since the
problem described in https://reviews.llvm.org/D139361 seems to be fixed.
---
 .../commands/expression/import-std-module/array/Makefile | 5 +
 .../import-std-module/deque-dbg-info-content/Makefile| 9 ++---
 .../import-std-module/list-dbg-info-content/Makefile | 9 ++---
 .../import-std-module/vector-dbg-info-content/Makefile   | 9 ++---
 .../import-std-module/vector-of-vectors/Makefile | 5 +
 5 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/lldb/test/API/commands/expression/import-std-module/array/Makefile 
b/lldb/test/API/commands/expression/import-std-module/array/Makefile
index f938f7428468..b96106a55b85 100644
--- a/lldb/test/API/commands/expression/import-std-module/array/Makefile
+++ b/lldb/test/API/commands/expression/import-std-module/array/Makefile
@@ -1,3 +1,8 @@
 USE_LIBCPP := 1
 CXX_SOURCES := main.cpp
+
+ifneq ($(OS),Darwin)
+   LD_EXTRAS := -Xlinker --whole-archive -Xlinker 
--allow-multiple-definition
+endif
+
 include Makefile.rules
diff --git 
a/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile
 
b/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile
index 98638c56f0b9..b96106a55b85 100644
--- 
a/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile
+++ 
b/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile
@@ -1,5 +1,8 @@
-# FIXME: once the expression evaluator can handle std libraries with debug
-# info, change this to USE_LIBCPP=1
-USE_SYSTEM_STDLIB := 1
+USE_LIBCPP := 1
 CXX_SOURCES := main.cpp
+
+ifneq ($(OS),Darwin)
+   LD_EXTRAS := -Xlinker --whole-archive -Xlinker 
--allow-multiple-definition
+endif
+
 include Makefile.rules
diff --git 
a/lldb/test/API/commands/expression/import-std-module/list-dbg-info-content/Makefile
 
b/lldb/test/API/commands/expression/import-std-module/list-dbg-info-content/Makefile
index 98638c56f0b9..b96106a55b85 100644
--- 
a/lldb/test/API/commands/expression/import-std-module/list-dbg-info-content/Makefile
+++ 
b/lldb/test/API/commands/expression/import-std-module/list-dbg-info-content/Makefile
@@ -1,5 +1,8 @@
-# FIXME: once the expression evaluator can handle std libraries with debug
-# info, change this to USE_LIBCPP=1
-USE_SYSTEM_STDLIB := 1
+USE_LIBCPP := 1
 CXX_SOURCES := main.cpp
+
+ifneq ($(OS),Darwin)
+   LD_EXTRAS := -Xlinker --whole-archive -Xlinker 
--allow-multiple-definition
+endif
+
 include Makefile.rules
diff --git 
a/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/Makefile
 
b/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/Makefile
index 98638c56f0b9..b96106a55b85 100644
--- 
a/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/Makefile
+++ 
b/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/Makefile
@@ -1,5 +1,8 @@
-# FIXME: once the expression evaluator can handle std libraries with debug
-# info, change this to USE_LIBCPP=1
-USE_SYSTEM_STDLIB := 1
+USE_LIBCPP := 1
 CXX_SOURCES := main.cpp
+
+ifneq ($(OS),Darwin)
+   LD_EXTRAS := -Xlinker --whole-archive -Xlinker 
--allow-multiple-definition
+endif
+
 include Makefile.rules
diff --git 
a/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/Makefile
 
b/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/Makefile
index f938f7428468..b96106a55b85 100644
--- 
a/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/Makefile
+++ 
b/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/Makefile
@@ -1,3 +1,8 @@
 USE_LIBCPP := 1
 CXX_SOURCES := main.cpp
+
+ifneq ($(OS),Darwin)
+   LD_EXTRAS := -Xlinker --whole-archive -Xlinker 
--allow-multiple-definition
+endif
+
 include Makefile.rules

___
lldb-commits mailing list
lldb-commits@lists.llvm

[Lldb-commits] [lldb] [lldb][test] Enable static linking with libcxx for import-std-module tests (PR #98701)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Vladislav Dzhidzhoev (dzhidzhoev)


Changes

--whole-archive and --allow-multiple-definition options has been added to 
linker flags of these import-std-module tests in order to make them pass with 
libcxx static linking enabled.

Darwin has been excluded since it doesn't seem to build in this configuration.

Also, some tests were switched from system stdlib to libcxx since the problem 
described in https://reviews.llvm.org/D139361 seems to be fixed.

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


5 Files Affected:

- (modified) lldb/test/API/commands/expression/import-std-module/array/Makefile 
(+5) 
- (modified) 
lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile
 (+6-3) 
- (modified) 
lldb/test/API/commands/expression/import-std-module/list-dbg-info-content/Makefile
 (+6-3) 
- (modified) 
lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/Makefile
 (+6-3) 
- (modified) 
lldb/test/API/commands/expression/import-std-module/vector-of-vectors/Makefile 
(+5) 


``diff
diff --git a/lldb/test/API/commands/expression/import-std-module/array/Makefile 
b/lldb/test/API/commands/expression/import-std-module/array/Makefile
index f938f7428468..b96106a55b85 100644
--- a/lldb/test/API/commands/expression/import-std-module/array/Makefile
+++ b/lldb/test/API/commands/expression/import-std-module/array/Makefile
@@ -1,3 +1,8 @@
 USE_LIBCPP := 1
 CXX_SOURCES := main.cpp
+
+ifneq ($(OS),Darwin)
+   LD_EXTRAS := -Xlinker --whole-archive -Xlinker 
--allow-multiple-definition
+endif
+
 include Makefile.rules
diff --git 
a/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile
 
b/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile
index 98638c56f0b9..b96106a55b85 100644
--- 
a/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile
+++ 
b/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile
@@ -1,5 +1,8 @@
-# FIXME: once the expression evaluator can handle std libraries with debug
-# info, change this to USE_LIBCPP=1
-USE_SYSTEM_STDLIB := 1
+USE_LIBCPP := 1
 CXX_SOURCES := main.cpp
+
+ifneq ($(OS),Darwin)
+   LD_EXTRAS := -Xlinker --whole-archive -Xlinker 
--allow-multiple-definition
+endif
+
 include Makefile.rules
diff --git 
a/lldb/test/API/commands/expression/import-std-module/list-dbg-info-content/Makefile
 
b/lldb/test/API/commands/expression/import-std-module/list-dbg-info-content/Makefile
index 98638c56f0b9..b96106a55b85 100644
--- 
a/lldb/test/API/commands/expression/import-std-module/list-dbg-info-content/Makefile
+++ 
b/lldb/test/API/commands/expression/import-std-module/list-dbg-info-content/Makefile
@@ -1,5 +1,8 @@
-# FIXME: once the expression evaluator can handle std libraries with debug
-# info, change this to USE_LIBCPP=1
-USE_SYSTEM_STDLIB := 1
+USE_LIBCPP := 1
 CXX_SOURCES := main.cpp
+
+ifneq ($(OS),Darwin)
+   LD_EXTRAS := -Xlinker --whole-archive -Xlinker 
--allow-multiple-definition
+endif
+
 include Makefile.rules
diff --git 
a/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/Makefile
 
b/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/Makefile
index 98638c56f0b9..b96106a55b85 100644
--- 
a/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/Makefile
+++ 
b/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/Makefile
@@ -1,5 +1,8 @@
-# FIXME: once the expression evaluator can handle std libraries with debug
-# info, change this to USE_LIBCPP=1
-USE_SYSTEM_STDLIB := 1
+USE_LIBCPP := 1
 CXX_SOURCES := main.cpp
+
+ifneq ($(OS),Darwin)
+   LD_EXTRAS := -Xlinker --whole-archive -Xlinker 
--allow-multiple-definition
+endif
+
 include Makefile.rules
diff --git 
a/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/Makefile
 
b/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/Makefile
index f938f7428468..b96106a55b85 100644
--- 
a/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/Makefile
+++ 
b/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/Makefile
@@ -1,3 +1,8 @@
 USE_LIBCPP := 1
 CXX_SOURCES := main.cpp
+
+ifneq ($(OS),Darwin)
+   LD_EXTRAS := -Xlinker --whole-archive -Xlinker 
--allow-multiple-definition
+endif
+
 include Makefile.rules

``




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

[Lldb-commits] [lldb] [lldb][test] Enable static linking with libcxx for import-std-module tests (PR #98701)

[Vladislav Dzhidzhoev via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][test] Enable static linking with libcxx for import-std-module tests (PR #98701)

[Michael Buch via lldb-commits]

@@ -1,5 +1,8 @@
-# FIXME: once the expression evaluator can handle std libraries with debug
-# info, change this to USE_LIBCPP=1
-USE_SYSTEM_STDLIB := 1

Michael137 wrote:

Is this related to the linker flag changes in any way? We rely on this on the 
macOS bots, so it doesn't sound like the underlying issue the FIXME referred to 
was resolved. If it's an unrelated change, I'd prefer opening a separate PR for 
these

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

[Lldb-commits] [lldb] [lldb][test] Enable static linking with libcxx for import-std-module tests (PR #98701)

[Michael Buch via lldb-commits]

@@ -1,3 +1,8 @@
 USE_LIBCPP := 1
 CXX_SOURCES := main.cpp
+
+ifneq ($(OS),Darwin)
+   LD_EXTRAS := -Xlinker --whole-archive -Xlinker 
--allow-multiple-definition

Michael137 wrote:

Can you elaborate on why this is necessary? Example test failures would be great

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

[Lldb-commits] [lldb] [lldb] Add frame recognizer for __builtin_verbose_trap (PR #80368)

[Dan Liew via lldb-commits]

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

Looks pretty good. I had a few minor comments

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

[Lldb-commits] [lldb] [lldb] Add frame recognizer for __builtin_verbose_trap (PR #80368)

[Dan Liew via lldb-commits]

@@ -0,0 +1,122 @@
+#include "lldb/Target/VerboseTrapFrameRecognizer.h"
+
+#include "lldb/Core/Module.h"
+#include "lldb/Symbol/Function.h"
+#include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Target/StackFrameRecognizer.h"
+#include "lldb/Target/Target.h"
+
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+
+#include "clang/CodeGen/ModuleBuilder.h"
+
+using namespace llvm;
+using namespace lldb;
+using namespace lldb_private;
+
+VerboseTrapRecognizedStackFrame::VerboseTrapRecognizedStackFrame(
+StackFrameSP most_relevant_frame_sp, std::string stop_desc)
+: m_most_relevant_frame(most_relevant_frame_sp) {
+  m_stop_desc = std::move(stop_desc);
+}
+
+lldb::RecognizedStackFrameSP
+VerboseTrapFrameRecognizer::RecognizeFrame(lldb::StackFrameSP frame_sp) {
+  if (frame_sp->GetFrameIndex())
+return {};
+
+  ThreadSP thread_sp = frame_sp->GetThread();
+  ProcessSP process_sp = thread_sp->GetProcess();
+
+  StackFrameSP most_relevant_frame_sp = thread_sp->GetStackFrameAtIndex(1);

delcypher wrote:

Is there anyway for there to not be a stack frame at index 1? If that's 
possible could we bail out early so we don't crash/have bad behavior?

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