[Lldb-commits] [lldb] Reapply "[lldb/aarch64] Fix unwinding when signal interrupts a leaf f… (PR #92503)

2024-05-21 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

as cool as this idea is, I do worry that it will make the code less readable, 
where instead of saying "BehavesLikeFrameZero / HasAllRegisters", we now need 
to ask "can the frame below supply register x", I don't know.  it's just 
something I have running around my head today.

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


[Lldb-commits] [lldb] [LLDB] Add more helper functions to ValueObject class. (PR #87197)

2024-05-21 Thread via lldb-commits


@@ -719,6 +776,10 @@ class ValueObject {
 ClearUserVisibleData(eClearUserVisibleDataItemsSummary);
   }
 
+  void SetDerefValobj(ValueObject *deref) { m_deref_valobj = deref; }

cmtice wrote:

I use the synthetic child providers way of getting the deref ValueObject  to 
get the value I use for my call to SetDerefValobj (when I'm converting a 
ValueObject containing a SmartPointer into a ValueObject containing the pointer 
the SmartPointer was referencing).



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


[Lldb-commits] [clang] [libcxx] [lldb] [llvm] [mlir] [BOLT][BAT] Add entries for deleted basic blocks (PR #91906)

2024-05-21 Thread Rafael Auler via lldb-commits

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

Could you elaborate a bit better on why do we need a deleted block to be 
present in the table? My memory fails me, aren't we using the translation table 
just to map samples collected on the bolted binary? Where do the deleted blocks 
become a problem?

Other than the motivation, the implementation itself looks good to me.

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


[Lldb-commits] [lldb] SBDebugger: define callback_token_t for win32 (PR #92870)

2024-05-21 Thread via lldb-commits

royitaqi wrote:

Thanks to @antmox and @labath for fixing this. My apologies for breaking the 
build.

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


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-21 Thread via lldb-commits

royitaqi wrote:

Hi @antmox,

I'm sorry that it broke the lldb-aarch64-windows build. My bad. Your fix makes 
sense, though I do have the same comment as @labath had, i.e. to move that 
typedef outside platform-specific region. From the latest comments in that PR 
it seems it's already got moved. If that's the case then I think we are all 
good.

My apologies that I didn't respond earlier - I was watching my email and the 
build bot (https://lab.llvm.org/buildbot/#/changes/134099), saw all green and I 
thought it's went well.   **Questions for my learning** (I'm noob to all 
these): I realize that the build bot I quoted didn't run the windows build you 
mentioned (lldb-aarch64-windows). This tells me that there are multiple build 
bots that I need to watch in the future. **Is there an exhaustive list 
somewhere?** Email obviously failed to inform me about the build break (i.e. I 
searched for "lldb-aarch64-windows" in my email and nothing except your 
message).

Thanks,
Roy

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


[Lldb-commits] [lldb] Change GetChildCompilerTypeAtIndex to return Expected (NFC) (PR #92979)

2024-05-21 Thread via lldb-commits

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff 0bc710f7c19910817ccff254c43496602635bbc9 
8a6202f8ae92a62ce577271ec580379f1424f9e3 -- 
lldb/include/lldb/Symbol/CompilerType.h lldb/include/lldb/Symbol/TypeSystem.h 
lldb/source/Core/ValueObject.cpp 
lldb/source/Core/ValueObjectConstResultImpl.cpp 
lldb/source/Plugins/ABI/PowerPC/ABISysV_ppc64.cpp 
lldb/source/Plugins/Language/CPlusPlus/BlockPointer.cpp 
lldb/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h 
lldb/source/Symbol/CompilerType.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
index d4cc47b454..0929d49e55 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
@@ -295,12 +295,12 @@ void 
lldb_private::formatters::LibcxxStdMapSyntheticFrontEnd::GetValueOffset(
 bool child_is_base_class;
 bool child_is_deref_of_parent;
 uint64_t language_flags;
-auto child_type = llvm::expectedToStdOptional(tree_node_type
-.GetChildCompilerTypeAtIndex(
-nullptr, 4, true, true, true, child_name, child_byte_size,
-child_byte_offset, child_bitfield_bit_size,
-child_bitfield_bit_offset, child_is_base_class,
-child_is_deref_of_parent, nullptr, language_flags));
+auto child_type =
+llvm::expectedToStdOptional(tree_node_type.GetChildCompilerTypeAtIndex(
+nullptr, 4, true, true, true, child_name, child_byte_size,
+child_byte_offset, child_bitfield_bit_size,
+child_bitfield_bit_offset, child_is_base_class,
+child_is_deref_of_parent, nullptr, language_flags));
 if (child_type && child_type->IsValid())
   m_skip_size = (uint32_t)child_byte_offset;
   }

``




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


[Lldb-commits] [lldb] Change GetChildCompilerTypeAtIndex to return Expected (NFC) (PR #92979)

2024-05-21 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Adrian Prantl (adrian-prantl)


Changes

This change is a general improvement of the internal API. My motivation is to 
use this in the Swift typesystem plugin.

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


10 Files Affected:

- (modified) lldb/include/lldb/Symbol/CompilerType.h (+1-1) 
- (modified) lldb/include/lldb/Symbol/TypeSystem.h (+1-1) 
- (modified) lldb/source/Core/ValueObject.cpp (+23-8) 
- (modified) lldb/source/Core/ValueObjectConstResultImpl.cpp (+10-2) 
- (modified) lldb/source/Plugins/ABI/PowerPC/ABISysV_ppc64.cpp (+2-1) 
- (modified) lldb/source/Plugins/Language/CPlusPlus/BlockPointer.cpp (+11-7) 
- (modified) lldb/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp (+3-3) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp (+10-8) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h (+1-1) 
- (modified) lldb/source/Symbol/CompilerType.cpp (+1-1) 


``diff
diff --git a/lldb/include/lldb/Symbol/CompilerType.h 
b/lldb/include/lldb/Symbol/CompilerType.h
index 28c723abf2794..70dacdcb7986f 100644
--- a/lldb/include/lldb/Symbol/CompilerType.h
+++ b/lldb/include/lldb/Symbol/CompilerType.h
@@ -436,7 +436,7 @@ class CompilerType {
uint32_t *bitfield_bit_size_ptr = nullptr,
bool *is_bitfield_ptr = nullptr) const;
 
-  CompilerType GetChildCompilerTypeAtIndex(
+  llvm::Expected GetChildCompilerTypeAtIndex(
   ExecutionContext *exe_ctx, size_t idx, bool transparent_pointers,
   bool omit_empty_base_classes, bool ignore_array_bounds,
   std::string &child_name, uint32_t &child_byte_size,
diff --git a/lldb/include/lldb/Symbol/TypeSystem.h 
b/lldb/include/lldb/Symbol/TypeSystem.h
index 7bcb8d69387a0..b4025c173a186 100644
--- a/lldb/include/lldb/Symbol/TypeSystem.h
+++ b/lldb/include/lldb/Symbol/TypeSystem.h
@@ -359,7 +359,7 @@ class TypeSystem : public PluginInterface,
 return CompilerDecl();
   }
 
-  virtual CompilerType GetChildCompilerTypeAtIndex(
+  virtual llvm::Expected GetChildCompilerTypeAtIndex(
   lldb::opaque_compiler_type_t type, ExecutionContext *exe_ctx, size_t idx,
   bool transparent_pointers, bool omit_empty_base_classes,
   bool ignore_array_bounds, std::string &child_name,
diff --git a/lldb/source/Core/ValueObject.cpp b/lldb/source/Core/ValueObject.cpp
index f39bd07a25536..1443d9dfc3280 100644
--- a/lldb/source/Core/ValueObject.cpp
+++ b/lldb/source/Core/ValueObject.cpp
@@ -505,15 +505,23 @@ ValueObject *ValueObject::CreateChildAtIndex(size_t idx,
   uint64_t language_flags = 0;
 
   const bool transparent_pointers = !synthetic_array_member;
-  CompilerType child_compiler_type;
 
   ExecutionContext exe_ctx(GetExecutionContextRef());
 
-  child_compiler_type = GetCompilerType().GetChildCompilerTypeAtIndex(
-  &exe_ctx, idx, transparent_pointers, omit_empty_base_classes,
-  ignore_array_bounds, child_name_str, child_byte_size, child_byte_offset,
-  child_bitfield_bit_size, child_bitfield_bit_offset, child_is_base_class,
-  child_is_deref_of_parent, this, language_flags);
+  auto child_compiler_type_or_err =
+  GetCompilerType().GetChildCompilerTypeAtIndex(
+  &exe_ctx, idx, transparent_pointers, omit_empty_base_classes,
+  ignore_array_bounds, child_name_str, child_byte_size,
+  child_byte_offset, child_bitfield_bit_size, 
child_bitfield_bit_offset,
+  child_is_base_class, child_is_deref_of_parent, this, language_flags);
+  CompilerType child_compiler_type;
+  if (!child_compiler_type_or_err)
+LLDB_LOG_ERROR(GetLog(LLDBLog::Types),
+   child_compiler_type_or_err.takeError(),
+   "could not find child: {0}");
+  else
+child_compiler_type = *child_compiler_type_or_err;
+
   if (child_compiler_type) {
 if (synthetic_index)
   child_byte_offset += child_byte_size * synthetic_index;
@@ -2624,16 +2632,23 @@ ValueObjectSP ValueObject::Dereference(Status &error) {
 bool child_is_deref_of_parent = false;
 const bool transparent_pointers = false;
 CompilerType compiler_type = GetCompilerType();
-CompilerType child_compiler_type;
 uint64_t language_flags = 0;
 
 ExecutionContext exe_ctx(GetExecutionContextRef());
 
-child_compiler_type = compiler_type.GetChildCompilerTypeAtIndex(
+CompilerType child_compiler_type;
+auto child_compiler_type_or_err = 
compiler_type.GetChildCompilerTypeAtIndex(
 &exe_ctx, 0, transparent_pointers, omit_empty_base_classes,
 ignore_array_bounds, child_name_str, child_byte_size, 
child_byte_offset,
 child_bitfield_bit_size, child_bitfield_bit_offset, 
child_is_base_class,
 child_is_deref_of_parent, this, language_flags);
+if (!child_compiler_type_or_err)
+  LLDB_LOG_ERROR(GetLog(LLDBLog::Types),
+ child_compiler_type_or_err.takeError(),
+ "coul

[Lldb-commits] [lldb] Change GetChildCompilerTypeAtIndex to return Expected (NFC) (PR #92979)

2024-05-21 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl created 
https://github.com/llvm/llvm-project/pull/92979

This change is a general improvement of the internal API. My motivation is to 
use this in the Swift typesystem plugin.

>From 8a6202f8ae92a62ce577271ec580379f1424f9e3 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Tue, 21 May 2024 17:41:31 -0700
Subject: [PATCH] Change GetChildCompilerTypeAtIndex to return Expected (NFC)

---
 lldb/include/lldb/Symbol/CompilerType.h   |  2 +-
 lldb/include/lldb/Symbol/TypeSystem.h |  2 +-
 lldb/source/Core/ValueObject.cpp  | 31 ++-
 .../Core/ValueObjectConstResultImpl.cpp   | 12 +--
 .../Plugins/ABI/PowerPC/ABISysV_ppc64.cpp |  3 +-
 .../Language/CPlusPlus/BlockPointer.cpp   | 18 ++-
 .../Plugins/Language/CPlusPlus/LibCxxMap.cpp  |  6 ++--
 .../TypeSystem/Clang/TypeSystemClang.cpp  | 18 ++-
 .../TypeSystem/Clang/TypeSystemClang.h|  2 +-
 lldb/source/Symbol/CompilerType.cpp   |  2 +-
 10 files changed, 63 insertions(+), 33 deletions(-)

diff --git a/lldb/include/lldb/Symbol/CompilerType.h 
b/lldb/include/lldb/Symbol/CompilerType.h
index 28c723abf2794..70dacdcb7986f 100644
--- a/lldb/include/lldb/Symbol/CompilerType.h
+++ b/lldb/include/lldb/Symbol/CompilerType.h
@@ -436,7 +436,7 @@ class CompilerType {
uint32_t *bitfield_bit_size_ptr = nullptr,
bool *is_bitfield_ptr = nullptr) const;
 
-  CompilerType GetChildCompilerTypeAtIndex(
+  llvm::Expected GetChildCompilerTypeAtIndex(
   ExecutionContext *exe_ctx, size_t idx, bool transparent_pointers,
   bool omit_empty_base_classes, bool ignore_array_bounds,
   std::string &child_name, uint32_t &child_byte_size,
diff --git a/lldb/include/lldb/Symbol/TypeSystem.h 
b/lldb/include/lldb/Symbol/TypeSystem.h
index 7bcb8d69387a0..b4025c173a186 100644
--- a/lldb/include/lldb/Symbol/TypeSystem.h
+++ b/lldb/include/lldb/Symbol/TypeSystem.h
@@ -359,7 +359,7 @@ class TypeSystem : public PluginInterface,
 return CompilerDecl();
   }
 
-  virtual CompilerType GetChildCompilerTypeAtIndex(
+  virtual llvm::Expected GetChildCompilerTypeAtIndex(
   lldb::opaque_compiler_type_t type, ExecutionContext *exe_ctx, size_t idx,
   bool transparent_pointers, bool omit_empty_base_classes,
   bool ignore_array_bounds, std::string &child_name,
diff --git a/lldb/source/Core/ValueObject.cpp b/lldb/source/Core/ValueObject.cpp
index f39bd07a25536..1443d9dfc3280 100644
--- a/lldb/source/Core/ValueObject.cpp
+++ b/lldb/source/Core/ValueObject.cpp
@@ -505,15 +505,23 @@ ValueObject *ValueObject::CreateChildAtIndex(size_t idx,
   uint64_t language_flags = 0;
 
   const bool transparent_pointers = !synthetic_array_member;
-  CompilerType child_compiler_type;
 
   ExecutionContext exe_ctx(GetExecutionContextRef());
 
-  child_compiler_type = GetCompilerType().GetChildCompilerTypeAtIndex(
-  &exe_ctx, idx, transparent_pointers, omit_empty_base_classes,
-  ignore_array_bounds, child_name_str, child_byte_size, child_byte_offset,
-  child_bitfield_bit_size, child_bitfield_bit_offset, child_is_base_class,
-  child_is_deref_of_parent, this, language_flags);
+  auto child_compiler_type_or_err =
+  GetCompilerType().GetChildCompilerTypeAtIndex(
+  &exe_ctx, idx, transparent_pointers, omit_empty_base_classes,
+  ignore_array_bounds, child_name_str, child_byte_size,
+  child_byte_offset, child_bitfield_bit_size, 
child_bitfield_bit_offset,
+  child_is_base_class, child_is_deref_of_parent, this, language_flags);
+  CompilerType child_compiler_type;
+  if (!child_compiler_type_or_err)
+LLDB_LOG_ERROR(GetLog(LLDBLog::Types),
+   child_compiler_type_or_err.takeError(),
+   "could not find child: {0}");
+  else
+child_compiler_type = *child_compiler_type_or_err;
+
   if (child_compiler_type) {
 if (synthetic_index)
   child_byte_offset += child_byte_size * synthetic_index;
@@ -2624,16 +2632,23 @@ ValueObjectSP ValueObject::Dereference(Status &error) {
 bool child_is_deref_of_parent = false;
 const bool transparent_pointers = false;
 CompilerType compiler_type = GetCompilerType();
-CompilerType child_compiler_type;
 uint64_t language_flags = 0;
 
 ExecutionContext exe_ctx(GetExecutionContextRef());
 
-child_compiler_type = compiler_type.GetChildCompilerTypeAtIndex(
+CompilerType child_compiler_type;
+auto child_compiler_type_or_err = 
compiler_type.GetChildCompilerTypeAtIndex(
 &exe_ctx, 0, transparent_pointers, omit_empty_base_classes,
 ignore_array_bounds, child_name_str, child_byte_size, 
child_byte_offset,
 child_bitfield_bit_size, child_bitfield_bit_offset, 
child_is_base_class,
 child_is_deref_of_parent, this, language_flags);
+if (!child_compiler_type_or_err)
+  LLDB_LOG_ERROR(GetLog(LLDBLog::Types),
+

[Lldb-commits] [lldb] Reapply "[lldb/aarch64] Fix unwinding when signal interrupts a leaf f… (PR #92503)

2024-05-21 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

(with the caveat that a register location of IsSame for a volatile aka 
non-callee-spilled register would be treated as "did not have a location")

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


[Lldb-commits] [clang] [lldb] [llvm] Remove some `try_compile` CMake checks for compiler flags (PR #92953)

2024-05-21 Thread Jonas Devlieghere via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb] Fixed the TestDebuggerAPI test on x86_64 Windows host (PR #90580)

2024-05-21 Thread Dmitry Vasilyev via lldb-commits

slydiman wrote:

We are almost done with configuring the buildbot for cross lldb (Windows x86_64 
host and Linux Aarch64 target). We are trying to get it green with minimal 
local patches.

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


[Lldb-commits] [lldb] Reapply "[lldb/aarch64] Fix unwinding when signal interrupts a leaf f… (PR #92503)

2024-05-21 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

We should be able to work correctly with a trap handler that has full eh_frame 
without knowing the function name.  And we shouldn't treat a sigtramp missing 
eh_frame as having all registers.

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


[Lldb-commits] [lldb] Reapply "[lldb/aarch64] Fix unwinding when signal interrupts a leaf f… (PR #92503)

2024-05-21 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

btw @labath I was thinking about "sigtramp routines" and fault / trap / 
interrupt handlers in general, and how lldb has this list of function names 
that it treats as fault handlers (`target.trap-handler-names`).  And in the 
unwinder we have the same idea of "the frame above a designed 
sigtramp/fault/trap/interrupt function can retrieve all registers".  

But what if the unwinder had a method saying "Do you have an unwind rule to 
give me a value for register n, without iterating down the stack?"   e.g. frame 
5 is interrupted and frame 4 is sigtramp, with full eh_frame.  From frame 5, I 
can say "does frame 4 have an unwind rule to provide x0, without iterating down 
to frame 3, etc."   This also means if we have a sigtramp which is missing its 
eh_frame, we won't apply our "all registers available" rules to the frame above.

An interesting case for a return-address target like aarch64 where normally 
when we ask for a caller frame's pc, we fetch the link register.  But above a 
fault/trap/interrupt frame, we can retrieve both the pc and the link register 
and they are different values.

Just something I started kicking around in my head, I don't have concrete plans 
to implement an overhaul like this but the more I think about it, the more I 
like it.

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


[Lldb-commits] [clang] [lldb] [llvm] Remove some `try_compile` CMake checks for compiler flags (PR #92953)

2024-05-21 Thread Arthur Eubanks via lldb-commits

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

awesome, thanks!

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


[Lldb-commits] [clang] [lldb] [llvm] Remove some `try_compile` CMake checks for compiler flags (PR #92953)

2024-05-21 Thread via lldb-commits

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


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


[Lldb-commits] [lldb] A few updates around "transcript" (PR #92843)

2024-05-21 Thread via lldb-commits

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


[Lldb-commits] [lldb] A few updates around "transcript" (PR #92843)

2024-05-21 Thread via lldb-commits

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


[Lldb-commits] [lldb] A few updates around "transcript" (PR #92843)

2024-05-21 Thread via lldb-commits

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


[Lldb-commits] [lldb] A few updates around "transcript" (PR #92843)

2024-05-21 Thread via lldb-commits


@@ -362,6 +363,36 @@ llvm::json::Value DebuggerStats::ReportStatistics(
 global_stats.try_emplace("modules", std::move(json_modules));
 global_stats.try_emplace("memory", std::move(json_memory));
 global_stats.try_emplace("commands", std::move(cmd_stats));
+
+// When transcript is available, add it to the to-be-returned statistics.
+//
+// NOTE:
+// When the statistics is polled by an LLDB command:
+// - The transcript in the returned statistics *will NOT* contain the
+//   returned statistics itself.
+// - The returned statistics *will* be written to the internal transcript
+//   buffer as the output of the said LLDB command. It *will* appear in
+//   the next statistcs or transcript poll.
+//
+// For example, let's say the following commands are run in order:
+// - "version"
+// - "statistics dump"  <- call it "A"
+// - "statistics dump"  <- call it "B"
+// The output of "A" will contain the transcript of "version" and
+// "statistics dump" (A), with the latter having empty output. The output
+// of B will contain the trascnript of "version", "statistics dump" (A),
+// "statistics dump" (B), with A's output populated and B's output empty.

royitaqi wrote:

I feel the quoted behavior is a bit difficult to understand/reason.

--

A (cleaner) alternative behavior might to completely remove the output of 
"statistics dump" commands in the "transcript" in the "statistics dump":
```
(lldb) statistics dump
{
  ...,
  "transcript" : [
{
  "command": "version",
  "output": "Meta LLDB version ...",
  ...
},
{
  "command": "statistics dump",
  "output": "(wiped empty)",
},
  ]
}
```

--

@clayborg  Which behavior do you think is better?

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Miro Bucko via lldb-commits


@@ -0,0 +1,65 @@
+//===-- SBAddressRange.h *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGE_H
+#define LLDB_API_SBADDRESSRANGE_H
+
+#include "lldb/API/SBDefines.h"
+
+namespace lldb {
+
+class LLDB_API SBAddressRange {
+public:
+  SBAddressRange();
+
+  SBAddressRange(const lldb::SBAddressRange &rhs);
+
+  SBAddressRange(lldb::SBAddress addr, lldb::addr_t byte_size);
+
+  ~SBAddressRange();
+
+  const lldb::SBAddressRange &operator=(const lldb::SBAddressRange &rhs);
+
+  void Clear();
+
+  /// Check the address range refers to a valid base address and has a byte
+  /// size greater than zero.
+  ///
+  /// \return
+  /// True if the address range is valid, false otherwise.
+  bool IsValid() const;
+
+  /// Get the base address of the range.
+  ///
+  /// \return
+  /// Base address object.
+  lldb::SBAddress GetBaseAddress() const;
+
+  /// Get the byte size of this range.
+  ///
+  /// \return
+  /// The size in bytes of this address range.
+  lldb::addr_t GetByteSize() const;
+
+  bool operator==(const SBAddressRange &rhs);
+
+  bool operator!=(const SBAddressRange &rhs);
+
+  bool GetDescription(lldb::SBStream &description, SBTarget *target);

mbucko wrote:

Target might be null though

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Alex Langford via lldb-commits


@@ -0,0 +1,91 @@
+//===-- SBAddressRangeList.cpp 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRangeList.h"
+#include "Utils.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/API/SBStream.h"
+#include "lldb/Core/AddressRangeListImpl.h"
+#include "lldb/Utility/Instrumentation.h"
+#include "lldb/Utility/Stream.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRangeList::SBAddressRangeList()
+: m_opaque_up(new AddressRangeListImpl()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRangeList::SBAddressRangeList(const SBAddressRangeList &rhs)
+: m_opaque_up(new AddressRangeListImpl(*rhs.m_opaque_up)) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+}
+
+SBAddressRangeList::~SBAddressRangeList() = default;
+
+const SBAddressRangeList &
+SBAddressRangeList::operator=(const SBAddressRangeList &rhs) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (this != &rhs)
+*m_opaque_up = *rhs.m_opaque_up;
+  return *this;
+}
+
+uint32_t SBAddressRangeList::GetSize() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  return m_opaque_up->GetSize();
+}
+
+SBAddressRange SBAddressRangeList::GetAddressRangeAtIndex(uint64_t idx) {
+  LLDB_INSTRUMENT_VA(this, idx);
+
+  SBAddressRange sb_addr_range;
+  (*sb_addr_range.m_opaque_up) = m_opaque_up->GetAddressRangeAtIndex(idx);
+  return sb_addr_range;
+}
+
+void SBAddressRangeList::Clear() {
+  LLDB_INSTRUMENT_VA(this);
+
+  m_opaque_up->Clear();
+}
+
+void SBAddressRangeList::Append(const SBAddressRange &sb_addr_range) {
+  LLDB_INSTRUMENT_VA(this, sb_addr_range);
+
+  m_opaque_up->Append(*sb_addr_range.m_opaque_up);
+}
+
+void SBAddressRangeList::Append(const SBAddressRangeList &sb_addr_range_list) {
+  LLDB_INSTRUMENT_VA(this, sb_addr_range_list);
+
+  m_opaque_up->Append(*sb_addr_range_list.m_opaque_up);
+}
+
+bool SBAddressRangeList::GetDescription(SBStream &description,
+SBTarget *target) {
+  LLDB_INSTRUMENT_VA(this, description);
+
+  const uint32_t num_ranges = GetSize();
+  bool is_first = true;
+  Stream &stream = description.ref();
+  stream << "[";
+  for (uint32_t i = 0; i < num_ranges; ++i) {
+if (is_first) {
+  is_first = false;
+} else {
+  stream.Printf(", ");
+}

bulbazord wrote:

Oh, yes, I see. That was definitely my mistake, sorry for the noise.

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Miro Bucko via lldb-commits

https://github.com/mbucko updated 
https://github.com/llvm/llvm-project/pull/92014

>From bcca8420736283bf564cf86e1442f023ba63b9e9 Mon Sep 17 00:00:00 2001
From: Miro Bucko 
Date: Fri, 10 May 2024 12:42:03 -0700
Subject: [PATCH] Add AddressRange to SB API

Summary:
This adds new SB API calls and classes to allow a user of the SB API to
obtain an address range from SBFunction and SBBlock.

Test Plan:
llvm-lit -sv 
llvm-project/lldb/test/API/python_api/address_range/TestAddressRange.py

Reviewers: clayborg

Subscribers: lldb-commits

Tasks:

Tags:
---
 lldb/bindings/headers.swig|   2 +
 .../interface/SBAddressRangeDocstrings.i  |   3 +
 .../interface/SBAddressRangeExtensions.i  |  11 +
 .../interface/SBAddressRangeListDocstrings.i  |   3 +
 .../interface/SBAddressRangeListExtensions.i  |  28 ++
 lldb/bindings/interfaces.swig |   6 +
 lldb/include/lldb/API/LLDB.h  |   2 +
 lldb/include/lldb/API/SBAddress.h |   1 +
 lldb/include/lldb/API/SBAddressRange.h|  65 +
 lldb/include/lldb/API/SBAddressRangeList.h|  54 
 lldb/include/lldb/API/SBBlock.h   |   4 +
 lldb/include/lldb/API/SBDefines.h |   2 +
 lldb/include/lldb/API/SBFunction.h|   3 +
 lldb/include/lldb/API/SBStream.h  |   2 +
 lldb/include/lldb/API/SBTarget.h  |   1 +
 lldb/include/lldb/Core/AddressRange.h |  14 +
 lldb/include/lldb/Core/AddressRangeListImpl.h |  51 
 lldb/include/lldb/Symbol/Block.h  |   2 +
 lldb/include/lldb/lldb-forward.h  |   3 +
 lldb/source/API/CMakeLists.txt|   2 +
 lldb/source/API/SBAddressRange.cpp| 103 
 lldb/source/API/SBAddressRangeList.cpp|  93 +++
 lldb/source/API/SBBlock.cpp   |  10 +
 lldb/source/API/SBFunction.cpp|  14 +
 lldb/source/Core/AddressRange.cpp |  43 
 lldb/source/Core/AddressRangeListImpl.cpp |  50 
 lldb/source/Core/CMakeLists.txt   |   1 +
 lldb/source/Symbol/Block.cpp  |  16 ++
 .../API/python_api/address_range/Makefile |   3 +
 .../address_range/TestAddressRange.py | 240 ++
 .../API/python_api/address_range/main.cpp |   8 +
 31 files changed, 840 insertions(+)
 create mode 100644 lldb/bindings/interface/SBAddressRangeDocstrings.i
 create mode 100644 lldb/bindings/interface/SBAddressRangeExtensions.i
 create mode 100644 lldb/bindings/interface/SBAddressRangeListDocstrings.i
 create mode 100644 lldb/bindings/interface/SBAddressRangeListExtensions.i
 create mode 100644 lldb/include/lldb/API/SBAddressRange.h
 create mode 100644 lldb/include/lldb/API/SBAddressRangeList.h
 create mode 100644 lldb/include/lldb/Core/AddressRangeListImpl.h
 create mode 100644 lldb/source/API/SBAddressRange.cpp
 create mode 100644 lldb/source/API/SBAddressRangeList.cpp
 create mode 100644 lldb/source/Core/AddressRangeListImpl.cpp
 create mode 100644 lldb/test/API/python_api/address_range/Makefile
 create mode 100644 lldb/test/API/python_api/address_range/TestAddressRange.py
 create mode 100644 lldb/test/API/python_api/address_range/main.cpp

diff --git a/lldb/bindings/headers.swig b/lldb/bindings/headers.swig
index ffdc3c31ec883..c91504604b6ac 100644
--- a/lldb/bindings/headers.swig
+++ b/lldb/bindings/headers.swig
@@ -8,6 +8,8 @@
 %{
 #include "lldb/lldb-public.h"
 #include "lldb/API/SBAddress.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/API/SBAddressRangeList.h"
 #include "lldb/API/SBAttachInfo.h"
 #include "lldb/API/SBBlock.h"
 #include "lldb/API/SBBreakpoint.h"
diff --git a/lldb/bindings/interface/SBAddressRangeDocstrings.i 
b/lldb/bindings/interface/SBAddressRangeDocstrings.i
new file mode 100644
index 0..650195704d73e
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeDocstrings.i
@@ -0,0 +1,3 @@
+%feature("docstring",
+"API clients can get address range information."
+) lldb::SBAddressRange;
diff --git a/lldb/bindings/interface/SBAddressRangeExtensions.i 
b/lldb/bindings/interface/SBAddressRangeExtensions.i
new file mode 100644
index 0..9ff8e78080eb2
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeExtensions.i
@@ -0,0 +1,11 @@
+%extend lldb::SBAddressRange {
+#ifdef SWIGPYTHON
+%pythoncode%{
+  def __repr__(self):
+import lldb
+stream = lldb.SBStream()
+self.GetDescription(stream, lldb.target)
+return stream.GetData()
+%}
+#endif
+}
diff --git a/lldb/bindings/interface/SBAddressRangeListDocstrings.i 
b/lldb/bindings/interface/SBAddressRangeListDocstrings.i
new file mode 100644
index 0..e4b96b9ca5931
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeListDocstrings.i
@@ -0,0 +1,3 @@
+%feature("docstring",
+"Represents a list of :py:class:`SBAddressRange`."
+) lldb::SBAddressRangeList;
diff --git a/lldb/bindings/interface/SBAddressRangeListExtensions.i 
b/lldb/bindings

[Lldb-commits] [clang] [lldb] [llvm] Remove some `try_compile` CMake checks for compiler flags (PR #92953)

2024-05-21 Thread Fangrui Song via lldb-commits

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

Great 👍 

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


[Lldb-commits] [clang] [lldb] [llvm] Remove some `try_compile` CMake checks for compiler flags (PR #92953)

2024-05-21 Thread Vlad Serebrennikov via lldb-commits

Endilll wrote:

Here are CE links with the set of minimum required compilers that should cover 
almost all the changes I made:
https://godbolt.org/z/j98xzhrGa
https://godbolt.org/z/errv4WhfP
https://godbolt.org/z/vnoh8YqEP
Windows-targeted flags were tested both on MSVC on CE, and on clang-cl 5.0 
locally.

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Miro Bucko via lldb-commits


@@ -0,0 +1,91 @@
+//===-- SBAddressRangeList.cpp 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRangeList.h"
+#include "Utils.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/API/SBStream.h"
+#include "lldb/Core/AddressRangeListImpl.h"
+#include "lldb/Utility/Instrumentation.h"
+#include "lldb/Utility/Stream.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRangeList::SBAddressRangeList()
+: m_opaque_up(new AddressRangeListImpl()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRangeList::SBAddressRangeList(const SBAddressRangeList &rhs)
+: m_opaque_up(new AddressRangeListImpl(*rhs.m_opaque_up)) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+}
+
+SBAddressRangeList::~SBAddressRangeList() = default;
+
+const SBAddressRangeList &
+SBAddressRangeList::operator=(const SBAddressRangeList &rhs) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (this != &rhs)
+*m_opaque_up = *rhs.m_opaque_up;
+  return *this;
+}
+
+uint32_t SBAddressRangeList::GetSize() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  return m_opaque_up->GetSize();
+}
+
+SBAddressRange SBAddressRangeList::GetAddressRangeAtIndex(uint64_t idx) {
+  LLDB_INSTRUMENT_VA(this, idx);
+
+  SBAddressRange sb_addr_range;
+  (*sb_addr_range.m_opaque_up) = m_opaque_up->GetAddressRangeAtIndex(idx);
+  return sb_addr_range;
+}
+
+void SBAddressRangeList::Clear() {
+  LLDB_INSTRUMENT_VA(this);
+
+  m_opaque_up->Clear();
+}
+
+void SBAddressRangeList::Append(const SBAddressRange &sb_addr_range) {
+  LLDB_INSTRUMENT_VA(this, sb_addr_range);
+
+  m_opaque_up->Append(*sb_addr_range.m_opaque_up);
+}
+
+void SBAddressRangeList::Append(const SBAddressRangeList &sb_addr_range_list) {
+  LLDB_INSTRUMENT_VA(this, sb_addr_range_list);
+
+  m_opaque_up->Append(*sb_addr_range_list.m_opaque_up);
+}
+
+bool SBAddressRangeList::GetDescription(SBStream &description,
+SBTarget *target) {
+  LLDB_INSTRUMENT_VA(this, description);
+
+  const uint32_t num_ranges = GetSize();
+  bool is_first = true;
+  Stream &stream = description.ref();
+  stream << "[";
+  for (uint32_t i = 0; i < num_ranges; ++i) {
+if (is_first) {
+  is_first = false;
+} else {
+  stream.Printf(", ");
+}

mbucko wrote:

This is actually correct, it prints out:
`[a.out[0x115f-0x1167), a.out[0x1134-0x1144), a.out[0x1144-0x1164)]`

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


[Lldb-commits] [clang] [lldb] [llvm] Remove some `try_compile` CMake checks for compiler flags (PR #92953)

2024-05-21 Thread Vlad Serebrennikov via lldb-commits

Endilll wrote:

On my setup, this patch improves CMake configuration times (from a clean state) 
from 51 seconds down to 46 seconds (average of 3 measurements).

My setup: ancient x86 hardware, Debian Sid, nightly Clang, build directory on a 
RAM disk. CMake invocation:
`cmake -DLLVM_ENABLE_PROJECTS="clang;lldb" 
-DLLVM_ENABLE_RUNTIMES="libunwind;libcxx;libcxxabi" -DCMAKE_BUILD_TYPE=Debug 
-DLLVM_OPTIMIZED_TABLEGEN=ON -DLLVM_TARGETS_TO_BUILD="X86" 
-DLLVM_ENABLE_DOXYGEN=ON -DLLVM_ENABLE_LIBCXX=ON -DBUILD_SHARED_LIBS=ON 
-DLLDB_ENABLE_PYTHON=ON ~/endill/llvm-project/llvm`.

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


[Lldb-commits] [clang] [lldb] [llvm] Remove some `try_compile` CMake checks for compiler flags (PR #92953)

2024-05-21 Thread via lldb-commits

llvmbot wrote:



@llvm/pr-subscribers-lldb

@llvm/pr-subscribers-clang

Author: Vlad Serebrennikov (Endilll)


Changes

This patch remove 36 checks for compiler flags that are done via invoking the 
compiler across LLVM, Clang, and LLDB. It's was made possible by raising the 
bar for supported compilers that has been happening over the years since the 
checks were added.

This is going to improve CMake configuration times. This topic was highlighted 
in 
https://discourse.llvm.org/t/cmake-compiler-flag-checks-are-really-slow-ideas-to-speed-them-up/78882.

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


7 Files Affected:

- (modified) clang/CMakeLists.txt (+1-4) 
- (modified) clang/tools/scan-build-py/tests/functional/exec/CMakeLists.txt 
(+1-5) 
- (modified) lldb/cmake/modules/LLDBConfig.cmake (+7-13) 
- (modified) llvm/cmake/config-ix.cmake (+8-11) 
- (modified) llvm/cmake/modules/AddLLVM.cmake (+1-3) 
- (modified) llvm/cmake/modules/HandleLLVMOptions.cmake (+61-81) 
- (modified) third-party/unittest/CMakeLists.txt (+1-3) 


``diff
diff --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index c20ce47a12abb..a6bcb853a464c 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -349,10 +349,7 @@ if (LLVM_COMPILER_IS_GCC_COMPATIBLE)
 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pedantic -Wno-long-long")
   endif ()
 
-  check_cxx_compiler_flag("-Werror -Wnested-anon-types" 
CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG)
-  if( CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG )
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-nested-anon-types" )
-  endif()
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-nested-anon-types" )
 endif ()
 
 # Determine HOST_LINK_VERSION on Darwin.
diff --git a/clang/tools/scan-build-py/tests/functional/exec/CMakeLists.txt 
b/clang/tools/scan-build-py/tests/functional/exec/CMakeLists.txt
index 95c6fdb610e0f..cb6ebda183725 100644
--- a/clang/tools/scan-build-py/tests/functional/exec/CMakeLists.txt
+++ b/clang/tools/scan-build-py/tests/functional/exec/CMakeLists.txt
@@ -2,11 +2,7 @@ project(exec C)
 
 cmake_minimum_required(VERSION 3.20.0)
 
-include(CheckCCompilerFlag)
-check_c_compiler_flag("-std=c99" C99_SUPPORTED)
-if (C99_SUPPORTED)
-set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=c99")
-endif()
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=c99")
 
 include(CheckFunctionExists)
 include(CheckSymbolExists)
diff --git a/lldb/cmake/modules/LLDBConfig.cmake 
b/lldb/cmake/modules/LLDBConfig.cmake
index 3c6223b015bb1..6458f2e174643 100644
--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -187,24 +187,18 @@ 
include_directories("${CMAKE_CURRENT_BINARY_DIR}/../clang/include")
 # form -W, and if supported, add the corresponding -Wno- option.
 
 # Disable GCC warnings
-check_cxx_compiler_flag("-Wdeprecated-declarations" 
CXX_SUPPORTS_DEPRECATED_DECLARATIONS)
-append_if(CXX_SUPPORTS_DEPRECATED_DECLARATIONS "-Wno-deprecated-declarations" 
CMAKE_CXX_FLAGS)
-
-check_cxx_compiler_flag("-Wunknown-pragmas" CXX_SUPPORTS_UNKNOWN_PRAGMAS)
-append_if(CXX_SUPPORTS_UNKNOWN_PRAGMAS "-Wno-unknown-pragmas" CMAKE_CXX_FLAGS)
-
-check_cxx_compiler_flag("-Wstrict-aliasing" CXX_SUPPORTS_STRICT_ALIASING)
-append_if(CXX_SUPPORTS_STRICT_ALIASING "-Wno-strict-aliasing" CMAKE_CXX_FLAGS)
+append("-Wno-deprecated-declarations" CMAKE_CXX_FLAGS)
+append("-Wno-unknown-pragmas" CMAKE_CXX_FLAGS)
+append("-Wno-strict-aliasing" CMAKE_CXX_FLAGS)
 
 check_cxx_compiler_flag("-Wstringop-truncation" 
CXX_SUPPORTS_STRINGOP_TRUNCATION)
 append_if(CXX_SUPPORTS_STRINGOP_TRUNCATION "-Wno-stringop-truncation" 
CMAKE_CXX_FLAGS)
 
 # Disable Clang warnings
-check_cxx_compiler_flag("-Wdeprecated-register" 
CXX_SUPPORTS_DEPRECATED_REGISTER)
-append_if(CXX_SUPPORTS_DEPRECATED_REGISTER "-Wno-deprecated-register" 
CMAKE_CXX_FLAGS)
-
-check_cxx_compiler_flag("-Wvla-extension" CXX_SUPPORTS_VLA_EXTENSION)
-append_if(CXX_SUPPORTS_VLA_EXTENSION "-Wno-vla-extension" CMAKE_CXX_FLAGS)
+if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
+  append("-Wno-deprecated-register" CMAKE_CXX_FLAGS)
+  append("-Wno-vla-extension" CMAKE_CXX_FLAGS)
+endif()
 
 # Disable MSVC warnings
 if( MSVC )
diff --git a/llvm/cmake/config-ix.cmake b/llvm/cmake/config-ix.cmake
index bf1b110245bb2..0900e1107076e 100644
--- a/llvm/cmake/config-ix.cmake
+++ b/llvm/cmake/config-ix.cmake
@@ -415,15 +415,14 @@ if( LLVM_ENABLE_PIC )
   set(ENABLE_PIC 1)
 else()
   set(ENABLE_PIC 0)
-  check_cxx_compiler_flag("-fno-pie" SUPPORTS_NO_PIE_FLAG)
-  if(SUPPORTS_NO_PIE_FLAG)
-set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fno-pie")
-  endif()
+  set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fno-pie")
 endif()
 
-check_cxx_compiler_flag("-Wvariadic-macros" SUPPORTS_VARIADIC_MACROS_FLAG)
-check_cxx_compiler_flag("-Wgnu-zero-variadic-macro-arguments"
-SUPPORTS_GNU_ZERO_VARIADIC_MACRO_ARGUMENTS_FLAG)
+if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
+  set(SUPPORTS_GNU_ZERO_VARIADIC_MACRO_ARGUMENTS_FLAG 1)

[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Miro Bucko via lldb-commits


@@ -0,0 +1,54 @@
+//===-- SBAddressRangeList.h *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGELIST_H
+#define LLDB_API_SBADDRESSRANGELIST_H
+
+#include 
+
+#include "lldb/API/SBDefines.h"
+
+namespace lldb_private {
+class AddressRangeListImpl;
+}
+
+namespace lldb {
+
+class LLDB_API SBAddressRangeList {
+public:
+  SBAddressRangeList();
+
+  SBAddressRangeList(const lldb::SBAddressRangeList &rhs);
+
+  ~SBAddressRangeList();
+
+  const lldb::SBAddressRangeList &
+  operator=(const lldb::SBAddressRangeList &rhs);
+
+  uint32_t GetSize() const;
+
+  void Clear();
+
+  SBAddressRange GetAddressRangeAtIndex(uint64_t idx);

mbucko wrote:

https://github.com/llvm/llvm-project/pull/92014#discussion_r1599157212

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


[Lldb-commits] [clang] [lldb] [llvm] Remove some `try_compile` CMake checks for compiler flags (PR #92953)

2024-05-21 Thread Vlad Serebrennikov via lldb-commits

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

This patch remove 36 checks for compiler flags that are done via invoking the 
compiler across LLVM, Clang, and LLDB. It's was made possible by raising the 
bar for supported compilers that has been happening over the years since the 
checks were added.

This is going to improve CMake configuration times. This topic was highlighted 
in 
https://discourse.llvm.org/t/cmake-compiler-flag-checks-are-really-slow-ideas-to-speed-them-up/78882.

>From 66e05ac24613435dbe774d49684d8ff9d119c4c3 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Tue, 21 May 2024 21:41:24 +0300
Subject: [PATCH] Remove some `try_compile` CMake checks for compiler flags

This patch remove 36 checks for compiler flags that are done via invoking the 
compiler across LLVM, Clang, and LLDB. It's was made possible by raising the 
bar for supported compilers that has been happening over the years since the 
checks were added.

This is going to improve CMake configuration times. This topic was highlighted 
in 
https://discourse.llvm.org/t/cmake-compiler-flag-checks-are-really-slow-ideas-to-speed-them-up/78882.
---
 clang/CMakeLists.txt  |   5 +-
 .../tests/functional/exec/CMakeLists.txt  |   6 +-
 lldb/cmake/modules/LLDBConfig.cmake   |  20 +--
 llvm/cmake/config-ix.cmake|  19 +--
 llvm/cmake/modules/AddLLVM.cmake  |   4 +-
 llvm/cmake/modules/HandleLLVMOptions.cmake| 142 --
 third-party/unittest/CMakeLists.txt   |   4 +-
 7 files changed, 80 insertions(+), 120 deletions(-)

diff --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index c20ce47a12abb..a6bcb853a464c 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -349,10 +349,7 @@ if (LLVM_COMPILER_IS_GCC_COMPATIBLE)
 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pedantic -Wno-long-long")
   endif ()
 
-  check_cxx_compiler_flag("-Werror -Wnested-anon-types" 
CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG)
-  if( CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG )
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-nested-anon-types" )
-  endif()
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-nested-anon-types" )
 endif ()
 
 # Determine HOST_LINK_VERSION on Darwin.
diff --git a/clang/tools/scan-build-py/tests/functional/exec/CMakeLists.txt 
b/clang/tools/scan-build-py/tests/functional/exec/CMakeLists.txt
index 95c6fdb610e0f..cb6ebda183725 100644
--- a/clang/tools/scan-build-py/tests/functional/exec/CMakeLists.txt
+++ b/clang/tools/scan-build-py/tests/functional/exec/CMakeLists.txt
@@ -2,11 +2,7 @@ project(exec C)
 
 cmake_minimum_required(VERSION 3.20.0)
 
-include(CheckCCompilerFlag)
-check_c_compiler_flag("-std=c99" C99_SUPPORTED)
-if (C99_SUPPORTED)
-set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=c99")
-endif()
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=c99")
 
 include(CheckFunctionExists)
 include(CheckSymbolExists)
diff --git a/lldb/cmake/modules/LLDBConfig.cmake 
b/lldb/cmake/modules/LLDBConfig.cmake
index 3c6223b015bb1..6458f2e174643 100644
--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -187,24 +187,18 @@ 
include_directories("${CMAKE_CURRENT_BINARY_DIR}/../clang/include")
 # form -W, and if supported, add the corresponding -Wno- option.
 
 # Disable GCC warnings
-check_cxx_compiler_flag("-Wdeprecated-declarations" 
CXX_SUPPORTS_DEPRECATED_DECLARATIONS)
-append_if(CXX_SUPPORTS_DEPRECATED_DECLARATIONS "-Wno-deprecated-declarations" 
CMAKE_CXX_FLAGS)
-
-check_cxx_compiler_flag("-Wunknown-pragmas" CXX_SUPPORTS_UNKNOWN_PRAGMAS)
-append_if(CXX_SUPPORTS_UNKNOWN_PRAGMAS "-Wno-unknown-pragmas" CMAKE_CXX_FLAGS)
-
-check_cxx_compiler_flag("-Wstrict-aliasing" CXX_SUPPORTS_STRICT_ALIASING)
-append_if(CXX_SUPPORTS_STRICT_ALIASING "-Wno-strict-aliasing" CMAKE_CXX_FLAGS)
+append("-Wno-deprecated-declarations" CMAKE_CXX_FLAGS)
+append("-Wno-unknown-pragmas" CMAKE_CXX_FLAGS)
+append("-Wno-strict-aliasing" CMAKE_CXX_FLAGS)
 
 check_cxx_compiler_flag("-Wstringop-truncation" 
CXX_SUPPORTS_STRINGOP_TRUNCATION)
 append_if(CXX_SUPPORTS_STRINGOP_TRUNCATION "-Wno-stringop-truncation" 
CMAKE_CXX_FLAGS)
 
 # Disable Clang warnings
-check_cxx_compiler_flag("-Wdeprecated-register" 
CXX_SUPPORTS_DEPRECATED_REGISTER)
-append_if(CXX_SUPPORTS_DEPRECATED_REGISTER "-Wno-deprecated-register" 
CMAKE_CXX_FLAGS)
-
-check_cxx_compiler_flag("-Wvla-extension" CXX_SUPPORTS_VLA_EXTENSION)
-append_if(CXX_SUPPORTS_VLA_EXTENSION "-Wno-vla-extension" CMAKE_CXX_FLAGS)
+if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
+  append("-Wno-deprecated-register" CMAKE_CXX_FLAGS)
+  append("-Wno-vla-extension" CMAKE_CXX_FLAGS)
+endif()
 
 # Disable MSVC warnings
 if( MSVC )
diff --git a/llvm/cmake/config-ix.cmake b/llvm/cmake/config-ix.cmake
index bf1b110245bb2..0900e1107076e 100644
--- a/llvm/cmake/config-ix.cmake
+++ b/llvm/cmake/config-ix.cmake
@@ -415,15 +415,14 @@ if( LLVM_ENABLE_PIC )
   set(ENABLE_PIC 1)
 else()
   set(ENABLE_P

[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Miro Bucko via lldb-commits


@@ -0,0 +1,28 @@
+%extend lldb::SBAddressRangeList {
+#ifdef SWIGPYTHON
+%pythoncode%{
+def __len__(self):
+  '''Return the number of address ranges in a lldb.SBAddressRangeList 
object.'''
+  return self.GetSize()
+
+def __iter__(self):
+  '''Iterate over all the address ranges in a lldb.SBAddressRangeList 
object.'''
+  return lldb_iter(self, 'GetSize', 'GetAddressRangeAtIndex')
+
+def __getitem__(self, idx):
+  '''Get the address range at a given index in an lldb.SBAddressRangeList 
object.'''
+  if type(idx) == int:
+if idx >= self.GetSize():
+  raise IndexError("list index out of range")
+return self.GetAddressRangeAtIndex(idx)
+  else:
+print("error: unsupported idx type: %s" % type(key))
+return None

mbucko wrote:

I'm following the convention from other Extensions files

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Miro Bucko via lldb-commits


@@ -0,0 +1,28 @@
+%extend lldb::SBAddressRangeList {
+#ifdef SWIGPYTHON
+%pythoncode%{
+def __len__(self):
+  '''Return the number of address ranges in a lldb.SBAddressRangeList 
object.'''
+  return self.GetSize()
+
+def __iter__(self):
+  '''Iterate over all the address ranges in a lldb.SBAddressRangeList 
object.'''
+  return lldb_iter(self, 'GetSize', 'GetAddressRangeAtIndex')
+
+def __getitem__(self, idx):
+  '''Get the address range at a given index in an lldb.SBAddressRangeList 
object.'''
+  if type(idx) == int:
+if idx >= self.GetSize():
+  raise IndexError("list index out of range")
+return self.GetAddressRangeAtIndex(idx)
+  else:
+print("error: unsupported idx type: %s" % type(key))
+return None
+def __repr__(self):
+  import lldb

mbucko wrote:

same as above

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Miro Bucko via lldb-commits


@@ -0,0 +1,11 @@
+%extend lldb::SBAddressRange {
+#ifdef SWIGPYTHON
+%pythoncode%{
+  def __repr__(self):
+import lldb

mbucko wrote:

it's not, produces the following error:
`NameError: name 'lldb' is not defined`

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Alex Langford via lldb-commits


@@ -0,0 +1,91 @@
+//===-- SBAddressRangeList.cpp 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRangeList.h"
+#include "Utils.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/API/SBStream.h"
+#include "lldb/Core/AddressRangeListImpl.h"
+#include "lldb/Utility/Instrumentation.h"
+#include "lldb/Utility/Stream.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRangeList::SBAddressRangeList()
+: m_opaque_up(new AddressRangeListImpl()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRangeList::SBAddressRangeList(const SBAddressRangeList &rhs)
+: m_opaque_up(new AddressRangeListImpl(*rhs.m_opaque_up)) {

bulbazord wrote:

Same here

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Alex Langford via lldb-commits


@@ -0,0 +1,103 @@
+//===-- SBAddressRange.cpp 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRange.h"
+#include "Utils.h"
+#include "lldb/API/SBAddress.h"
+#include "lldb/API/SBStream.h"
+#include "lldb/API/SBTarget.h"
+#include "lldb/Core/AddressRange.h"
+#include "lldb/Core/Section.h"
+#include "lldb/Utility/Instrumentation.h"
+#include "lldb/Utility/Stream.h"
+#include 
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRange::SBAddressRange()
+: m_opaque_up(std::make_unique()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRange::SBAddressRange(const SBAddressRange &rhs) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  m_opaque_up = clone(rhs.m_opaque_up);
+}
+
+SBAddressRange::SBAddressRange(lldb::SBAddress addr, lldb::addr_t byte_size)
+: m_opaque_up(std::make_unique(addr.ref(), byte_size)) {
+  LLDB_INSTRUMENT_VA(this, addr, byte_size);
+}
+
+SBAddressRange::~SBAddressRange() = default;
+
+const SBAddressRange &SBAddressRange::operator=(const SBAddressRange &rhs) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (this != &rhs)
+m_opaque_up = clone(rhs.m_opaque_up);
+  return *this;
+}
+
+bool SBAddressRange::operator==(const SBAddressRange &rhs) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (!IsValid() || !rhs.IsValid())
+return false;
+  return m_opaque_up->operator==(*(rhs.m_opaque_up));
+}
+
+bool SBAddressRange::operator!=(const SBAddressRange &rhs) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  return !(*this == rhs);
+}
+
+void SBAddressRange::Clear() {
+  LLDB_INSTRUMENT_VA(this);
+
+  m_opaque_up.reset();
+}
+
+bool SBAddressRange::IsValid() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  return m_opaque_up && m_opaque_up->IsValid();
+}
+
+lldb::SBAddress SBAddressRange::GetBaseAddress() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  if (!IsValid())
+return lldb::SBAddress();
+  return lldb::SBAddress(m_opaque_up->GetBaseAddress());
+}
+
+lldb::addr_t SBAddressRange::GetByteSize() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  if (!IsValid())
+return 0;
+  return m_opaque_up->GetByteSize();
+}
+
+bool SBAddressRange::GetDescription(SBStream &description, SBTarget *target) {
+  LLDB_INSTRUMENT_VA(this, description);

bulbazord wrote:

instrumentation macro is missing target

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Alex Langford via lldb-commits


@@ -0,0 +1,91 @@
+//===-- SBAddressRangeList.cpp 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRangeList.h"
+#include "Utils.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/API/SBStream.h"
+#include "lldb/Core/AddressRangeListImpl.h"
+#include "lldb/Utility/Instrumentation.h"
+#include "lldb/Utility/Stream.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRangeList::SBAddressRangeList()
+: m_opaque_up(new AddressRangeListImpl()) {

bulbazord wrote:

Can we use `make_unique` here instead of a raw `new`?

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Alex Langford via lldb-commits


@@ -0,0 +1,54 @@
+//===-- SBAddressRangeList.h *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGELIST_H
+#define LLDB_API_SBADDRESSRANGELIST_H
+
+#include 
+
+#include "lldb/API/SBDefines.h"
+
+namespace lldb_private {
+class AddressRangeListImpl;
+}
+
+namespace lldb {
+
+class LLDB_API SBAddressRangeList {
+public:
+  SBAddressRangeList();
+
+  SBAddressRangeList(const lldb::SBAddressRangeList &rhs);
+
+  ~SBAddressRangeList();
+
+  const lldb::SBAddressRangeList &
+  operator=(const lldb::SBAddressRangeList &rhs);
+
+  uint32_t GetSize() const;
+
+  void Clear();
+
+  SBAddressRange GetAddressRangeAtIndex(uint64_t idx);

bulbazord wrote:

There's still a difference here. Why is the index uint64_t while `GetSize` 
returns a `uint32_t`?

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Alex Langford via lldb-commits


@@ -0,0 +1,65 @@
+//===-- SBAddressRange.h *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGE_H
+#define LLDB_API_SBADDRESSRANGE_H
+
+#include "lldb/API/SBDefines.h"
+
+namespace lldb {
+
+class LLDB_API SBAddressRange {
+public:
+  SBAddressRange();
+
+  SBAddressRange(const lldb::SBAddressRange &rhs);
+
+  SBAddressRange(lldb::SBAddress addr, lldb::addr_t byte_size);
+
+  ~SBAddressRange();
+
+  const lldb::SBAddressRange &operator=(const lldb::SBAddressRange &rhs);
+
+  void Clear();
+
+  /// Check the address range refers to a valid base address and has a byte
+  /// size greater than zero.
+  ///
+  /// \return
+  /// True if the address range is valid, false otherwise.
+  bool IsValid() const;
+
+  /// Get the base address of the range.
+  ///
+  /// \return
+  /// Base address object.
+  lldb::SBAddress GetBaseAddress() const;
+
+  /// Get the byte size of this range.
+  ///
+  /// \return
+  /// The size in bytes of this address range.
+  lldb::addr_t GetByteSize() const;
+
+  bool operator==(const SBAddressRange &rhs);
+
+  bool operator!=(const SBAddressRange &rhs);
+
+  bool GetDescription(lldb::SBStream &description, SBTarget *target);

bulbazord wrote:

In addition, if this doesn't modify the `SBTarget`, please mark it as const -- 
`const SBTarget &target`. We have some tooling downstream that works better if 
parameters that aren't mutated are marked as `const`.

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Alex Langford via lldb-commits


@@ -0,0 +1,91 @@
+//===-- SBAddressRangeList.cpp 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRangeList.h"
+#include "Utils.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/API/SBStream.h"
+#include "lldb/Core/AddressRangeListImpl.h"
+#include "lldb/Utility/Instrumentation.h"
+#include "lldb/Utility/Stream.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRangeList::SBAddressRangeList()
+: m_opaque_up(new AddressRangeListImpl()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRangeList::SBAddressRangeList(const SBAddressRangeList &rhs)
+: m_opaque_up(new AddressRangeListImpl(*rhs.m_opaque_up)) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+}
+
+SBAddressRangeList::~SBAddressRangeList() = default;
+
+const SBAddressRangeList &
+SBAddressRangeList::operator=(const SBAddressRangeList &rhs) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (this != &rhs)
+*m_opaque_up = *rhs.m_opaque_up;
+  return *this;
+}
+
+uint32_t SBAddressRangeList::GetSize() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  return m_opaque_up->GetSize();
+}
+
+SBAddressRange SBAddressRangeList::GetAddressRangeAtIndex(uint64_t idx) {
+  LLDB_INSTRUMENT_VA(this, idx);
+
+  SBAddressRange sb_addr_range;
+  (*sb_addr_range.m_opaque_up) = m_opaque_up->GetAddressRangeAtIndex(idx);
+  return sb_addr_range;
+}
+
+void SBAddressRangeList::Clear() {
+  LLDB_INSTRUMENT_VA(this);
+
+  m_opaque_up->Clear();
+}
+
+void SBAddressRangeList::Append(const SBAddressRange &sb_addr_range) {
+  LLDB_INSTRUMENT_VA(this, sb_addr_range);
+
+  m_opaque_up->Append(*sb_addr_range.m_opaque_up);
+}
+
+void SBAddressRangeList::Append(const SBAddressRangeList &sb_addr_range_list) {
+  LLDB_INSTRUMENT_VA(this, sb_addr_range_list);
+
+  m_opaque_up->Append(*sb_addr_range_list.m_opaque_up);
+}
+
+bool SBAddressRangeList::GetDescription(SBStream &description,
+SBTarget *target) {
+  LLDB_INSTRUMENT_VA(this, description);

bulbazord wrote:

Missing target from the instrumentation macro.

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Alex Langford via lldb-commits


@@ -0,0 +1,91 @@
+//===-- SBAddressRangeList.cpp 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRangeList.h"
+#include "Utils.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/API/SBStream.h"
+#include "lldb/Core/AddressRangeListImpl.h"
+#include "lldb/Utility/Instrumentation.h"
+#include "lldb/Utility/Stream.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRangeList::SBAddressRangeList()
+: m_opaque_up(new AddressRangeListImpl()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRangeList::SBAddressRangeList(const SBAddressRangeList &rhs)
+: m_opaque_up(new AddressRangeListImpl(*rhs.m_opaque_up)) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+}
+
+SBAddressRangeList::~SBAddressRangeList() = default;
+
+const SBAddressRangeList &
+SBAddressRangeList::operator=(const SBAddressRangeList &rhs) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (this != &rhs)
+*m_opaque_up = *rhs.m_opaque_up;
+  return *this;
+}
+
+uint32_t SBAddressRangeList::GetSize() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  return m_opaque_up->GetSize();
+}
+
+SBAddressRange SBAddressRangeList::GetAddressRangeAtIndex(uint64_t idx) {
+  LLDB_INSTRUMENT_VA(this, idx);
+
+  SBAddressRange sb_addr_range;
+  (*sb_addr_range.m_opaque_up) = m_opaque_up->GetAddressRangeAtIndex(idx);
+  return sb_addr_range;
+}
+
+void SBAddressRangeList::Clear() {
+  LLDB_INSTRUMENT_VA(this);
+
+  m_opaque_up->Clear();
+}
+
+void SBAddressRangeList::Append(const SBAddressRange &sb_addr_range) {
+  LLDB_INSTRUMENT_VA(this, sb_addr_range);
+
+  m_opaque_up->Append(*sb_addr_range.m_opaque_up);
+}
+
+void SBAddressRangeList::Append(const SBAddressRangeList &sb_addr_range_list) {
+  LLDB_INSTRUMENT_VA(this, sb_addr_range_list);
+
+  m_opaque_up->Append(*sb_addr_range_list.m_opaque_up);
+}
+
+bool SBAddressRangeList::GetDescription(SBStream &description,
+SBTarget *target) {
+  LLDB_INSTRUMENT_VA(this, description);
+
+  const uint32_t num_ranges = GetSize();
+  bool is_first = true;
+  Stream &stream = description.ref();
+  stream << "[";
+  for (uint32_t i = 0; i < num_ranges; ++i) {
+if (is_first) {
+  is_first = false;
+} else {
+  stream.Printf(", ");
+}

bulbazord wrote:

I think this doesn't do what you intended it to do. For example, a list with 3 
elements will look like this:
```
[ , , ]
```
When you probably wanted something like this:
```
[, , ]
```

The first element isn't the one you care about, it's the last one that doesn't 
need the `", "` appended to the end.

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Alex Langford via lldb-commits


@@ -0,0 +1,11 @@
+%extend lldb::SBAddressRange {
+#ifdef SWIGPYTHON
+%pythoncode%{
+  def __repr__(self):
+import lldb

bulbazord wrote:

Why does this import lldb? Shouldn't it already be imported?

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Alex Langford via lldb-commits


@@ -0,0 +1,28 @@
+%extend lldb::SBAddressRangeList {
+#ifdef SWIGPYTHON
+%pythoncode%{
+def __len__(self):
+  '''Return the number of address ranges in a lldb.SBAddressRangeList 
object.'''
+  return self.GetSize()
+
+def __iter__(self):
+  '''Iterate over all the address ranges in a lldb.SBAddressRangeList 
object.'''
+  return lldb_iter(self, 'GetSize', 'GetAddressRangeAtIndex')
+
+def __getitem__(self, idx):
+  '''Get the address range at a given index in an lldb.SBAddressRangeList 
object.'''
+  if type(idx) == int:
+if idx >= self.GetSize():
+  raise IndexError("list index out of range")
+return self.GetAddressRangeAtIndex(idx)
+  else:
+print("error: unsupported idx type: %s" % type(key))
+return None

bulbazord wrote:

If the type of index is not an int, why not raise an exception? We raise an 
exception if the index is an int and is out of range.

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-21 Thread Alex Langford via lldb-commits


@@ -0,0 +1,28 @@
+%extend lldb::SBAddressRangeList {
+#ifdef SWIGPYTHON
+%pythoncode%{
+def __len__(self):
+  '''Return the number of address ranges in a lldb.SBAddressRangeList 
object.'''
+  return self.GetSize()
+
+def __iter__(self):
+  '''Iterate over all the address ranges in a lldb.SBAddressRangeList 
object.'''
+  return lldb_iter(self, 'GetSize', 'GetAddressRangeAtIndex')
+
+def __getitem__(self, idx):
+  '''Get the address range at a given index in an lldb.SBAddressRangeList 
object.'''
+  if type(idx) == int:
+if idx >= self.GetSize():
+  raise IndexError("list index out of range")
+return self.GetAddressRangeAtIndex(idx)
+  else:
+print("error: unsupported idx type: %s" % type(key))
+return None
+def __repr__(self):
+  import lldb

bulbazord wrote:

Same here, why does this import lldb?

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

2024-05-21 Thread Zequan Wu via lldb-commits


@@ -2306,6 +2345,11 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const 
DWARFDIE &die,
 
   if (!die)
 return false;
+  ParsedDWARFTypeAttributes attrs(die);

ZequanWu wrote:

> The reason why this crash does not happen when attempting to complete a type 
> with no definition is because this function is the actual implementation of 
> "completing a type from a defintion". I.e., it expects to be called with a 
> definition DIE, and will never be called if there is no definition (we will 
> bail out, and possibly "forcefully" complete the type somewhere higher up the 
> stack).

Yes, it should only be called with definition DIE. This extra check just a 
double-check for it with a bit performance cost. If there's no definition DIE, 
`SymbolFileDWARF::CompleteType` does an early return. This behaviour is 
unchanged. Forceful completion behaviour is also remained unchanged, happens 
when failed to find definition DIE of a containing record type.

> If that is true, then I think Greg's patch is a better fix for this problem, 
> and it also sidesteps all of the performance/memory tradeoff discussions.

I agree. If we can ensure the DIE is always a definition DIE for both manual 
index and debug_names index at a earlier time, there's no need for this check. 
I'll remove this check when Greg's change is in.

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


[Lldb-commits] [lldb] Summarize std::string's when created from data. (PR #89110)

2024-05-21 Thread via lldb-commits

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff 3074060d6a1d7d2e74cb767876bd9e5192d12007 
29b55fcba7a7f7b7ab0581f7804b9ad70863b0ff -- 
lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/main.cpp
``





View the diff from clang-format here.


``diff
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/main.cpp
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/main.cpp
index b169a2e694..838781935f 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/main.cpp
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/main.cpp
@@ -1,12 +1,12 @@
 #include 
 
 struct string_container {
-std::string short_string;
-std::string long_string;
-std::string *short_string_ptr = &short_string;
-std::string *long_string_ptr = &long_string;
-std::string &short_string_ref = short_string;
-std::string &long_string_ref = long_string;
+  std::string short_string;
+  std::string long_string;
+  std::string *short_string_ptr = &short_string;
+  std::string *long_string_ptr = &long_string;
+  std::string &short_string_ref = short_string;
+  std::string &long_string_ref = long_string;
 };
 
 int main()
@@ -22,7 +22,8 @@ int main()
 std::string *pq = &q, *pQ = &Q;
 string_container sc;
 sc.short_string = "u22";
-sc.long_string = "quite a long std::string with lots of info inside it 
inside a struct";
+sc.long_string =
+"quite a long std::string with lots of info inside it inside a struct";
 
 S.assign(L"!"); // Set break point at this line.
 return 0;

``




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


[Lldb-commits] [lldb] Summarize std::string's when created from data. (PR #89110)

2024-05-21 Thread 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 
3074060d6a1d7d2e74cb767876bd9e5192d12007...29b55fcba7a7f7b7ab0581f7804b9ad70863b0ff
 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/ConvertToDataFormatter.py
 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/TestDataFormatterStdString.py
``





View the diff from darker here.


``diff
--- ConvertToDataFormatter.py   2024-04-16 22:18:59.00 +
+++ ConvertToDataFormatter.py   2024-05-21 17:57:50.207877 +
@@ -2,10 +2,11 @@
 """
 Helper formmater to verify Std::String by created via SBData
 """
 
 import lldb
+
 
 class SyntheticFormatter:
 def __init__(self, valobj, dict):
 self.valobj = valobj
 
@@ -33,13 +34,11 @@
 case _:
 return None
 
 child = self.valobj.GetChildMemberWithName(name)
 valType = child.GetType()
-return self.valobj.CreateValueFromData(name,
-child.GetData(),
-valType)
+return self.valobj.CreateValueFromData(name, child.GetData(), valType)
 
 
 def __lldb_init_module(debugger, dict):
 typeName = "string_container"
 debugger.HandleCommand(
--- TestDataFormatterStdString.py   2024-04-24 20:52:10.00 +
+++ TestDataFormatterStdString.py   2024-05-21 17:57:50.260723 +
@@ -92,11 +92,10 @@
 
 self.runCmd("next")
 
 self.assertEqual(var_S.GetSummary(), 'L"!"', "new S summary wrong")
 
-
 @add_test_categories(["libstdcxx"])
 @expectedFailureAll(bugnumber="llvm.org/pr50861", compiler="gcc")
 def test_std_string_as_data(self):
 """Test that strings created via SBValue::CreateFromData display 
correctly."""
 self.build()
@@ -122,26 +121,32 @@
 var_str_container = self.frame().FindVariable("sc")
 
 self.assertEqual(
 var_str_container.GetChildAtIndex(0).GetSummary(),
 '"u22"',
-"string container child wrong")
+"string container child wrong",
+)
 self.assertEqual(
 var_str_container.GetChildAtIndex(1).GetSummary(),
 '"quite a long std::string with lots of info inside it inside a 
struct"',
-"string container child wrong")
+"string container child wrong",
+)
 self.assertEqual(
 var_str_container.GetChildAtIndex(2).GetSummary(),
 '"u22"',
-"string container child wrong")
+"string container child wrong",
+)
 self.assertEqual(
 var_str_container.GetChildAtIndex(3).GetSummary(),
 '"quite a long std::string with lots of info inside it inside a 
struct"',
-"string container child wrong")
+"string container child wrong",
+)
 self.assertEqual(
 var_str_container.GetChildAtIndex(4).GetSummary(),
 '"u22"',
-"string container child wrong")
+"string container child wrong",
+)
 self.assertEqual(
 var_str_container.GetChildAtIndex(5).GetSummary(),
 '"quite a long std::string with lots of info inside it inside a 
struct"',
-"string container child wrong")
+"string container child wrong",
+)

``




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


[Lldb-commits] [lldb] [lldb] Refactor string manipulation in Debugger.cpp (#91209) (PR #92565)

2024-05-21 Thread Augusto Noronha via lldb-commits

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


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


[Lldb-commits] [lldb] Summarize std::string's when created from data. (PR #89110)

2024-05-21 Thread Jacob Lalonde via lldb-commits

https://github.com/Jlalond updated 
https://github.com/llvm/llvm-project/pull/89110

>From e0316188d22605c670079e37855d3d8b5c944cee Mon Sep 17 00:00:00 2001
From: Jacob John Lalonde 
Date: Wed, 10 Apr 2024 14:33:40 -0700
Subject: [PATCH 1/5] Fix bug where an sbvalue containing a std::string created
 from data would not use the built in summary provider, but default to the
 valueobjectprinter

std::string children are normally formatted as their summary [my_string_prop] = 
"hello world".
Sbvalues created from data do not follow the same summary formatter path and 
instead hit the value object printer.
This change fixes that and adds tests for the future.

Added tests in TestDataFormatterStdString.py and a formatter for a custom 
struct.
---
 .../Plugins/Language/CPlusPlus/LibStdcpp.cpp  | 31 ++--
 .../string/ConvertToDataFormatter.py  | 50 +++
 .../string/TestDataFormatterStdString.py  | 28 +++
 .../libstdcpp/string/main.cpp | 13 +
 4 files changed, 118 insertions(+), 4 deletions(-)
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/ConvertToDataFormatter.py

diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
index 86bb575af5ca3..0da01e9ca07fb 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
@@ -254,13 +254,13 @@ bool 
lldb_private::formatters::LibStdcppStringSummaryProvider(
   } else
 addr_of_string =
 valobj.GetAddressOf(scalar_is_load_addr, &addr_type);
-  if (addr_of_string != LLDB_INVALID_ADDRESS) {
+  if (addr_of_string != LLDB_INVALID_ADDRESS ||
+addr_type == eAddressTypeHost) {
 switch (addr_type) {
 case eAddressTypeLoad: {
   ProcessSP process_sp(valobj.GetProcessSP());
   if (!process_sp)
 return false;
-
   StringPrinter::ReadStringAndDumpToStreamOptions options(valobj);
   Status error;
   lldb::addr_t addr_of_data =
@@ -287,8 +287,31 @@ bool 
lldb_private::formatters::LibStdcppStringSummaryProvider(
   } else
 return true;
 } break;
-case eAddressTypeHost:
-  break;
+case eAddressTypeHost: {
+  // We have the host address of our std::string
+  // But we need to read the pointee data from the debugged process.
+  ProcessSP process_sp(valobj.GetProcessSP());
+  DataExtractor data;
+  Status error;
+  valobj.GetData(data, error);
+  if (error.Fail())
+return false;
+  // We want to read the address from std::string, which is the first 8 
bytes.
+  lldb::offset_t offset = 0;
+  lldb::addr_t addr = data.GetAddress(&offset);
+  if (!addr)
+  {
+stream.Printf("nullptr");
+return true;
+  }
+
+  std::string contents;
+  process_sp->ReadCStringFromMemory(addr, contents, error);
+  if (error.Fail())
+return false;
+  stream.Printf("%s", contents.c_str());
+  return true;
+} break;
 case eAddressTypeInvalid:
 case eAddressTypeFile:
   break;
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/ConvertToDataFormatter.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/ConvertToDataFormatter.py
new file mode 100644
index 0..57e42c920f829
--- /dev/null
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/ConvertToDataFormatter.py
@@ -0,0 +1,50 @@
+# coding=utf8
+"""
+Helper formmater to verify Std::String by created via SBData
+"""
+
+import lldb
+
+class SyntheticFormatter:
+def __init__(self, valobj, dict):
+self.valobj = valobj
+
+def num_children(self):
+return 6
+
+def has_children(self):
+return True
+
+def get_child_at_index(self, index):
+name = None
+match index:
+case 0:
+name = "short_string"
+case 1:
+name = "long_string"
+case 2:
+name = "short_string_ptr"
+case 3:
+name = "long_string_ptr"
+case 4:
+name = "short_string_ref"
+case 5:
+name = "long_string_ref"
+case _:
+return None
+
+child = self.valobj.GetChildMemberWithName(name)
+valType = child.GetType()
+return self.valobj.CreateValueFromData(name,
+child.GetData(),
+valType)
+
+
+def __lldb_init_module(debugger, dict):
+typeName = "string_container"
+debugger.HandleCommand(
+'type synthetic add -x "'
++ typeName
++ '" --python-class '
++ f"{__name__}.SyntheticFormatter"
+)
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/TestDataFormatterStdString.py
 
b/lldb/test/A

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

2024-05-21 Thread Pavel Labath via lldb-commits


@@ -2306,6 +2345,11 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const 
DWARFDIE &die,
 
   if (!die)
 return false;
+  ParsedDWARFTypeAttributes attrs(die);

labath wrote:

> > Why don't those cases lead to a crash? For example, what would happen if 
> > the name was simply not in the index?
> 
> That is specific to debug_names because the index gives us a declaration DIE 
> when we are searching for definition DIE in 
> 'FindDefinitionTypeForDWARFDeclContext'. Before, we didn't have the extra 
> check, so we tries to complete the type from declaration DIE, which triggers 
> an assertion in clang. However, it doesn't happen in manual index because we 
> already explicitly checked `DW_AT_declaration` attributes when creating the 
> manual index. It's guaranteed to find a definition DIE from 
> `FindDefinitionTypeForDWARFDeclContext` or nothing (early bailout, won't try 
> to complete it).

Okay, so when I said "specific to debug_names", I was mainly thinking of the 
case where the index doesn't find anything (i.e., we attempt to complete a type 
and the index (any kind of index) says we can't, because it doesn't have the 
definition). Based on what you've said (and some more pondering), I think can 
now answer that question for myself (please let me know if this is wrong):

The reason why this crash does not happen when attempting to complete a type 
with no definition is because this function is the actual implementation of 
"completing a type from a defintion". I.e., it expects to be called with a 
definition DIE, and will never be called if there is no definition (we will 
bail out, and possibly "forcefully" complete the type somewhere higher up the 
stack).

If that is true, then I think Greg's patch is a better fix for this problem, 
and it also sidesteps all of the performance/memory tradeoff discussions.


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


[Lldb-commits] [clang] [compiler-rt] [lldb] [llvm] [Support] Remove terminfo dependency (PR #92865)

2024-05-21 Thread Jonas Devlieghere via lldb-commits

JDevlieghere wrote:

No objections in the context of LLDB. We don't use terminfo directly (although 
I think editline does, but that isn't affected by this) and if we want the TUI 
we depend on curses anyway. 


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


[Lldb-commits] [lldb] 98f105a - [lldb] Add the word "backtrace" to bt help string (#92618)

2024-05-21 Thread via lldb-commits

Author: Dave Lee
Date: 2024-05-21T10:16:51-07:00
New Revision: 98f105a1304e8d3fd0a0234d1d488ed513833df8

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

LOG: [lldb] Add the word "backtrace" to bt help string (#92618)

We noticed that `apropos backtrace` did not return the `bt` alias. This change 
adds the 
word "backtrace" to the help for `bt`. It also updates `thread backtrace` to 
keep the 
language used roughly in sync.

Added: 


Modified: 
lldb/source/Commands/CommandObjectThread.cpp
lldb/source/Interpreter/CommandInterpreter.cpp

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectThread.cpp 
b/lldb/source/Commands/CommandObjectThread.cpp
index 4397ee14ea074..db96ee2cec383 100644
--- a/lldb/source/Commands/CommandObjectThread.cpp
+++ b/lldb/source/Commands/CommandObjectThread.cpp
@@ -114,8 +114,8 @@ class CommandObjectThreadBacktrace : public 
CommandObjectIterateOverThreads {
   CommandObjectThreadBacktrace(CommandInterpreter &interpreter)
   : CommandObjectIterateOverThreads(
 interpreter, "thread backtrace",
-"Show thread call stacks.  Defaults to the current thread, thread "
-"indexes can be specified as arguments.\n"
+"Show backtraces of thread call stacks.  Defaults to the current "
+"thread, thread indexes can be specified as arguments.\n"
 "Use the thread-index \"all\" to see all threads.\n"
 "Use the thread-index \"unique\" to see threads grouped by unique "
 "call stacks.\n"

diff  --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index 811726e30af4d..7f21f382adb83 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -828,11 +828,11 @@ void CommandInterpreter::LoadCommandDictionary() {
   std::unique_ptr bt_regex_cmd_up(
   new CommandObjectRegexCommand(
   *this, "_regexp-bt",
-  "Show the current thread's call stack.  Any numeric argument "
-  "displays at most that many "
-  "frames.  The argument 'all' displays all threads.  Use 'settings"
-  " set frame-format' to customize the printing of individual frames "
-  "and 'settings set thread-format' to customize the thread header.",
+  "Show backtrace of the current thread's call stack.  Any numeric "
+  "argument displays at most that many frames.  The argument 'all' "
+  "displays all threads.  Use 'settings set frame-format' to customize 
"
+  "the printing of individual frames and 'settings set thread-format' "
+  "to customize the thread header.",
   "bt [ | all]", 0, false));
   if (bt_regex_cmd_up) {
 // accept but don't document "bt -c " -- before bt was a regex



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


[Lldb-commits] [lldb] [lldb] Add the word "backtrace" to bt help string (PR #92618)

2024-05-21 Thread Dave Lee via lldb-commits

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


[Lldb-commits] [clang] [compiler-rt] [lldb] [llvm] [Support] Remove terminfo dependency (PR #92865)

2024-05-21 Thread Keith Smiley via lldb-commits

keith wrote:

looks like the .bazelrc still has mentions of this

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


[Lldb-commits] [lldb] Improve performance of .debug_names lookups when DW_IDX_parent attributes are used (PR #91808)

2024-05-21 Thread Pavel Labath via lldb-commits

labath wrote:

> > I was not able to produce a DW_IDX_parent_entries referring to any kind of 
> > class type
> 
> When I compile the following with `clang++ test.cpp -c -gdwarf-5 -O0 -o - | 
> dwarfdump --debug-names -`, I get the right parent chain. Is this not true 
> when you try it?

I do get it. It was my bad, I had a leftover -fdebug-types-section flag in my 
test cmd from when I was experimenting with the debug types section. I guess 
that's another thing to chalk up to 
https://github.com/llvm/llvm-project/issues/77696


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


[Lldb-commits] [lldb] Improve performance of .debug_names lookups when DW_IDX_parent attributes are used (PR #91808)

2024-05-21 Thread Felipe de Azevedo Piovezan via lldb-commits

felipepiovezan wrote:

> I think #77696 is justification enough to add this check, but I don't think 
> we should be implicating DW_IDX_parent_entries until we know how those came 
> about. 

This is pretty much my point, the workaround is fine, but I don't think the 
source-code comment in this PR is. The suggestion provided LGTM.

My guess is that the examples Greg is encountering are just hitting the 
slowness of DWARF parsing through other code paths (anything that causes too 
many calls to "ProcessEntries", and IDX_parent addressed _one_ of those, 
@Michael137  was just asking me the other day if we can address some of the 
other queries as well).

> I believe we could add a debug_names entry for std::ios_base (and refer to it 
> from the entry for std::ios_base::seekdir), as long as the ios_base entry was 
> not present in any of the name tables.

Yup, this is very doable!

> I was not able to produce a DW_IDX_parent_entries referring to any kind of 
> class type

When I compile the following with `clang++ test.cpp -c -gdwarf-5 -O0 -o - | 
dwarfdump --debug-names -`, I get the right parent chain. Is this not true when 
you try it?

```
namespace A { namespace B { struct State { class InnerState{}; }; } }
A::B::State::InnerState get_state() { return A::B::State::InnerState(); }
```

```
  String: 0x00c4 "InnerState"
  Entry @ 0xbe {
Abbrev: 0x138
Tag: DW_TAG_class_type
DW_IDX_die_offset: 0x003f
DW_IDX_parent: Entry @ 0xde
  }
  String: 0x00be "State"
  Entry @ 0xde {
Abbrev: 0x9b8
Tag: DW_TAG_structure_type
DW_IDX_die_offset: 0x0039
DW_IDX_parent: Entry @ 0xe9
  }
  String: 0x00bc "B"
  Entry @ 0xe9 {
Abbrev: 0x1cb8
Tag: DW_TAG_namespace
DW_IDX_die_offset: 0x0037
DW_IDX_parent: Entry @ 0xd7
  }
  String: 0x00ba "A"
  Entry @ 0xd7 {
Abbrev: 0x1c98
Tag: DW_TAG_namespace
DW_IDX_die_offset: 0x0035
DW_IDX_parent: 
  }
```

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

2024-05-21 Thread Zequan Wu via lldb-commits


@@ -2306,6 +2345,11 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const 
DWARFDIE &die,
 
   if (!die)
 return false;
+  ParsedDWARFTypeAttributes attrs(die);

ZequanWu wrote:

> Why don't those cases lead to a crash? For example, what would happen if the 
> name was simply not in the index?

That is specific to debug_names because the index gives us a declaration DIE 
when we are searching for definition DIE in 
'FindDefinitionTypeForDWARFDeclContext'. Before, we didn't have the extra 
check, so we tries to complete the type from declaration DIE, which triggers an 
assertion in clang. However, it doesn't happen in manual index because we 
already explicitly checked `DW_AT_declaration` attributes when creating the 
manual index. It's guaranteed to find a definition DIE from 
`FindDefinitionTypeForDWARFDeclContext` or nothing (early bailout, won't try to 
complete it).

> So it seems perfectly reasonable to have this check somewhere. I just want to 
> check whether this is the right place.

I assume Greg's change at https://github.com/llvm/llvm-project/pull/91808 will 
also fix this problem by skipping forward declaration DIE when processing it, 
which is earlier check  than this extra check added here.

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


[Lldb-commits] [lldb] A few updates around "transcript" (PR #92843)

2024-05-21 Thread via lldb-commits

royitaqi wrote:

cc @clayborg and @jeffreytan81 

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


[Lldb-commits] [lldb] New ThreadPlanSingleThreadTimeout to resolve potential deadlock in single thread stepping (PR #90930)

2024-05-21 Thread via lldb-commits

jeffreytan81 wrote:

@jimingham, I have revised the PR, let me know when you can review again. 
Thanks.

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


[Lldb-commits] [lldb] [lldb] Remove DWARFDebugInfo DIERef footguns (PR #92894)

2024-05-21 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Pavel Labath (labath)


Changes

DWARFDebugInfo doesn't know how to resolve the "file_index" component of a 
DIERef. This patch removes GetUnit (in favor of existing 
GetUnitContainingDIEOffset) and changes GetDIE to take only the components it 
actually uses.

In the process it fixes GetCompleteObjCClass, although that bug was unlikely to 
be noticed, since ObjC is only really used on darwin, and split DWARF isn't a 
thing there.

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


5 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp (+3-8) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h (+1-2) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp 
(+7-7) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+4-3) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp (+1-1) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
index d28da728728e5..c37cc91e08ed1 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
@@ -222,10 +222,6 @@ DWARFUnit *DWARFDebugInfo::GetUnitAtOffset(DIERef::Section 
section,
   return result;
 }
 
-DWARFUnit *DWARFDebugInfo::GetUnit(const DIERef &die_ref) {
-  return GetUnitContainingDIEOffset(die_ref.section(), die_ref.die_offset());
-}
-
 DWARFUnit *
 DWARFDebugInfo::GetUnitContainingDIEOffset(DIERef::Section section,
dw_offset_t die_offset) {
@@ -253,9 +249,8 @@ bool DWARFDebugInfo::ContainsTypeUnits() {
 //
 // Get the DIE (Debug Information Entry) with the specified offset.
 DWARFDIE
-DWARFDebugInfo::GetDIE(const DIERef &die_ref) {
-  DWARFUnit *cu = GetUnit(die_ref);
-  if (cu)
-return cu->GetNonSkeletonUnit().GetDIE(die_ref.die_offset());
+DWARFDebugInfo::GetDIE(DIERef::Section section, dw_offset_t die_offset) {
+  if (DWARFUnit *cu = GetUnitContainingDIEOffset(section, die_offset))
+return cu->GetNonSkeletonUnit().GetDIE(die_offset);
   return DWARFDIE(); // Not found
 }
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
index 456ebd908ccb2..4706b55d38ea9 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
@@ -38,11 +38,10 @@ class DWARFDebugInfo {
  uint32_t *idx_ptr = nullptr);
   DWARFUnit *GetUnitContainingDIEOffset(DIERef::Section section,
 dw_offset_t die_offset);
-  DWARFUnit *GetUnit(const DIERef &die_ref);
   DWARFUnit *GetSkeletonUnit(DWARFUnit *dwo_unit);
   DWARFTypeUnit *GetTypeUnitForHash(uint64_t hash);
   bool ContainsTypeUnits();
-  DWARFDIE GetDIE(const DIERef &die_ref);
+  DWARFDIE GetDIE(DIERef::Section section, dw_offset_t die_offset);
 
   enum {
 eDumpFlag_Verbose = (1 << 0),  // Verbose dumping
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
index 79400e36e04f3..31bbad3e56269 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
@@ -195,17 +195,17 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
 if (!ref)
   continue;
 
-DWARFUnit *cu = m_debug_info.GetUnit(*ref);
-if (!cu || !cu->Supports_DW_AT_APPLE_objc_complete_type()) {
-  incomplete_types.push_back(*ref);
-  continue;
-}
-
-DWARFDIE die = m_debug_info.GetDIE(*ref);
+SymbolFileDWARF &dwarf = *llvm::cast(
+m_module.GetSymbolFile()->GetBackingSymbolFile());
+DWARFDIE die = dwarf.GetDIE(*ref);
 if (!die) {
   ReportInvalidDIERef(*ref, class_name.GetStringRef());
   continue;
 }
+if (!die.GetCU()->Supports_DW_AT_APPLE_objc_complete_type()) {
+  incomplete_types.push_back(*ref);
+  continue;
+}
 
 if (die.GetAttributeValueAsUnsigned(DW_AT_APPLE_objc_complete_type, 0)) {
   // If we find the complete version we're done.
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index f6f152726bf74..2bca27936c76b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1748,7 +1748,8 @@ SymbolFileDWARF::GetDIE(const DIERef &die_ref) {
 if (SymbolFileDWARFDebugMap *debug_map = GetDebugMapSymfile()) {
   symbol_file = debug_map->GetSymbolFileByOSOIndex(*file_index); // OSO 
case
   if (symbol_file)
-return symbol_file->DebugInfo().GetDIE(die_ref);
+return symbol_file->DebugInfo().GetDIE(die_ref.section(),
+  

[Lldb-commits] [lldb] [lldb] Remove DWARFDebugInfo DIERef footguns (PR #92894)

2024-05-21 Thread Pavel Labath via lldb-commits

https://github.com/labath created 
https://github.com/llvm/llvm-project/pull/92894

DWARFDebugInfo doesn't know how to resolve the "file_index" component of a 
DIERef. This patch removes GetUnit (in favor of existing 
GetUnitContainingDIEOffset) and changes GetDIE to take only the components it 
actually uses.

In the process it fixes GetCompleteObjCClass, although that bug was unlikely to 
be noticed, since ObjC is only really used on darwin, and split DWARF isn't a 
thing there.

>From e416051b09147b1083765795f711bb972e42a893 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Mon, 20 May 2024 14:51:52 +
Subject: [PATCH] [lldb] Remove DWARFDebugInfo DIERef footguns

DWARFDebugInfo doesn't know how to resolve the "file_index" component of
a DIERef. This patch removes GetUnit (in favor of existing
GetUnitContainingDIEOffset) and changes GetDIE to take only the
components it actually uses.

In the process it fixes GetCompleteObjCClass, although that bug was
unlikely to be noticed, since ObjC is only really used on darwin, and
split DWARF isn't a thing there.
---
 .../Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp| 11 +++
 .../Plugins/SymbolFile/DWARF/DWARFDebugInfo.h  |  3 +--
 .../SymbolFile/DWARF/DebugNamesDWARFIndex.cpp  | 14 +++---
 .../Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp   |  7 ---
 .../SymbolFile/DWARF/SymbolFileDWARFDwo.cpp|  2 +-
 5 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
index d28da728728e5..c37cc91e08ed1 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
@@ -222,10 +222,6 @@ DWARFUnit *DWARFDebugInfo::GetUnitAtOffset(DIERef::Section 
section,
   return result;
 }
 
-DWARFUnit *DWARFDebugInfo::GetUnit(const DIERef &die_ref) {
-  return GetUnitContainingDIEOffset(die_ref.section(), die_ref.die_offset());
-}
-
 DWARFUnit *
 DWARFDebugInfo::GetUnitContainingDIEOffset(DIERef::Section section,
dw_offset_t die_offset) {
@@ -253,9 +249,8 @@ bool DWARFDebugInfo::ContainsTypeUnits() {
 //
 // Get the DIE (Debug Information Entry) with the specified offset.
 DWARFDIE
-DWARFDebugInfo::GetDIE(const DIERef &die_ref) {
-  DWARFUnit *cu = GetUnit(die_ref);
-  if (cu)
-return cu->GetNonSkeletonUnit().GetDIE(die_ref.die_offset());
+DWARFDebugInfo::GetDIE(DIERef::Section section, dw_offset_t die_offset) {
+  if (DWARFUnit *cu = GetUnitContainingDIEOffset(section, die_offset))
+return cu->GetNonSkeletonUnit().GetDIE(die_offset);
   return DWARFDIE(); // Not found
 }
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
index 456ebd908ccb2..4706b55d38ea9 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
@@ -38,11 +38,10 @@ class DWARFDebugInfo {
  uint32_t *idx_ptr = nullptr);
   DWARFUnit *GetUnitContainingDIEOffset(DIERef::Section section,
 dw_offset_t die_offset);
-  DWARFUnit *GetUnit(const DIERef &die_ref);
   DWARFUnit *GetSkeletonUnit(DWARFUnit *dwo_unit);
   DWARFTypeUnit *GetTypeUnitForHash(uint64_t hash);
   bool ContainsTypeUnits();
-  DWARFDIE GetDIE(const DIERef &die_ref);
+  DWARFDIE GetDIE(DIERef::Section section, dw_offset_t die_offset);
 
   enum {
 eDumpFlag_Verbose = (1 << 0),  // Verbose dumping
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
index 79400e36e04f3..31bbad3e56269 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
@@ -195,17 +195,17 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
 if (!ref)
   continue;
 
-DWARFUnit *cu = m_debug_info.GetUnit(*ref);
-if (!cu || !cu->Supports_DW_AT_APPLE_objc_complete_type()) {
-  incomplete_types.push_back(*ref);
-  continue;
-}
-
-DWARFDIE die = m_debug_info.GetDIE(*ref);
+SymbolFileDWARF &dwarf = *llvm::cast(
+m_module.GetSymbolFile()->GetBackingSymbolFile());
+DWARFDIE die = dwarf.GetDIE(*ref);
 if (!die) {
   ReportInvalidDIERef(*ref, class_name.GetStringRef());
   continue;
 }
+if (!die.GetCU()->Supports_DW_AT_APPLE_objc_complete_type()) {
+  incomplete_types.push_back(*ref);
+  continue;
+}
 
 if (die.GetAttributeValueAsUnsigned(DW_AT_APPLE_objc_complete_type, 0)) {
   // If we find the complete version we're done.
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index f6f152726bf74..2bca27936c76b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+

[Lldb-commits] [lldb] 45a5d8d - [lldb] Clean up unused includes in DebugNamesDWARFIndex

2024-05-21 Thread Pavel Labath via lldb-commits

Author: Pavel Labath
Date: 2024-05-21T10:48:39Z
New Revision: 45a5d8d6dba6156c24825b3a04378e999f8af82d

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

LOG: [lldb] Clean up unused includes in DebugNamesDWARFIndex

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
index fcf29470b9485..79400e36e04f3 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
@@ -9,7 +9,7 @@
 #include "Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h"
 #include "Plugins/SymbolFile/DWARF/DWARFDebugInfo.h"
 #include "Plugins/SymbolFile/DWARF/DWARFDeclContext.h"
-#include "Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h"
+#include "Plugins/SymbolFile/DWARF/LogChannelDWARF.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Utility/RegularExpression.h"
 #include "lldb/Utility/Stream.h"

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h
index 392ec559dfb12..81fb8f88b805a 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h
@@ -10,7 +10,6 @@
 #define LLDB_SOURCE_PLUGINS_SYMBOLFILE_DWARF_DEBUGNAMESDWARFINDEX_H
 
 #include "Plugins/SymbolFile/DWARF/DWARFIndex.h"
-#include "Plugins/SymbolFile/DWARF/LogChannelDWARF.h"
 #include "Plugins/SymbolFile/DWARF/ManualDWARFIndex.h"
 #include "Plugins/SymbolFile/DWARF/SymbolFileDWARF.h"
 #include "lldb/Utility/ConstString.h"



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


[Lldb-commits] [lldb] [lldb/dwarf] Fix DW_IDX_parent processing for split dwarf (PR #92745)

2024-05-21 Thread Pavel Labath via lldb-commits

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


[Lldb-commits] [lldb] 9677e81 - [lldb/dwarf] Fix DW_IDX_parent processing for split dwarf (#92745)

2024-05-21 Thread via lldb-commits

Author: Pavel Labath
Date: 2024-05-21T12:45:59+02:00
New Revision: 9677e8171c19f1a15c0234724f083bc9473c545a

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

LOG: [lldb/dwarf] Fix DW_IDX_parent processing for split dwarf (#92745)

DWARFDebugInfo only knows how to resolve references in its own file, but
in split dwarf, the index entries will refer to DIEs in the separate
(DWO) file. To resolve the DIERef correctly we'd either need to go
through the SymbolFileDWARF to get the full logic for resolving a
DIERef, or use the fact that ToDIERef already looks up the correct unit
while computing its result.

This patch does the latter.

This bug manifested itself in not being able to find type definitions
for types in namespaces, so I've modified one of our type resolving test
cases to run with debug_names, and added a namespaced class into it (it
originally contained only a top-level class).

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h
lldb/test/API/lang/cpp/limit-debug-info/Makefile
lldb/test/API/lang/cpp/limit-debug-info/TestWithLimitDebugInfo.py
lldb/test/API/lang/cpp/limit-debug-info/base.cpp
lldb/test/API/lang/cpp/limit-debug-info/base.h
lldb/test/API/lang/cpp/limit-debug-info/derived.cpp
lldb/test/API/lang/cpp/limit-debug-info/derived.h
lldb/test/API/lang/cpp/limit-debug-info/main.cpp
lldb/unittests/SymbolFile/DWARF/DWARFDIETest.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
index 44febcfac3b00..d28da728728e5 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
@@ -259,9 +259,3 @@ DWARFDebugInfo::GetDIE(const DIERef &die_ref) {
 return cu->GetNonSkeletonUnit().GetDIE(die_ref.die_offset());
   return DWARFDIE(); // Not found
 }
-
-llvm::StringRef DWARFDebugInfo::PeekDIEName(const DIERef &die_ref) {
-  if (DWARFUnit *cu = GetUnit(die_ref))
-return cu->GetNonSkeletonUnit().PeekDIEName(die_ref.die_offset());
-  return llvm::StringRef();
-}

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
index c1f0cb0203fb7..456ebd908ccb2 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
@@ -44,11 +44,6 @@ class DWARFDebugInfo {
   bool ContainsTypeUnits();
   DWARFDIE GetDIE(const DIERef &die_ref);
 
-  /// Returns the AT_Name of this DIE, if it exists, without parsing the entire
-  /// compile unit. An empty is string is returned upon error or if the
-  /// attribute is not present.
-  llvm::StringRef PeekDIEName(const DIERef &die_ref);
-
   enum {
 eDumpFlag_Verbose = (1 << 0),  // Verbose dumping
 eDumpFlag_ShowForm = (1 << 1), // Show the DW_form type

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
index 4da0d56fdcacb..fcf29470b9485 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
@@ -48,26 +48,30 @@ DebugNamesDWARFIndex::GetUnits(const DebugNames 
&debug_names) {
   return result;
 }
 
-std::optional
-DebugNamesDWARFIndex::ToDIERef(const DebugNames::Entry &entry) const {
+DWARFUnit *
+DebugNamesDWARFIndex::GetNonSkeletonUnit(const DebugNames::Entry &entry) const 
{
   // Look for a DWARF unit offset (CU offset or local TU offset) as they are
   // both offsets into the .debug_info section.
   std::optional unit_offset = entry.getCUOffset();
   if (!unit_offset) {
 unit_offset = entry.getLocalTUOffset();
 if (!unit_offset)
-  return std::nullopt;
+  return nullptr;
   }
 
   DWARFUnit *cu =
   m_debug_info.GetUnitAtOffset(DIERef::Section::DebugInfo, *unit_offset);
-  if (!cu)
-return std::nullopt;
+  return cu ? &cu->GetNonSkeletonUnit() : nullptr;
+}
 
-  cu = &cu->GetNonSkeletonUnit();
+std::optional
+DebugNamesDWARFIndex::ToDIERef(const DebugNames::Entry &entry) const {
+  DWARFUnit *unit = GetNonSkeletonUnit(entry);
+  if (!unit)
+return std::nullopt;
   if (std::optional die_offset = entry.getDIEUnitOffset())
-return DIERef(cu->GetSymbolFileDWARF().GetFileIndex(),
-  DIERef::Section::DebugInfo, cu->GetOffset() + *die_offset);
+return DIERef(unit->GetSymbolFileDWARF().GetFileIndex(),
+  DIERef::Section::DebugInfo, unit->GetOffset() + *die_offset);
 

[Lldb-commits] [lldb] [lldb/dwarf] Fix DW_IDX_parent processing for split dwarf (PR #92745)

2024-05-21 Thread Pavel Labath via lldb-commits


@@ -9,7 +9,7 @@
 #include "Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h"
 #include "Plugins/SymbolFile/DWARF/DWARFDebugInfo.h"
 #include "Plugins/SymbolFile/DWARF/DWARFDeclContext.h"
-#include "Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h"
+#include "Plugins/SymbolFile/DWARF/LogChannelDWARF.h"

labath wrote:

Not exactly. I wanted to remove (unused) SymbolFileDWARFDwo since it was 
potentially signalling breaking of abstractions, and then I got carried away 
include gardening (my editor now highlights unused headers :/).

Let me put those in separately.

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


[Lldb-commits] [lldb] [lldb/dwarf] Fix DW_IDX_parent processing for split dwarf (PR #92745)

2024-05-21 Thread Pavel Labath via lldb-commits

https://github.com/labath updated 
https://github.com/llvm/llvm-project/pull/92745

>From ae72d530c723a8d0fb2eac38224e8cf74cc43e70 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Mon, 20 May 2024 12:30:46 +
Subject: [PATCH 1/2] [lldb/dwarf] Fix DW_IDX_parent processing for split dwarf

DWARFDebugInfo only knows how to resolve references in its own file, but
in split dwarf, the index entries will refer to DIEs in the separate
(DWO) file. To resolve the DIERef correctly we'd either need to go
through the SymbolFileDWARF to get the full logic for resolving a
DIERef, or use the fact that ToDIERef already looks up the correct unit
while computing its result.

This patch does the latter.

This bug manifested itself in not being able to find type definitions
for types in namespaces, so I've modified one of our type resolving test
cases to run with debug_names, and added a namespaced class into it (it
originally contained only a top-level class).
---
 .../SymbolFile/DWARF/DWARFDebugInfo.cpp   |  6 ---
 .../Plugins/SymbolFile/DWARF/DWARFDebugInfo.h |  5 ---
 .../SymbolFile/DWARF/DebugNamesDWARFIndex.cpp | 28 +++--
 .../SymbolFile/DWARF/DebugNamesDWARFIndex.h   |  2 +-
 .../API/lang/cpp/limit-debug-info/Makefile|  2 -
 .../TestWithLimitDebugInfo.py | 40 +++
 .../API/lang/cpp/limit-debug-info/base.cpp|  9 ++---
 .../test/API/lang/cpp/limit-debug-info/base.h | 22 +++---
 .../API/lang/cpp/limit-debug-info/derived.cpp | 11 +++--
 .../API/lang/cpp/limit-debug-info/derived.h   | 37 -
 .../API/lang/cpp/limit-debug-info/main.cpp|  6 +--
 .../SymbolFile/DWARF/DWARFDIETest.cpp | 24 +--
 12 files changed, 106 insertions(+), 86 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
index 44febcfac3b00..d28da728728e5 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
@@ -259,9 +259,3 @@ DWARFDebugInfo::GetDIE(const DIERef &die_ref) {
 return cu->GetNonSkeletonUnit().GetDIE(die_ref.die_offset());
   return DWARFDIE(); // Not found
 }
-
-llvm::StringRef DWARFDebugInfo::PeekDIEName(const DIERef &die_ref) {
-  if (DWARFUnit *cu = GetUnit(die_ref))
-return cu->GetNonSkeletonUnit().PeekDIEName(die_ref.die_offset());
-  return llvm::StringRef();
-}
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
index c1f0cb0203fb7..456ebd908ccb2 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
@@ -44,11 +44,6 @@ class DWARFDebugInfo {
   bool ContainsTypeUnits();
   DWARFDIE GetDIE(const DIERef &die_ref);
 
-  /// Returns the AT_Name of this DIE, if it exists, without parsing the entire
-  /// compile unit. An empty is string is returned upon error or if the
-  /// attribute is not present.
-  llvm::StringRef PeekDIEName(const DIERef &die_ref);
-
   enum {
 eDumpFlag_Verbose = (1 << 0),  // Verbose dumping
 eDumpFlag_ShowForm = (1 << 1), // Show the DW_form type
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
index 4da0d56fdcacb..79400e36e04f3 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
@@ -9,7 +9,7 @@
 #include "Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h"
 #include "Plugins/SymbolFile/DWARF/DWARFDebugInfo.h"
 #include "Plugins/SymbolFile/DWARF/DWARFDeclContext.h"
-#include "Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h"
+#include "Plugins/SymbolFile/DWARF/LogChannelDWARF.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Utility/RegularExpression.h"
 #include "lldb/Utility/Stream.h"
@@ -48,26 +48,30 @@ DebugNamesDWARFIndex::GetUnits(const DebugNames 
&debug_names) {
   return result;
 }
 
-std::optional
-DebugNamesDWARFIndex::ToDIERef(const DebugNames::Entry &entry) const {
+DWARFUnit *
+DebugNamesDWARFIndex::GetNonSkeletonUnit(const DebugNames::Entry &entry) const 
{
   // Look for a DWARF unit offset (CU offset or local TU offset) as they are
   // both offsets into the .debug_info section.
   std::optional unit_offset = entry.getCUOffset();
   if (!unit_offset) {
 unit_offset = entry.getLocalTUOffset();
 if (!unit_offset)
-  return std::nullopt;
+  return nullptr;
   }
 
   DWARFUnit *cu =
   m_debug_info.GetUnitAtOffset(DIERef::Section::DebugInfo, *unit_offset);
-  if (!cu)
-return std::nullopt;
+  return cu ? &cu->GetNonSkeletonUnit() : nullptr;
+}
 
-  cu = &cu->GetNonSkeletonUnit();
+std::optional
+DebugNamesDWARFIndex::ToDIERef(const DebugNames::Entry &entry) const {
+  DWARFUnit *unit = GetNonSkeletonUnit(entry);
+  if (!unit)
+return std::nullopt;
   if (std::optional die_offset = entry.getDIE

[Lldb-commits] [lldb] Improve performance of .debug_names lookups when DW_IDX_parent attributes are used (PR #91808)

2024-05-21 Thread Pavel Labath via lldb-commits

labath wrote:

> What is "nameless index entry"? I don't quite understand from the spec.

```
It is possible that an indexed debugging information entry has a parent that is
not indexed (for example, if its parent does not have a name attribute). In 
such a
case, a parent attribute may point to a nameless index entry (that is, one that
cannot be reached from any entry in the name table), or it may point to the
nearest ancestor that does have an index entry.
```

My interpretation of this paragraph is that we're allowed to insert extra 
"floating" entries into the debug_names table. Such entries must not be 
reachable from the hash or name tables, but they can be referred to via 
DW_IDX_parent_entry attributes of other (reachable) entries.

Using Greg's example from 
https://github.com/llvm/llvm-project/pull/91808#issue-2290404282, I believe we 
could add a debug_names entry for `std::ios_base` (and refer to it from the 
entry for `std::ios_base::seekdir`), as long as the ios_base entry was not 
present in any of the name tables.

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


[Lldb-commits] [lldb] Improve performance of .debug_names lookups when DW_IDX_parent attributes are used (PR #91808)

2024-05-21 Thread Pavel Labath via lldb-commits

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


[Lldb-commits] [lldb] Improve performance of .debug_names lookups when DW_IDX_parent attributes are used (PR #91808)

2024-05-21 Thread Pavel Labath via lldb-commits

https://github.com/labath commented:

I think #77696 is justification enough to add this check, but I don't think we 
should be implicating DW_IDX_parent_entries until we know how those came about. 
Both me and David have tried to produce entries like you describe and failed 
(in fact I was not able to produce a DW_IDX_parent_entries referring to any 
kind of class type whatsoever (only to namespace entries)).

Even when this check goes in, I think it would be useful to get to the bottom 
of the DW_IDX_parent_entries issue, if nothing else, then because it may affect 
the decision of when/if to remove this workaround.

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


[Lldb-commits] [lldb] Improve performance of .debug_names lookups when DW_IDX_parent attributes are used (PR #91808)

2024-05-21 Thread Pavel Labath via lldb-commits


@@ -83,6 +83,10 @@ bool DebugNamesDWARFIndex::ProcessEntry(
   DWARFDIE die = dwarf.GetDIE(*ref);
   if (!die)
 return true;
+  // Watch out for forward declarations that appear in the .debug_names tables
+  // only due to being there for a DW_IDX_parent.

labath wrote:

```suggestion
  // Clang erroneously emits index entries for declaration DIEs in case when the
  // definition is in a type unit (llvm.org/pr77696). Weed those out.
```

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


[Lldb-commits] [lldb] SBDebugger: define callback_token_t for win32 (PR #92870)

2024-05-21 Thread antoine moynault via lldb-commits

antmox wrote:

fixed elsewhere

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


[Lldb-commits] [lldb] SBDebugger: define callback_token_t for win32 (PR #92870)

2024-05-21 Thread antoine moynault via lldb-commits

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


[Lldb-commits] [lldb] SBDebugger: define callback_token_t for win32 (PR #92870)

2024-05-21 Thread Pavel Labath via lldb-commits

labath wrote:

Moving the typedef out of platform-specific code would be a better, as this is 
not in any way platform-specific. I just pushed something along those lines.

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


[Lldb-commits] [lldb] a098bea - [lldb] Move callback_token_t out of #ifdef windows

2024-05-21 Thread Pavel Labath via lldb-commits

Author: Pavel Labath
Date: 2024-05-21T09:37:38Z
New Revision: a098beaff7670e5986b790b6ba93999fa21c6b48

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

LOG: [lldb] Move callback_token_t out of #ifdef windows

Also make it a int32_t to match the surrounding code.

Added: 


Modified: 
lldb/include/lldb/lldb-types.h

Removed: 




diff  --git a/lldb/include/lldb/lldb-types.h b/lldb/include/lldb/lldb-types.h
index 8e717c62d3259..d88b8232ee6b4 100644
--- a/lldb/include/lldb/lldb-types.h
+++ b/lldb/include/lldb/lldb-types.h
@@ -62,7 +62,6 @@ typedef void *thread_arg_t; // Host thread 
argument type
 typedef void *thread_result_t;  // Host thread result type
 typedef void *(*thread_func_t)(void *); // Host thread function type
 typedef int pipe_t; // Host pipe type
-typedef int callback_token_t;
 
 #endif // _WIN32
 
@@ -79,6 +78,7 @@ typedef bool 
(*ExpressionCancelCallback)(ExpressionEvaluationPhase phase,
 typedef void *ScriptObjectPtr;
 
 typedef uint64_t addr_t;
+typedef int32_t callback_token_t;
 typedef uint64_t user_id_t;
 typedef uint64_t pid_t;
 typedef uint64_t tid_t;



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


[Lldb-commits] [lldb] Reapply "[lldb/aarch64] Fix unwinding when signal interrupts a leaf f… (PR #92503)

2024-05-21 Thread Pavel Labath via lldb-commits

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


[Lldb-commits] [lldb] bbd54e0 - Reapply "[lldb/aarch64] Fix unwinding when signal interrupts a leaf f… (#92503)

2024-05-21 Thread via lldb-commits

Author: Pavel Labath
Date: 2024-05-21T10:56:26+02:00
New Revision: bbd54e08b08f5ccd38c4665178e65c58f7b14459

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

LOG: Reapply "[lldb/aarch64] Fix unwinding when signal interrupts a leaf f… 
(#92503)

…unction (#91321)"

This reapplies fd1bd53ba5a06f344698a55578f6a5d79c457e30, which was
reverted due to a test failure on aarch64/windows. The failure was
caused by a combination of several factors:
- clang targeting aarch64-windows (unlike msvc, and unlike clang
targeting other aarch64 platforms) defaults to -fomit-frame-pointers
- lldb's code for looking up register values for `` unwind rules
is recursive
- the test binary creates a very long chain of fp-less function frames
(it manages to fit about 22k frames before it blows its stack)

Together, these things have caused lldb to recreate the same deep
recursion when unwinding through this, and blow its own stack as well.
Since lldb frames are larger, about 4k frames like this was sufficient
to trigger the stack overflow.

This version of the patch works around this problem by increasing the
frame size of the test binary, thereby causing it to blow its stack
sooner. This doesn't fix the issue -- the same problem can occur with a
real binary -- but it's not very likely, as it requires an infinite
recursion in a simple (so it doesn't use the frame pointer) function
with a very small frame (so you can fit a lot of them on the stack).

A more principled fix would be to make lldb's lookup code non-recursive,
but I believe that's out of scope for this patch.

The original patch description follows:

A leaf function may not store the link register to stack, but we it can
still end up being a non-zero frame if it gets interrupted by a signal.
Currently, we were unable to unwind past this function because we could
not read the link register value.

To make this work, this patch:
- changes the function-entry unwind plan to include the `fp|lr = `
rules. This in turn necessitated an adjustment in the generic
instruction emulation logic to ensure that `lr=[sp-X]` can override the
`` rule.
- allows the `` rule for pc and lr in all
`m_all_registers_available` frames (and not just frame zero).

The test verifies that we can unwind in a situation like this, and that
the backtrace matches the one we computed before getting a signal.

Added: 
lldb/test/Shell/Unwind/Inputs/signal-in-leaf-function-aarch64.c
lldb/test/Shell/Unwind/signal-in-leaf-function-aarch64.test

Modified: 
lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp

lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
lldb/source/Target/RegisterContextUnwind.cpp
lldb/test/API/functionalities/bt-interrupt/main.c
lldb/unittests/UnwindAssembly/ARM64/TestArm64InstEmulation.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp 
b/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
index 6ca4fb052457e..62ecac3e0831d 100644
--- a/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
+++ b/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
@@ -444,6 +444,8 @@ bool EmulateInstructionARM64::CreateFunctionEntryUnwind(
 
   // Our previous Call Frame Address is the stack pointer
   row->GetCFAValue().SetIsRegisterPlusOffset(gpr_sp_arm64, 0);
+  row->SetRegisterLocationToSame(gpr_lr_arm64, /*must_replace=*/false);
+  row->SetRegisterLocationToSame(gpr_fp_arm64, /*must_replace=*/false);
 
   unwind_plan.AppendRow(row);
   unwind_plan.SetSourceName("EmulateInstructionARM64");

diff  --git 
a/lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
 
b/lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
index c4a171ec7d01b..49edd40544e32 100644
--- 
a/lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
+++ 
b/lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
@@ -424,8 +424,6 @@ size_t UnwindAssemblyInstEmulation::WriteMemory(
 log->PutString(strm.GetString());
   }
 
-  const bool cant_replace = false;
-
   switch (context.type) {
   default:
   case EmulateInstruction::eContextInvalid:
@@ -467,7 +465,7 @@ size_t UnwindAssemblyInstEmulation::WriteMemory(
 m_pushed_regs[reg_num] = addr;
 const int32_t offset = addr - m_initial_sp;
 m_curr_row->SetRegisterLocationToAtCFAPlusOffset(reg_num, offset,
- cant_replace);
+ /*can_replace=*/true);
 m_curr_row_modified = true;
   }
 }

diff  --git a/lldb/source/Target/RegisterContextUnwind.cpp 
b/lldb/source/Tar

[Lldb-commits] [lldb] Reapply "[lldb/aarch64] Fix unwinding when signal interrupts a leaf f… (PR #92503)

2024-05-21 Thread Pavel Labath via lldb-commits

https://github.com/labath updated 
https://github.com/llvm/llvm-project/pull/92503

>From 47858edddfbccf989213d61f3761fcdb04814839 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Fri, 17 May 2024 06:34:08 +
Subject: [PATCH 1/2] Reapply "[lldb/aarch64] Fix unwinding when signal
 interrupts a leaf function (#91321)"

This reapplies fd1bd53ba5a06f344698a55578f6a5d79c457e30, which was
reverted due to a test failure on aarch64/windows. The failure was
caused by a combination of several factors:
- clang targeting aarch64-windows (unlike msvc, and unlike clang
  targeting other aarch64 platforms) defaults to -fomit-frame-pointers
- lldb's code for looking up register values for `` unwind rules
  is recursive
- the test binary creates a very long chain of fp-less function frames
  (it manages to fit about 22k frames before it blows its stack)

Together, these things have caused lldb to recreate the same deep
recursion when unwinding through this, and blow its own stack as well.
Since lldb frames are larger, about 4k frames like this was sufficient
to trigger the stack overflow.

This version of the patch works around this problem by increasing the
frame size of the test binary, thereby causing it to blow its stack
sooner. This doesn't fix the issue -- the same problem can occur with a
real binary -- but it's not very likely, as it requires an infinite
recursion in a simple (so it doesn't use the frame pointer) function
with a very small frame (so you can fit a lot of them on the stack).

A more principled fix would be to make lldb's lookup code non-recursive,
but I believe that's out of scope for this patch.

The original patch description follows:

A leaf function may not store the link register to stack, but we it can
still end up being a non-zero frame if it gets interrupted by a signal.
Currently, we were unable to unwind past this function because we could
not read the link register value.

To make this work, this patch:
- changes the function-entry unwind plan to include the `fp|lr = `
rules. This in turn necessitated an adjustment in the generic
instruction emulation logic to ensure that `lr=[sp-X]` can override the
`` rule.
- allows the `` rule for pc and lr in all
`m_all_registers_available` frames (and not just frame zero).

The test verifies that we can unwind in a situation like this, and that
the backtrace matches the one we computed before getting a signal.
---
 .../ARM64/EmulateInstructionARM64.cpp |  2 ++
 .../UnwindAssemblyInstEmulation.cpp   |  4 +--
 lldb/source/Target/RegisterContextUnwind.cpp  |  6 ++---
 .../API/functionalities/bt-interrupt/main.c   |  1 +
 .../Inputs/signal-in-leaf-function-aarch64.c  | 15 +++
 .../signal-in-leaf-function-aarch64.test  | 27 +++
 .../ARM64/TestArm64InstEmulation.cpp  | 24 ++---
 7 files changed, 69 insertions(+), 10 deletions(-)
 create mode 100644 
lldb/test/Shell/Unwind/Inputs/signal-in-leaf-function-aarch64.c
 create mode 100644 lldb/test/Shell/Unwind/signal-in-leaf-function-aarch64.test

diff --git a/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp 
b/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
index 6ca4fb052457e..62ecac3e0831d 100644
--- a/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
+++ b/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
@@ -444,6 +444,8 @@ bool EmulateInstructionARM64::CreateFunctionEntryUnwind(
 
   // Our previous Call Frame Address is the stack pointer
   row->GetCFAValue().SetIsRegisterPlusOffset(gpr_sp_arm64, 0);
+  row->SetRegisterLocationToSame(gpr_lr_arm64, /*must_replace=*/false);
+  row->SetRegisterLocationToSame(gpr_fp_arm64, /*must_replace=*/false);
 
   unwind_plan.AppendRow(row);
   unwind_plan.SetSourceName("EmulateInstructionARM64");
diff --git 
a/lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
 
b/lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
index c4a171ec7d01b..49edd40544e32 100644
--- 
a/lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
+++ 
b/lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
@@ -424,8 +424,6 @@ size_t UnwindAssemblyInstEmulation::WriteMemory(
 log->PutString(strm.GetString());
   }
 
-  const bool cant_replace = false;
-
   switch (context.type) {
   default:
   case EmulateInstruction::eContextInvalid:
@@ -467,7 +465,7 @@ size_t UnwindAssemblyInstEmulation::WriteMemory(
 m_pushed_regs[reg_num] = addr;
 const int32_t offset = addr - m_initial_sp;
 m_curr_row->SetRegisterLocationToAtCFAPlusOffset(reg_num, offset,
- cant_replace);
+ /*can_replace=*/true);
 m_curr_row_modified = true;
   }
 }
diff --git a/lldb/source/Target/RegisterContextUnwind.cpp 
b/lldb/source/Target/Reg

[Lldb-commits] [lldb] Reapply "[lldb/aarch64] Fix unwinding when signal interrupts a leaf f… (PR #92503)

2024-05-21 Thread Pavel Labath via lldb-commits

labath wrote:

> Yes, originally lldb's unwinder was recursive for any register propagation 
> and it was easy to hit the problem of lldb blowing out its own stack on a 
> recursive inferior that had crashed. I changed most of the propagation to a 
> loop to solve this (years and years ago) but it looks like we still have a 
> case where it is recursing.
> 
> We still need to skip the test case on macOS until I can come up with some 
> idea to get proper unwind instruction for sigtramp on arm64. Most of the CI 
> bots are x86_64 so it may pass on them, but that's The Past and I would 
> prefer to skip this on Darwin until I can figure something out, I wrote a 
> little TODO on myself in rdar://128031075

Sounds good (I meant to xfail this on darwin, but it looks like I forgot).

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


[Lldb-commits] [lldb] [lldb-dap] Don't send expanded descriptions for "hover" expressions (PR #92726)

2024-05-21 Thread Pavel Labath via lldb-commits

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


[Lldb-commits] [lldb] af8f155 - [lldb-dap] Don't send expanded descriptions for "hover" expressions (#92726)

2024-05-21 Thread via lldb-commits

Author: Pavel Labath
Date: 2024-05-21T10:37:41+02:00
New Revision: af8f1554b8e7844304ce61b49b06e5b7946e9c47

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

LOG: [lldb-dap] Don't send expanded descriptions for "hover" expressions 
(#92726)

VSCode will automatically ask for the children (in structured form) so
there's no point in sending the textual representation. This can make
displaying hover popups for complex variables with complicated data
formatters much faster. See discussion on #77026 for context.

Added: 


Modified: 
lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py
lldb/tools/lldb-dap/JSONUtils.cpp

Removed: 




diff  --git a/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py 
b/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
index 57cabf5b7f411..68c57ad775544 100644
--- a/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
+++ b/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
@@ -27,7 +27,7 @@ def assertEvaluateFailure(self, expression):
 )
 
 def isResultExpandedDescription(self):
-return self.context == "repl" or self.context == "hover"
+return self.context == "repl"
 
 def isExpressionParsedExpected(self):
 return self.context != "hover"

diff  --git a/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py 
b/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py
index 07ab6d5a63eb6..57c17e5ea9d3d 100644
--- a/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py
+++ b/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py
@@ -502,29 +502,12 @@ def do_test_scopes_and_evaluate_expansion(self, 
enableAutoVariableSummaries: boo
 },
 "hover": {
 "equals": {"type": "PointType"},
-"equals": {
-"result": """(PointType) pt = {
-  x = 11
-  y = 22
-  buffer = {
-[0] = 0
-[1] = 1
-[2] = 2
-[3] = 3
-[4] = 4
-[5] = 5
-[6] = 6
-[7] = 7
-[8] = 8
-[9] = 9
-[10] = 10
-[11] = 11
-[12] = 12
-[13] = 13
-[14] = 14
-[15] = 15
-  }
-}"""
+"startswith": {
+"result": (
+"{x:11, y:22, buffer:{...}}"
+if enableAutoVariableSummaries
+else "PointType @ 0x"
+)
 },
 "missing": ["indexedVariables"],
 "hasVariablesReference": True,

diff  --git a/lldb/tools/lldb-dap/JSONUtils.cpp 
b/lldb/tools/lldb-dap/JSONUtils.cpp
index bec277332bcf0..069877dbab339 100644
--- a/lldb/tools/lldb-dap/JSONUtils.cpp
+++ b/lldb/tools/lldb-dap/JSONUtils.cpp
@@ -1065,9 +1065,9 @@ llvm::json::Object 
VariableDescription::GetVariableExtensionsJSON() {
 }
 
 std::string VariableDescription::GetResult(llvm::StringRef context) {
-  // In repl and hover context, the results can be displayed as multiple lines
-  // so more detailed descriptions can be returned.
-  if (context != "repl" && context != "hover")
+  // In repl context, the results can be displayed as multiple lines so more
+  // detailed descriptions can be returned.
+  if (context != "repl")
 return display_value;
 
   if (!v.IsValid())



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


[Lldb-commits] [lldb] SBDebugger: define callback_token_t for win32 (PR #92870)

2024-05-21 Thread Martin Storsjö via lldb-commits

mstorsjo wrote:

+1, this fixes my build errors for Windows targets as well: 
https://github.com/mstorsjo/llvm-mingw/actions/runs/9167001362/job/25206642195

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


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-21 Thread antoine moynault via lldb-commits

antmox wrote:

@royitaqi @clayborg I proposed a fix here : 
https://github.com/llvm/llvm-project/pull/92870

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


[Lldb-commits] [lldb] SBDebugger: define callback_token_t for win32 (PR #92870)

2024-05-21 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: antoine moynault (antmox)


Changes

fix lldb-aarch64-windows bot failure introduced by #89868 
https://lab.llvm.org/buildbot/#/builders/219/builds/11583

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


1 Files Affected:

- (modified) lldb/include/lldb/lldb-types.h (+1) 


``diff
diff --git a/lldb/include/lldb/lldb-types.h b/lldb/include/lldb/lldb-types.h
index 8e717c62d3259..6b9289f0a0743 100644
--- a/lldb/include/lldb/lldb-types.h
+++ b/lldb/include/lldb/lldb-types.h
@@ -47,6 +47,7 @@ typedef void *thread_arg_t;   // Host 
thread argument type
 typedef unsigned thread_result_t; // Host thread result type
 typedef thread_result_t (*thread_func_t)(void *); // Host thread function type
 typedef void *pipe_t; // Host pipe type is HANDLE
+typedef int callback_token_t;
 
 #else
 

``




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


[Lldb-commits] [lldb] SBDebugger: define callback_token_t for win32 (PR #92870)

2024-05-21 Thread antoine moynault via lldb-commits

https://github.com/antmox created 
https://github.com/llvm/llvm-project/pull/92870

fix lldb-aarch64-windows bot failure introduced by #89868 
https://lab.llvm.org/buildbot/#/builders/219/builds/11583

>From 83ac7ff11a694795dccf3fa09c82ddab5d0096f3 Mon Sep 17 00:00:00 2001
From: Antoine Moynault 
Date: Tue, 21 May 2024 07:21:10 +
Subject: [PATCH] SBDebugger: define callback_token_t for win32

fix lldb-aarch64-windows bot failure introduced by #89868
https://lab.llvm.org/buildbot/#/builders/219/builds/11583
---
 lldb/include/lldb/lldb-types.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lldb/include/lldb/lldb-types.h b/lldb/include/lldb/lldb-types.h
index 8e717c62d3259..6b9289f0a0743 100644
--- a/lldb/include/lldb/lldb-types.h
+++ b/lldb/include/lldb/lldb-types.h
@@ -47,6 +47,7 @@ typedef void *thread_arg_t;   // Host 
thread argument type
 typedef unsigned thread_result_t; // Host thread result type
 typedef thread_result_t (*thread_func_t)(void *); // Host thread function type
 typedef void *pipe_t; // Host pipe type is HANDLE
+typedef int callback_token_t;
 
 #else
 

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