date:20231205

[Lldb-commits] [clang-tools-extra] [libc] [compiler-rt] [lldb] [flang] [clang] [llvm] [mlir] [DAGCombiner] Combine frem into fdiv+ftrunc+fma (PR #67642)

2023-12-05 Thread Qiu Chaofan via lldb-commits


ecnelises wrote:

I tested with a number of random floating values. In most of the cases, the 
expanded result is exactly the same as libcall result.

But when `fmod(a,b)` is very close to `b` (smaller than `1e-10`, for example, 
`fmod(521862.045173469, 31.048432006988875)`), the result would be totally 
wrong..  I'm thinking about a solution.

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

[Lldb-commits] [lldb] [lldb] Return index of element in ValueObject path instead of the element's value (PR #74413)

2023-12-05 Thread David Spickett via lldb-commits


DavidSpickett wrote:

I can see why the mistake was made, we have an index into a list of different 
indexes? Anyway, please add a test for this.

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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread David Spickett via lldb-commits

=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 



@@ -231,6 +231,25 @@ class Stream {
   /// The string to be output to the stream.
   size_t PutCString(llvm::StringRef cstr);
 
+  /// Output a C string to the stream with color highlighting.
+  ///
+  /// Print a C string \a text to the stream, applying red color highlighting 
to
+  /// the portions of the string that match the regex pattern \a pattern. The
+  /// pattern is matched as many times as possible throughout the string. If \a
+  /// pattern is nullptr, then no highlighting is applied.
+  ///
+  /// \param[in] text
+  /// The string to be output to the stream.
+  ///
+  /// \param[in] pattern
+  /// The regex pattern to match against the \a text string. Portions of \a
+  /// text matching this pattern will be colorized. If this parameter is
+  /// nullptr, highlighting is not performed.

DavidSpickett wrote:

Reminder to update this comment once the other changes have settled.

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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread David Spickett via lldb-commits

=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 



@@ -70,6 +72,31 @@ size_t Stream::PutCString(llvm::StringRef str) {
   return bytes_written;
 }
 
+void Stream::PutCStringColorHighlighted(llvm::StringRef text,
+const char *pattern) {
+  if (!pattern) {
+PutCString(text);
+return;
+  }
+
+  // If pattern is not nullptr, we should use color
+  llvm::Regex reg_pattern(pattern);
+  llvm::SmallVector matches;
+  llvm::StringRef remaining = text;
+  std::string format_str = lldb_private::ansi::FormatAnsiTerminalCodes(
+  "${ansi.fg.red}%.*s${ansi.normal}");

DavidSpickett wrote:

You might be able to get it from the exe_scope like this does:
```
bool Address::Dump(Stream *s, ExecutionContextScope *exe_scope, DumpStyle style,
   DumpStyle fallback_style, uint32_t addr_size,
   bool all_ranges) const {
```
But you won't always have a target. Which is a bit odd because there'd always 
be a settings object somewhere, if only you could get to it.

Seems like symbolcontext can have a target or not, and methods that definitely 
need one have it as a parameter. So that's the other way to go, add a parameter 
for it.

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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread David Spickett via lldb-commits

=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 



@@ -246,8 +246,8 @@ class Address {
   /// \see Address::DumpStyle
   bool Dump(Stream *s, ExecutionContextScope *exe_scope, DumpStyle style,
 DumpStyle fallback_style = DumpStyleInvalid,
-uint32_t addr_byte_size = UINT32_MAX,
-bool all_ranges = false) const;
+uint32_t addr_byte_size = UINT32_MAX, bool all_ranges = false,
+const char *pattern = nullptr) const;

DavidSpickett wrote:

What errors did you get?

Remember that optionals are "pointer like" when you want to get at the value 
within them, `*foo`, `foo->method()` etc. that trips me up sometimes. Also the 
default value would be ` = std::nullopt`.

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

[Lldb-commits] [lldb] [lldb] Correctly check and report error states in StackFrame.cpp (PR #74414)

2023-12-05 Thread David Spickett via lldb-commits


DavidSpickett wrote:

Is testing this possible?

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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread José Lira Junior via lldb-commits

@@ -246,8 +246,8 @@ class Address {
   /// \see Address::DumpStyle
   bool Dump(Stream *s, ExecutionContextScope *exe_scope, DumpStyle style,
 DumpStyle fallback_style = DumpStyleInvalid,
-uint32_t addr_byte_size = UINT32_MAX,
-bool all_ranges = false) const;
+uint32_t addr_byte_size = UINT32_MAX, bool all_ranges = false,
+const char *pattern = nullptr) const;

junior-jl wrote:

I apologize, I should have noted the errors. But as far as I remember, it was 
related to use of deleted functions and type conversions. I also tried passing 
the parameter as a reference thinking the error could be caused by copying. 

> Remember that optionals are "pointer like" when you want to get at the value 
> within them, *foo, foo->method() etc. that trips me up sometimes.

Hmm, I was trying to get `pattern.value()`, perhaps that was part of the 
problem.

> Also the default value would be  = std::nullopt

At least I got that right.

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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread David Spickett via lldb-commits

=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 



@@ -246,8 +246,8 @@ class Address {
   /// \see Address::DumpStyle
   bool Dump(Stream *s, ExecutionContextScope *exe_scope, DumpStyle style,
 DumpStyle fallback_style = DumpStyleInvalid,
-uint32_t addr_byte_size = UINT32_MAX,
-bool all_ranges = false) const;
+uint32_t addr_byte_size = UINT32_MAX, bool all_ranges = false,
+const char *pattern = nullptr) const;

DavidSpickett wrote:

Tbf I had to look up nullopt, I don't see it much. `.value` returns a reference 
to the contained value (assuming it has one), `->` does the same so either is 
fine.

Can you post the error message(s)? Don't need to update this change, just 
describe how you're constructing and passing it, that'll likely be enough.


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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread David Spickett via lldb-commits

=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 


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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread José Lira Junior via lldb-commits



@@ -70,6 +72,31 @@ size_t Stream::PutCString(llvm::StringRef str) {
   return bytes_written;
 }
 
+void Stream::PutCStringColorHighlighted(llvm::StringRef text,
+const char *pattern) {
+  if (!pattern) {
+PutCString(text);
+return;
+  }
+
+  // If pattern is not nullptr, we should use color
+  llvm::Regex reg_pattern(pattern);
+  llvm::SmallVector matches;
+  llvm::StringRef remaining = text;
+  std::string format_str = lldb_private::ansi::FormatAnsiTerminalCodes(
+  "${ansi.fg.red}%.*s${ansi.normal}");

junior-jl wrote:

I could have sworn I did this yesterday and it did not work. But I tried (again 
?) and it works now. Just checking if that's okay... This is how it is now: 

```cpp
llvm::StringRef ansi_prefix = 
exe_scope->CalculateTarget()->GetDebugger().GetRegexMatchAnsiPrefix();
llvm::StringRef ansi_suffix = 
exe_scope->CalculateTarget()->GetDebugger().GetRegexMatchAnsiSuffix();
```

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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread David Spickett via lldb-commits

=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 



@@ -246,8 +246,8 @@ class Address {
   /// \see Address::DumpStyle
   bool Dump(Stream *s, ExecutionContextScope *exe_scope, DumpStyle style,
 DumpStyle fallback_style = DumpStyleInvalid,
-uint32_t addr_byte_size = UINT32_MAX,
-bool all_ranges = false) const;
+uint32_t addr_byte_size = UINT32_MAX, bool all_ranges = false,
+const char *pattern = nullptr) const;

DavidSpickett wrote:

It may be caused by this https://godbolt.org/z/414Kzd18Y because llvm::Regex 
deletes the copy constructor. This is I think because it contains state about 
the matching. I think I should be able to move an llvm::Regex though but I 
haven't been able to get that to work either.

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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread José Lira Junior via lldb-commits



@@ -231,6 +231,25 @@ class Stream {
   /// The string to be output to the stream.
   size_t PutCString(llvm::StringRef cstr);
 
+  /// Output a C string to the stream with color highlighting.
+  ///
+  /// Print a C string \a text to the stream, applying red color highlighting 
to
+  /// the portions of the string that match the regex pattern \a pattern. The
+  /// pattern is matched as many times as possible throughout the string. If \a
+  /// pattern is nullptr, then no highlighting is applied.
+  ///
+  /// \param[in] text
+  /// The string to be output to the stream.
+  ///
+  /// \param[in] pattern
+  /// The regex pattern to match against the \a text string. Portions of \a
+  /// text matching this pattern will be colorized. If this parameter is
+  /// nullptr, highlighting is not performed.

junior-jl wrote:

Thank you. This also reminded me that we didn't update the comments in 
`SymbolContext.h` and `Address.h`. Added these as well.

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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread David Spickett via lldb-commits

=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 



@@ -246,8 +246,8 @@ class Address {
   /// \see Address::DumpStyle
   bool Dump(Stream *s, ExecutionContextScope *exe_scope, DumpStyle style,
 DumpStyle fallback_style = DumpStyleInvalid,
-uint32_t addr_byte_size = UINT32_MAX,
-bool all_ranges = false) const;
+uint32_t addr_byte_size = UINT32_MAX, bool all_ranges = false,
+const char *pattern = nullptr) const;

DavidSpickett wrote:

Regex is put into an optional 
[here](https://github.com/llvm/llvm-project/blob/e4710872e98a931c6d5e89bc965b778746ead2c0/mlir/lib/IR/Diagnostics.cpp#L640)
 and in one other place. See also `clang-tools-extra/clangd/ConfigCompile.cpp`.

Tried to recreate that in a small example but failed. See what you can do with 
it.

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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread José Lira Junior via lldb-commits



@@ -246,8 +246,8 @@ class Address {
   /// \see Address::DumpStyle
   bool Dump(Stream *s, ExecutionContextScope *exe_scope, DumpStyle style,
 DumpStyle fallback_style = DumpStyleInvalid,
-uint32_t addr_byte_size = UINT32_MAX,
-bool all_ranges = false) const;
+uint32_t addr_byte_size = UINT32_MAX, bool all_ranges = false,
+const char *pattern = nullptr) const;

junior-jl wrote:

> Tbf I had to look up nullopt, I don't see it much.

I search this as well. Actually, I never used `std::optional` before.

> Can you post the error message(s)? Don't need to update the PR, just describe 
> how you're constructing and passing it, that'll likely be enough.

Okay. I'll update the PR with the recent changes and will try to replicate the 
error and post here.

> It may be caused by this https://godbolt.org/z/414Kzd18Y because llvm::Regex 
> deletes the copy constructor. This is I think because it contains state about 
> the matching. I think I should be able to move an llvm::Regex though but I 
> haven't been able to get that to work either.

This is interesting. I believe this is similar to the error we were getting.

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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread José Lira Junior via lldb-commits



@@ -70,6 +72,31 @@ size_t Stream::PutCString(llvm::StringRef str) {
   return bytes_written;
 }
 
+void Stream::PutCStringColorHighlighted(llvm::StringRef text,
+const char *pattern) {
+  if (!pattern) {
+PutCString(text);
+return;
+  }
+
+  // If pattern is not nullptr, we should use color
+  llvm::Regex reg_pattern(pattern);
+  llvm::SmallVector matches;
+  llvm::StringRef remaining = text;
+  std::string format_str = lldb_private::ansi::FormatAnsiTerminalCodes(
+  "${ansi.fg.red}%.*s${ansi.normal}");

junior-jl wrote:

Actually, before pushing these, `check-lldb` failed because of this change.

You can check the log here: 
[https://pastebin.com/atfvLauV](https://pastebin.com/atfvLauV)

https://github.com/llvm/llvm-project/pull/69422
___
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 CompilerType class (second try). (PR #73472)

2023-12-05 Thread via lldb-commits


https://github.com/cmtice updated 
https://github.com/llvm/llvm-project/pull/73472

>From a063ebd8ee8bbd491fff3449bc20d663d2e501ea Mon Sep 17 00:00:00 2001
From: Caroline Tice 
Date: Sun, 26 Nov 2023 17:24:39 -0800
Subject: [PATCH 1/3] [LLDB] Add more helper functions to CompilerType class
 (second try).

This adds 23 new helper functions to LLDB's CompilerType class, things
like IsSmartPtrType, IsPromotableIntegerType,
GetNumberofNonEmptyBaseClasses, and GetTemplateArgumentType (to name a
few).

It also has run clang-format on the files CompilerType.{h,cpp}.

These helper functions are needed as part of the implementation for
the Data Inspection Language, (see
https://discourse.llvm.org/t/rfc-data-inspection-language/69893).
---
 lldb/include/lldb/Symbol/CompilerType.h |  56 -
 lldb/source/Symbol/CompilerType.cpp | 285 ++--
 2 files changed, 320 insertions(+), 21 deletions(-)

diff --git a/lldb/include/lldb/Symbol/CompilerType.h 
b/lldb/include/lldb/Symbol/CompilerType.h
index 0a9533a1ac0ef..a3331ad3269c0 100644
--- a/lldb/include/lldb/Symbol/CompilerType.h
+++ b/lldb/include/lldb/Symbol/CompilerType.h
@@ -112,9 +112,7 @@ class CompilerType {
 
   /// Tests.
   /// \{
-  explicit operator bool() const {
-return m_type_system.lock() && m_type;
-  }
+  explicit operator bool() const { return m_type_system.lock() && m_type; }
 
   bool IsValid() const { return (bool)*this; }
 
@@ -194,6 +192,54 @@ class CompilerType {
   bool IsTypedefType() const;
 
   bool IsVoidType() const;
+
+  bool IsSmartPtrType() const;
+
+  bool IsInteger() const;
+
+  bool IsFloat() const;
+
+  bool IsEnumerationType() const;
+
+  bool IsUnscopedEnumerationType() const;
+
+  bool IsIntegerOrUnscopedEnumerationType() const;
+
+  bool IsSigned() const;
+
+  bool IsNullPtrType() const;
+
+  bool IsBoolean() const;
+
+  bool IsEnumerationIntegerTypeSigned() const;
+
+  bool IsScalarOrUnscopedEnumerationType() const;
+
+  bool IsPromotableIntegerType() const;
+
+  bool IsPointerToVoid() const;
+
+  bool IsRecordType() const;
+
+  bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
+ bool carry_virtual = false) const;
+
+  bool IsContextuallyConvertibleToBool() const;
+
+  bool IsBasicType() const;
+
+  std::string TypeDescription();
+
+  bool CompareTypes(CompilerType rhs) const;
+
+  const char *GetTypeTag();
+
+  uint32_t GetNumberOfNonEmptyBaseClasses();
+
+  CompilerType GetTemplateArgumentType(uint32_t idx);
+
+  CompilerType GetSmartPtrPointeeType();
+
   /// \}
 
   /// Type Completion.
@@ -436,8 +482,8 @@ class CompilerType {
  ExecutionContextScope *exe_scope);
 
   /// Dump to stdout.
-  void DumpTypeDescription(lldb::DescriptionLevel level =
-   lldb::eDescriptionLevelFull) const;
+  void DumpTypeDescription(
+  lldb::DescriptionLevel level = lldb::eDescriptionLevelFull) const;
 
   /// Print a description of the type to a stream. The exact implementation
   /// varies, but the expectation is that eDescriptionLevelFull returns a
diff --git a/lldb/source/Symbol/CompilerType.cpp 
b/lldb/source/Symbol/CompilerType.cpp
index 78cc8dad94a9c..854d6cab01b50 100644
--- a/lldb/source/Symbol/CompilerType.cpp
+++ b/lldb/source/Symbol/CompilerType.cpp
@@ -54,7 +54,7 @@ bool CompilerType::IsArrayType(CompilerType 
*element_type_ptr, uint64_t *size,
   if (IsValid())
 if (auto type_system_sp = GetTypeSystem())
   return type_system_sp->IsArrayType(m_type, element_type_ptr, size,
-  is_incomplete);
+ is_incomplete);
 
   if (element_type_ptr)
 element_type_ptr->Clear();
@@ -157,7 +157,8 @@ bool CompilerType::IsBlockPointerType(
 CompilerType *function_pointer_type_ptr) const {
   if (IsValid())
 if (auto type_system_sp = GetTypeSystem())
-  return type_system_sp->IsBlockPointerType(m_type, 
function_pointer_type_ptr);
+  return type_system_sp->IsBlockPointerType(m_type,
+function_pointer_type_ptr);
   return false;
 }
 
@@ -249,7 +250,7 @@ bool CompilerType::IsPossibleDynamicType(CompilerType 
*dynamic_pointee_type,
   if (IsValid())
 if (auto type_system_sp = GetTypeSystem())
   return type_system_sp->IsPossibleDynamicType(m_type, 
dynamic_pointee_type,
-check_cplusplus, check_objc);
+   check_cplusplus, 
check_objc);
   return false;
 }
 
@@ -302,6 +303,256 @@ bool CompilerType::IsBeingDefined() const {
   return false;
 }
 
+bool CompilerType::IsSmartPtrType() const {
+  // These regular expressions cover shared, unique and weak pointers both from
+  // stdlibc++ and libc+++.
+
+  static llvm::Regex k_libcxx_std_unique_ptr_regex(
+  "^std::__[[:alnum:]]+::unique_ptr<.+>(( )?&)?$");
+  static llvm::Regex k_libcxx_std_shared_ptr_regex(
+  "^std::__[[:alnum:]]+::

[Lldb-commits] [lldb] [LLDB] Add more helper functions to CompilerType class (second try). (PR #73472)

2023-12-05 Thread via lldb-commits



@@ -194,6 +192,54 @@ class CompilerType {
   bool IsTypedefType() const;
 
   bool IsVoidType() const;
+
+  bool IsSmartPtrType() const;
+
+  bool IsInteger() const;
+
+  bool IsFloat() const;
+
+  bool IsEnumerationType() const;
+
+  bool IsUnscopedEnumerationType() const;
+
+  bool IsIntegerOrUnscopedEnumerationType() const;
+
+  bool IsSigned() const;
+
+  bool IsNullPtrType() const;
+
+  bool IsBoolean() const;
+
+  bool IsEnumerationIntegerTypeSigned() const;
+
+  bool IsScalarOrUnscopedEnumerationType() const;
+
+  bool IsPromotableIntegerType() const;
+
+  bool IsPointerToVoid() const;
+
+  bool IsRecordType() const;
+
+  bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
+ bool carry_virtual = false) const;
+
+  bool IsContextuallyConvertibleToBool() const;

cmtice wrote:

Really done. :-)

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

[Lldb-commits] [lldb] Add option to pass thread ID to thread select command (PR #73596)

2023-12-05 Thread Michael Christensen via lldb-commits


https://github.com/mdko updated https://github.com/llvm/llvm-project/pull/73596

>From 97a6e23c85457a14c91c5800fa03bb872e6f1fa6 Mon Sep 17 00:00:00 2001
From: Michael Christensen 
Date: Mon, 27 Nov 2023 12:49:24 -0800
Subject: [PATCH 1/6] Add option to pass thread ID to thread select command

---
 lldb/source/Commands/CommandObjectThread.cpp  | 59 +--
 lldb/source/Commands/Options.td   |  5 ++
 .../thread/select/TestThreadSelect.py | 23 +++-
 3 files changed, 78 insertions(+), 9 deletions(-)

diff --git a/lldb/source/Commands/CommandObjectThread.cpp 
b/lldb/source/Commands/CommandObjectThread.cpp
index a9f5a4f8a4fbd..9384df319cc22 100644
--- a/lldb/source/Commands/CommandObjectThread.cpp
+++ b/lldb/source/Commands/CommandObjectThread.cpp
@@ -1129,8 +1129,44 @@ class CommandObjectThreadUntil : public 
CommandObjectParsed {
 
 // CommandObjectThreadSelect
 
+#define LLDB_OPTIONS_thread_select
+#include "CommandOptions.inc"
+
 class CommandObjectThreadSelect : public CommandObjectParsed {
 public:
+  class CommandOptions : public Options {
+  public:
+CommandOptions() { OptionParsingStarting(nullptr); }
+
+~CommandOptions() override = default;
+
+void OptionParsingStarting(ExecutionContext *execution_context) override {
+  m_thread_id = false;
+}
+
+Status SetOptionValue(uint32_t option_idx, llvm::StringRef option_arg,
+  ExecutionContext *execution_context) override {
+  const int short_option = m_getopt_table[option_idx].val;
+  switch (short_option) {
+  case 't': {
+m_thread_id = true;
+break;
+  }
+
+  default:
+llvm_unreachable("Unimplemented option");
+  }
+
+  return {};
+}
+
+llvm::ArrayRef GetDefinitions() override {
+  return llvm::ArrayRef(g_thread_select_options);
+}
+
+bool m_thread_id;
+  };
+
   CommandObjectThreadSelect(CommandInterpreter &interpreter)
   : CommandObjectParsed(interpreter, "thread select",
 "Change the currently selected thread.", nullptr,
@@ -1165,6 +1201,8 @@ class CommandObjectThreadSelect : public 
CommandObjectParsed {
 nullptr);
   }
 
+  Options *GetOptions() override { return &m_options; }
+
 protected:
   void DoExecute(Args &command, CommandReturnObject &result) override {
 Process *process = m_exe_ctx.GetProcessPtr();
@@ -1173,22 +1211,29 @@ class CommandObjectThreadSelect : public 
CommandObjectParsed {
   return;
 } else if (command.GetArgumentCount() != 1) {
   result.AppendErrorWithFormat(
-  "'%s' takes exactly one thread index argument:\nUsage: %s\n",
-  m_cmd_name.c_str(), m_cmd_syntax.c_str());
+  "'%s' takes exactly one thread %s argument:\nUsage: %s\n",
+  m_cmd_name.c_str(), m_options.m_thread_id ? "ID" : "index",
+  m_cmd_syntax.c_str());
   return;
 }
 
 uint32_t index_id;
 if (!llvm::to_integer(command.GetArgumentAtIndex(0), index_id)) {
-  result.AppendErrorWithFormat("Invalid thread index '%s'",
+  result.AppendErrorWithFormat("Invalid thread %s '%s'",
+   m_options.m_thread_id ? "ID" : "index",
command.GetArgumentAtIndex(0));
   return;
 }
 
-Thread *new_thread =
-process->GetThreadList().FindThreadByIndexID(index_id).get();
+Thread *new_thread = nullptr;
+if (m_options.m_thread_id) {
+new_thread = process->GetThreadList().FindThreadByID(index_id).get();
+} else {
+new_thread = 
process->GetThreadList().FindThreadByIndexID(index_id).get();
+}
 if (new_thread == nullptr) {
-  result.AppendErrorWithFormat("invalid thread #%s.\n",
+  result.AppendErrorWithFormat("invalid thread %s%s.\n",
+   m_options.m_thread_id ? "ID " : "#",
command.GetArgumentAtIndex(0));
   return;
 }
@@ -1196,6 +1241,8 @@ class CommandObjectThreadSelect : public 
CommandObjectParsed {
 process->GetThreadList().SetSelectedThreadByID(new_thread->GetID(), true);
 result.SetStatus(eReturnStatusSuccessFinishNoResult);
   }
+
+  CommandOptions m_options;
 };
 
 // CommandObjectThreadList
diff --git a/lldb/source/Commands/Options.td b/lldb/source/Commands/Options.td
index 542c78be5a12d..23886046df8f6 100644
--- a/lldb/source/Commands/Options.td
+++ b/lldb/source/Commands/Options.td
@@ -1117,6 +1117,11 @@ let Command = "thread plan list" in {
 Desc<"Display thread plans for unreported threads">;
 }
 
+let Command = "thread select" in {
+  def thread_thread_id : Option<"thread_id", "t">,
+Desc<"Provide a thread ID instead of a thread index.">;
+}
+
 let Command = "thread trace dump function calls" in {
   def thread_trace_dump_function_calls_file : Option<"file", "F">, Group<1>,
 Arg<"Filename">,
diff --git a/lldb/test/API/commands/thread/select/TestThreadSelect.py 
b/lldb/test/API/comman

[Lldb-commits] [lldb] [LLDB] Add more helper functions to CompilerType class (second try). (PR #73472)

2023-12-05 Thread via lldb-commits


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

[Lldb-commits] [lldb] Add option to pass thread ID to thread select command (PR #73596)

2023-12-05 Thread Michael Christensen via lldb-commits


mdko wrote:

Latest change:
* Reverts `eCustomCompletion` to original value
* Moves `eThreadIDCompletion` after `eCustomCompletion`
* Adds `eTerminatorCompletion` as last value in enum
* Sets all values to 64 bit to future-proof it

https://github.com/llvm/llvm-project/pull/73596
___
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 CompilerType class (second try). (PR #73472)

2023-12-05 Thread via lldb-commits



@@ -194,6 +192,54 @@ class CompilerType {
   bool IsTypedefType() const;
 
   bool IsVoidType() const;
+
+  bool IsSmartPtrType() const;
+
+  bool IsInteger() const;
+
+  bool IsFloat() const;
+
+  bool IsEnumerationType() const;
+
+  bool IsUnscopedEnumerationType() const;
+
+  bool IsIntegerOrUnscopedEnumerationType() const;
+
+  bool IsSigned() const;
+
+  bool IsNullPtrType() const;
+
+  bool IsBoolean() const;
+
+  bool IsEnumerationIntegerTypeSigned() const;
+
+  bool IsScalarOrUnscopedEnumerationType() const;
+
+  bool IsPromotableIntegerType() const;
+
+  bool IsPointerToVoid() const;
+
+  bool IsRecordType() const;
+
+  bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
+ bool carry_virtual = false) const;
+
+  bool IsContextuallyConvertibleToBool() const;
+
+  bool IsBasicType() const;
+
+  std::string TypeDescription();
+
+  bool CompareTypes(CompilerType rhs) const;
+
+  const char *GetTypeTag();
+
+  uint32_t GetNumberOfNonEmptyBaseClasses();
+
+  CompilerType GetTemplateArgumentType(uint32_t idx);
+
+  CompilerType GetSmartPtrPointeeType();

cmtice wrote:

I looked at the functions in LibcxxSharedPtrSyntheticFrontend 
(iPlugins/Language/CPlusPlus) -- I assume this is what you were referring to.  
None of the functions there do exactly what this function does, so I can't use 
one of them instead.  The only place I saw there that might be able to use this 
function was in GetChildAtIndex... I could replace 
'valobj_sp->GetCompilerType().GetTypeTemplateArgument(0).GetPointerType()' with 
'valobj_sp->GetCompilerType().GetSmartPtrPointeeType()', but it looks like the 
current call would return something like "* FooType", whereas my call would 
return "FooType", so they're not quite the same, either.

So I don't see how to do what you're asking. 

https://github.com/llvm/llvm-project/pull/73472
___
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 CompilerType class (second try). (PR #73472)

2023-12-05 Thread via lldb-commits


cmtice wrote:

I believe i have addressed all the review comments. Please let me know if 
there's anything else I need to do and/or (hopefully) approve this so I can 
merge it. 

Thanks!

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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread David Spickett via lldb-commits

=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 



@@ -70,6 +72,31 @@ size_t Stream::PutCString(llvm::StringRef str) {
   return bytes_written;
 }
 
+void Stream::PutCStringColorHighlighted(llvm::StringRef text,
+const char *pattern) {
+  if (!pattern) {
+PutCString(text);
+return;
+  }
+
+  // If pattern is not nullptr, we should use color
+  llvm::Regex reg_pattern(pattern);
+  llvm::SmallVector matches;
+  llvm::StringRef remaining = text;
+  std::string format_str = lldb_private::ansi::FormatAnsiTerminalCodes(
+  "${ansi.fg.red}%.*s${ansi.normal}");

DavidSpickett wrote:

I think it's either find another way to get to the settings, or assume no 
colour if the target isn't present.

Jonas may know a way to do it.

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

[Lldb-commits] [openmp] [lld] [clang-tools-extra] [clang] [libcxx] [flang] [mlir] [libunwind] [compiler-rt] [lldb] [llvm] [libcxxabi] [libc] [C23] Implement N3018: The constexpr specifier for object d

2023-12-05 Thread via lldb-commits



@@ -14270,6 +14318,113 @@ StmtResult Sema::ActOnCXXForRangeIdentifier(Scope *S, 
SourceLocation IdentLoc,
   : IdentLoc);
 }
 
+static ImplicitConversionKind GetConversionKind(QualType FromType,
+QualType ToType) {
+  if (ToType->isIntegerType()) {
+if (FromType->isComplexType())
+  return ICK_Complex_Real;
+if (FromType->isFloatingType())
+  return ICK_Floating_Integral;
+if (FromType->isIntegerType())
+  return ICK_Integral_Conversion;
+  }
+
+  if (ToType->isFloatingType()) {
+if (FromType->isComplexType())
+  return ICK_Complex_Real;
+if (FromType->isFloatingType())
+  return ICK_Floating_Conversion;
+if (FromType->isIntegerType())
+  return ICK_Floating_Integral;
+  }
+
+  return ICK_Identity;
+}
+
+static bool CheckC23ConstexprInitConversion(Sema &S, const Expr *Init) {
+  assert(S.getLangOpts().C23);
+  const Expr *InitNoCast = Init->IgnoreParenImpCasts();
+  StandardConversionSequence SCS;
+  SCS.setAsIdentityConversion();
+  auto FromType = InitNoCast->getType();
+  auto ToType = Init->getType();
+  SCS.setToType(0, FromType);
+  SCS.setToType(1, ToType);
+  SCS.Second = GetConversionKind(FromType, ToType);
+
+  APValue Value;
+  QualType PreNarrowingType;
+  // Reuse C++ narrowing check.
+  switch (SCS.getNarrowingKind(S.Context, Init, Value, PreNarrowingType,
+   /*IgnoreFloatToIntegralConversion*/ false)) {
+  // The value doesn't fit.
+  case NK_Constant_Narrowing:
+S.Diag(Init->getBeginLoc(), diag::err_c23_constexpr_init_not_representable)
+<< Value.getAsString(S.Context, PreNarrowingType) << ToType;
+return true;
+
+  // Conversion to a narrower type.
+  case NK_Type_Narrowing:
+S.Diag(Init->getBeginLoc(), diag::err_c23_constexpr_init_type_mismatch)
+<< ToType << FromType;
+return true;
+
+  // Since we only reuse narrowing check for C23 constexpr variables here, 
we're
+  // not really interested in these cases.
+  case NK_Dependent_Narrowing:
+  case NK_Variable_Narrowing:
+  case NK_Not_Narrowing:
+return false;
+  }
+  llvm_unreachable("unhandled case in switch");
+}
+
+static bool CheckC23ConstexprInitStringLiteral(const StringLiteral *SE,
+   Sema &SemaRef,
+   SourceLocation Loc) {
+  assert(SemaRef.getLangOpts().C23);
+  // String literals have the target type attached but underneath may contain
+  // values that don't really fit into the target type. Check that every
+  // character fits.
+  const ConstantArrayType *CAT =
+  SemaRef.Context.getAsConstantArrayType(SE->getType());
+  QualType CharType = CAT->getElementType();
+  uint32_t BitWidth = SemaRef.Context.getTypeSize(CharType);
+  bool isUnsigned = CharType->isUnsignedIntegerType();
+  llvm::APSInt Value(BitWidth, isUnsigned);
+  for (unsigned I = 0, N = SE->getLength(); I != N; ++I) {
+int64_t C = SE->getCodeUnitS(I, SemaRef.Context.getCharWidth());
+Value = C;
+if (Value != C) {
+  SemaRef.Diag(Loc, diag::err_c23_constexpr_init_not_representable)

cor3ntin wrote:

Maybe we can use `getLocationOfByte` instead of `Loc` here, if it's easy (I'm 
not insisting)

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

[Lldb-commits] [clang] [compiler-rt] [flang] [libcxxabi] [lldb] [clang-tools-extra] [libcxx] [llvm] [libc] [lld] [libunwind] [openmp] [mlir] [C23] Implement N3018: The constexpr specifier for object d

2023-12-05 Thread via lldb-commits



@@ -1914,6 +1914,17 @@ class StringLiteral final
 llvm_unreachable("Unsupported character width!");
   }
 
+  // Get code unit but preserve sign info.
+  int64_t getCodeUnitS(size_t I, uint64_t ByteWidth) const {

cor3ntin wrote:

```suggestion
  int64_t getCodeUnitS(size_t I, uint64_t BitWidth) const {
```
ByteWidth is actually a number of bits, right?


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

[Lldb-commits] [compiler-rt] [clang-tools-extra] [clang] [llvm] [libc] [libcxx] [libunwind] [lldb] [openmp] [flang] [lld] [libcxxabi] [mlir] [C23] Implement N3018: The constexpr specifier for object d

2023-12-05 Thread via lldb-commits


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

[Lldb-commits] [compiler-rt] [libunwind] [llvm] [libc] [lldb] [clang] [flang] [clang-tools-extra] [lld] [libcxxabi] [openmp] [libcxx] [mlir] [C23] Implement N3018: The constexpr specifier for object d

2023-12-05 Thread via lldb-commits


https://github.com/cor3ntin commented:

Modulo comment I'm happy with the StringLiteral aspect of the patch and 
generally the rest of the patch looks good to me, but I'm not familiar enough 
with the peculiarities of C to provide an in-depth review

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

[Lldb-commits] [lld] [mlir] [llvm] [openmp] [libcxxabi] [libunwind] [lldb] [libcxx] [clang] [compiler-rt] [flang] [libc] [clang-tools-extra] [C23] Implement N3018: The constexpr specifier for object d

2023-12-05 Thread via lldb-commits



@@ -13816,7 +13862,9 @@ void Sema::AddInitializerToDecl(Decl *RealDecl, Expr 
*Init, bool DirectInit) {
   VDecl->setStorageClass(SC_Extern);
 
 // C99 6.7.8p4. All file scoped initializers need to be constant.
-if (!getLangOpts().CPlusPlus && !VDecl->isInvalidDecl())
+// Avoid double diagnosing for constexpr variables.

cor3ntin wrote:

```suggestion
// Avoid double diagnoses for constexpr variables.
```

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

[Lldb-commits] [lldb] [lldb] Correctly check and report error states in StackFrame.cpp (PR #74414)

2023-12-05 Thread Felipe de Azevedo Piovezan via lldb-commits


felipepiovezan wrote:

It is wild that all of these have gone unnoticed for such a long time. I guess 
it makes sense, as these are more of sanity checks that we never expect to fire?

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

[Lldb-commits] [lldb] [libc] [compiler-rt] [llvm] [flang] [libcxx] [lld] [clang] [clang-tools-extra] [Clang] Fix linker error for function multiversioning (PR #71706)

2023-12-05 Thread via lldb-commits


https://github.com/elizabethandrews updated 
https://github.com/llvm/llvm-project/pull/71706

>From 534fad70af45a6a22ba2d03f474089e896f4fcd6 Mon Sep 17 00:00:00 2001
From: Elizabeth Andrews 
Date: Thu, 26 Oct 2023 08:53:54 -0700
Subject: [PATCH 1/4] [Clang]  Fix linker error for function multiversioning
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Currently target_clones attribute results in a linker error when
there are no multi-versioned function declarations in the calling TU.

In the calling TU, the call is generated with the ‘normal’ assembly name.
This does not match any of the versions or the ifunc, since version mangling
includes a .versionstring, and the ifunc includes .ifunc suffix. The linker
error is not seen with GCC since the mangling for the ifunc symbol in GCC
is the ‘normal’ assembly name for function i.e. no ifunc suffix.

This PR removes the .ifunc suffix to match GCC. It also adds alias with
the .ifunc suffix so as to ensure backward compatibility.

The changes exclude aarch64 target because the mangling for default
versions on aarch64 does not include a .default suffix and is the
'normal' assembly name, unlike other targets. It is not clear to me
what the correct behavior for this target is.
---
 clang/docs/ReleaseNotes.rst  |  1 +
 clang/lib/CodeGen/CodeGenModule.cpp  | 35 +---
 clang/test/CodeGen/attr-target-clones.c  | 33 +++---
 clang/test/CodeGenCXX/attr-target-clones.cpp | 27 +--
 4 files changed, 70 insertions(+), 26 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 8bac599f88503..9e73fa03a0355 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -550,6 +550,7 @@ Bug Fixes in This Version
   Fixes (`#67687 `_)
 - Fix crash from constexpr evaluator evaluating uninitialized arrays as rvalue.
   Fixes (`#67317 `_)
+- Fix linker error when using multiversioned function defined in a different 
TU.
 
 Bug Fixes to Compiler Builtins
 ^^
diff --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 2e96fff808113..b54c4296a0f9d 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -4098,8 +4098,26 @@ void CodeGenModule::emitMultiVersionFunctions() {
 }
 
 llvm::Constant *ResolverConstant = GetOrCreateMultiVersionResolver(GD);
-if (auto *IFunc = dyn_cast(ResolverConstant))
+if (auto *IFunc = dyn_cast(ResolverConstant)) {
   ResolverConstant = IFunc->getResolver();
+  // In Aarch64, default versions of multiversioned functions are mangled 
to
+  // their 'normal' assembly name. This deviates from other targets which
+  // append a '.default' string. As a result we need to continue appending
+  // .ifunc in Aarch64.
+  // FIXME: Should Aarch64 mangling for 'default' multiversion function and
+  // in turn ifunc function match that of other targets?
+  if (FD->isTargetClonesMultiVersion() &&
+  !getTarget().getTriple().isAArch64()) {
+const CGFunctionInfo &FI = getTypes().arrangeGlobalDeclaration(GD);
+llvm::FunctionType *DeclTy = getTypes().GetFunctionType(FI);
+std::string MangledName = getMangledNameImpl(
+*this, GD, FD, /*OmitMultiVersionMangling=*/true);
+auto *Alias = llvm::GlobalAlias::create(
+DeclTy, 0, llvm::Function::WeakODRLinkage, MangledName + ".ifunc",
+IFunc, &getModule());
+SetCommonAttributes(FD, Alias);
+  }
+}
 llvm::Function *ResolverFunc = cast(ResolverConstant);
 
 ResolverFunc->setLinkage(getMultiversionLinkage(*this, GD));
@@ -4266,10 +4284,19 @@ llvm::Constant 
*CodeGenModule::GetOrCreateMultiVersionResolver(GlobalDecl GD) {
   // Holds the name of the resolver, in ifunc mode this is the ifunc (which has
   // a separate resolver).
   std::string ResolverName = MangledName;
-  if (getTarget().supportsIFunc())
-ResolverName += ".ifunc";
-  else if (FD->isTargetMultiVersion())
+  if (getTarget().supportsIFunc()) {
+// In Aarch64, default versions of multiversioned functions are mangled to
+// their 'normal' assembly name. This deviates from other targets which
+// append a '.default' string. As a result we need to continue appending
+// .ifunc in Aarch64.
+// FIXME: Should Aarch64 mangling for 'default' multiversion function and
+// in turn ifunc function match that of other targets?
+if (!FD->isTargetClonesMultiVersion() ||
+getTarget().getTriple().isAArch64())
+  ResolverName += ".ifunc";
+  } else if (FD->isTargetMultiVersion()) {
 ResolverName += ".resolver";
+  }
 
   // If the resolver has already been created, just return it.
   if (llvm::GlobalValue *ResolverGV = GetGlobalValue(ResolverName))

[Lldb-commits] [lldb] [lldb] Return index of element in ValueObject path instead of the element's value (PR #74413)

2023-12-05 Thread Chelsea Cassanova via lldb-commits



@@ -398,13 +398,16 @@ ValueObject::GetChildAtIndexPath(llvm::ArrayRef 
idxs,
   if (idxs.size() == 0)
 return GetSP();
   ValueObjectSP root(GetSP());
+
+  size_t current_index = 0;
   for (size_t idx : idxs) {
 root = root->GetChildAtIndex(idx);
 if (!root) {
   if (index_of_error)
-*index_of_error = idx;
+*index_of_error = current_index;
   return root;
 }
+current_index += 1;

chelcassanova wrote:

This is the tiniest nit on earth but `current_index++` here to increment this?

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

[Lldb-commits] [lldb] [lldb] Return index of element in ValueObject path instead of the element's value (PR #74413)

2023-12-05 Thread Felipe de Azevedo Piovezan via lldb-commits


felipepiovezan wrote:

Should we change the documentation of these functions?

https://github.com/llvm/llvm-project/pull/74413
___
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 CompilerType class (second try). (PR #73472)

2023-12-05 Thread Adrian Prantl via lldb-commits



@@ -194,6 +192,54 @@ class CompilerType {
   bool IsTypedefType() const;
 
   bool IsVoidType() const;
+
+  bool IsSmartPtrType() const;
+
+  bool IsInteger() const;
+
+  bool IsFloat() const;
+
+  bool IsEnumerationType() const;
+
+  bool IsUnscopedEnumerationType() const;
+
+  bool IsIntegerOrUnscopedEnumerationType() const;
+
+  bool IsSigned() const;
+
+  bool IsNullPtrType() const;
+
+  bool IsBoolean() const;
+
+  bool IsEnumerationIntegerTypeSigned() const;
+
+  bool IsScalarOrUnscopedEnumerationType() const;
+
+  bool IsPromotableIntegerType() const;
+
+  bool IsPointerToVoid() const;
+
+  bool IsRecordType() const;
+
+  bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
+ bool carry_virtual = false) const;
+
+  bool IsContextuallyConvertibleToBool() const;
+
+  bool IsBasicType() const;
+
+  std::string TypeDescription();
+
+  bool CompareTypes(CompilerType rhs) const;
+
+  const char *GetTypeTag();
+
+  uint32_t GetNumberOfNonEmptyBaseClasses();
+
+  CompilerType GetTemplateArgumentType(uint32_t idx);
+
+  CompilerType GetSmartPtrPointeeType();

adrian-prantl wrote:

Here you are adding a function that takes a CompilerType holding an STL  smart 
pointer and ask for the pointee type. We also have synthetic child formatters 
used by `frame variable` that allow evaluating `*my_shared_ptr`. From that I 
was assuming that there must be some overlap between what the dataformatter 
provides and what this function does.
What I don't know is whether synthetic children provided by a formatter are a 
good fit for what you are trying to do, but maybe the inverse is true, and the 
existing data formatter should be implemented in terms of this new 
GetSmartPtrPointeeType() API.
I just want to make sure we're not introducing two places in LLDB that have to 
know about STL smart pointers while covering slightly different functionality.

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

[Lldb-commits] [libcxx] [lld] [clang] [flang] [clang-tools-extra] [llvm] [libc] [compiler-rt] [mlir] [openmp] [lldb] [MLIR] Enable GPU Dialect to SYCL runtime integration (PR #71430)

2023-12-05 Thread Sang Ik Lee via lldb-commits


silee2 wrote:

@fabianmcg Can you approve and merge? @joker-eph is not responding and this PR 
has been open for a long time.
It is blocking other future PRs that depend on this one.
If SPIR-V dialect registration needs to change that can be done in another PR.

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

[Lldb-commits] [lldb] [lldb] Correctly check and report error states in StackFrame.cpp (PR #74414)

2023-12-05 Thread Adrian Prantl via lldb-commits


adrian-prantl wrote:

> Is testing this possible?

If this weren't inside of StackFrame we could write a reliable test based on 
LLVM IR, but it might be difficult to reliably produce debug info with 
optimized out variables from source code on all platforms. If you have any 
suggestions, let me know!

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

[Lldb-commits] [lldb] Add option to pass thread ID to thread select command (PR #73596)

2023-12-05 Thread via lldb-commits


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

[Lldb-commits] [lldb] Add option to pass thread ID to thread select command (PR #73596)

2023-12-05 Thread via lldb-commits


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

Looks fine, except you need to fix the eTerminatorCompletion value.

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

[Lldb-commits] [lldb] Add option to pass thread ID to thread select command (PR #73596)

2023-12-05 Thread via lldb-commits



@@ -1270,36 +1270,37 @@ enum WatchpointValueKind {
 };
 
 enum CompletionType {
-  eNoCompletion = 0u,
-  eSourceFileCompletion = (1u << 0),
-  eDiskFileCompletion = (1u << 1),
-  eDiskDirectoryCompletion = (1u << 2),
-  eSymbolCompletion = (1u << 3),
-  eModuleCompletion = (1u << 4),
-  eSettingsNameCompletion = (1u << 5),
-  ePlatformPluginCompletion = (1u << 6),
-  eArchitectureCompletion = (1u << 7),
-  eVariablePathCompletion = (1u << 8),
-  eRegisterCompletion = (1u << 9),
-  eBreakpointCompletion = (1u << 10),
-  eProcessPluginCompletion = (1u << 11),
-  eDisassemblyFlavorCompletion = (1u << 12),
-  eTypeLanguageCompletion = (1u << 13),
-  eFrameIndexCompletion = (1u << 14),
-  eModuleUUIDCompletion = (1u << 15),
-  eStopHookIDCompletion = (1u << 16),
-  eThreadIndexCompletion = (1u << 17),
-  eWatchpointIDCompletion = (1u << 18),
-  eBreakpointNameCompletion = (1u << 19),
-  eProcessIDCompletion = (1u << 20),
-  eProcessNameCompletion = (1u << 21),
-  eRemoteDiskFileCompletion = (1u << 22),
-  eRemoteDiskDirectoryCompletion = (1u << 23),
-  eTypeCategoryNameCompletion = (1u << 24),
-  // This item serves two purposes.  It is the last element in the enum, so
-  // you can add custom enums starting from here in your Option class. Also
-  // if you & in this bit the base code will not process the option.
-  eCustomCompletion = (1u << 25)
+  eNoCompletion = 0ul,
+  eSourceFileCompletion = (1ul << 0),
+  eDiskFileCompletion = (1ul << 1),
+  eDiskDirectoryCompletion = (1ul << 2),
+  eSymbolCompletion = (1ul << 3),
+  eModuleCompletion = (1ul << 4),
+  eSettingsNameCompletion = (1ul << 5),
+  ePlatformPluginCompletion = (1ul << 6),
+  eArchitectureCompletion = (1ul << 7),
+  eVariablePathCompletion = (1ul << 8),
+  eRegisterCompletion = (1ul << 9),
+  eBreakpointCompletion = (1ul << 10),
+  eProcessPluginCompletion = (1ul << 11),
+  eDisassemblyFlavorCompletion = (1ul << 12),
+  eTypeLanguageCompletion = (1ul << 13),
+  eFrameIndexCompletion = (1ul << 14),
+  eModuleUUIDCompletion = (1ul << 15),
+  eStopHookIDCompletion = (1ul << 16),
+  eThreadIndexCompletion = (1ul << 17),
+  eWatchpointIDCompletion = (1ul << 18),
+  eBreakpointNameCompletion = (1ul << 19),
+  eProcessIDCompletion = (1ul << 20),
+  eProcessNameCompletion = (1ul << 21),
+  eRemoteDiskFileCompletion = (1ul << 22),
+  eRemoteDiskDirectoryCompletion = (1ul << 23),
+  eTypeCategoryNameCompletion = (1ul << 24),
+  eCustomCompletion = (1ul << 25),
+  eThreadIDCompletion = (1ul << 26),
+  // This last enum element is just for input validation.
+  // Add new completions before this element.
+  eTerminatorCompletion = (1ul << 63)

jimingham wrote:

This isn't right, eTerminatorCompletion should be `(1ul << 27)` here.  I want 
to be able to write:

if (number_passed_in >= eTerminatorCompletion)
error("You passed an invalid completion")

The value of eTerminatorCompletion gets shifted up each time someone adds a new 
completion, that allows each lldb version to check the input value against the 
completions it knows.

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

[Lldb-commits] [lldb] Add option to pass thread ID to thread select command (PR #73596)

2023-12-05 Thread Michael Christensen via lldb-commits


https://github.com/mdko updated https://github.com/llvm/llvm-project/pull/73596

>From 97a6e23c85457a14c91c5800fa03bb872e6f1fa6 Mon Sep 17 00:00:00 2001
From: Michael Christensen 
Date: Mon, 27 Nov 2023 12:49:24 -0800
Subject: [PATCH 1/7] Add option to pass thread ID to thread select command

---
 lldb/source/Commands/CommandObjectThread.cpp  | 59 +--
 lldb/source/Commands/Options.td   |  5 ++
 .../thread/select/TestThreadSelect.py | 23 +++-
 3 files changed, 78 insertions(+), 9 deletions(-)

diff --git a/lldb/source/Commands/CommandObjectThread.cpp 
b/lldb/source/Commands/CommandObjectThread.cpp
index a9f5a4f8a4fbd..9384df319cc22 100644
--- a/lldb/source/Commands/CommandObjectThread.cpp
+++ b/lldb/source/Commands/CommandObjectThread.cpp
@@ -1129,8 +1129,44 @@ class CommandObjectThreadUntil : public 
CommandObjectParsed {
 
 // CommandObjectThreadSelect
 
+#define LLDB_OPTIONS_thread_select
+#include "CommandOptions.inc"
+
 class CommandObjectThreadSelect : public CommandObjectParsed {
 public:
+  class CommandOptions : public Options {
+  public:
+CommandOptions() { OptionParsingStarting(nullptr); }
+
+~CommandOptions() override = default;
+
+void OptionParsingStarting(ExecutionContext *execution_context) override {
+  m_thread_id = false;
+}
+
+Status SetOptionValue(uint32_t option_idx, llvm::StringRef option_arg,
+  ExecutionContext *execution_context) override {
+  const int short_option = m_getopt_table[option_idx].val;
+  switch (short_option) {
+  case 't': {
+m_thread_id = true;
+break;
+  }
+
+  default:
+llvm_unreachable("Unimplemented option");
+  }
+
+  return {};
+}
+
+llvm::ArrayRef GetDefinitions() override {
+  return llvm::ArrayRef(g_thread_select_options);
+}
+
+bool m_thread_id;
+  };
+
   CommandObjectThreadSelect(CommandInterpreter &interpreter)
   : CommandObjectParsed(interpreter, "thread select",
 "Change the currently selected thread.", nullptr,
@@ -1165,6 +1201,8 @@ class CommandObjectThreadSelect : public 
CommandObjectParsed {
 nullptr);
   }
 
+  Options *GetOptions() override { return &m_options; }
+
 protected:
   void DoExecute(Args &command, CommandReturnObject &result) override {
 Process *process = m_exe_ctx.GetProcessPtr();
@@ -1173,22 +1211,29 @@ class CommandObjectThreadSelect : public 
CommandObjectParsed {
   return;
 } else if (command.GetArgumentCount() != 1) {
   result.AppendErrorWithFormat(
-  "'%s' takes exactly one thread index argument:\nUsage: %s\n",
-  m_cmd_name.c_str(), m_cmd_syntax.c_str());
+  "'%s' takes exactly one thread %s argument:\nUsage: %s\n",
+  m_cmd_name.c_str(), m_options.m_thread_id ? "ID" : "index",
+  m_cmd_syntax.c_str());
   return;
 }
 
 uint32_t index_id;
 if (!llvm::to_integer(command.GetArgumentAtIndex(0), index_id)) {
-  result.AppendErrorWithFormat("Invalid thread index '%s'",
+  result.AppendErrorWithFormat("Invalid thread %s '%s'",
+   m_options.m_thread_id ? "ID" : "index",
command.GetArgumentAtIndex(0));
   return;
 }
 
-Thread *new_thread =
-process->GetThreadList().FindThreadByIndexID(index_id).get();
+Thread *new_thread = nullptr;
+if (m_options.m_thread_id) {
+new_thread = process->GetThreadList().FindThreadByID(index_id).get();
+} else {
+new_thread = 
process->GetThreadList().FindThreadByIndexID(index_id).get();
+}
 if (new_thread == nullptr) {
-  result.AppendErrorWithFormat("invalid thread #%s.\n",
+  result.AppendErrorWithFormat("invalid thread %s%s.\n",
+   m_options.m_thread_id ? "ID " : "#",
command.GetArgumentAtIndex(0));
   return;
 }
@@ -1196,6 +1241,8 @@ class CommandObjectThreadSelect : public 
CommandObjectParsed {
 process->GetThreadList().SetSelectedThreadByID(new_thread->GetID(), true);
 result.SetStatus(eReturnStatusSuccessFinishNoResult);
   }
+
+  CommandOptions m_options;
 };
 
 // CommandObjectThreadList
diff --git a/lldb/source/Commands/Options.td b/lldb/source/Commands/Options.td
index 542c78be5a12d..23886046df8f6 100644
--- a/lldb/source/Commands/Options.td
+++ b/lldb/source/Commands/Options.td
@@ -1117,6 +1117,11 @@ let Command = "thread plan list" in {
 Desc<"Display thread plans for unreported threads">;
 }
 
+let Command = "thread select" in {
+  def thread_thread_id : Option<"thread_id", "t">,
+Desc<"Provide a thread ID instead of a thread index.">;
+}
+
 let Command = "thread trace dump function calls" in {
   def thread_trace_dump_function_calls_file : Option<"file", "F">, Group<1>,
 Arg<"Filename">,
diff --git a/lldb/test/API/commands/thread/select/TestThreadSelect.py 
b/lldb/test/API/comman

[Lldb-commits] [lldb] Add option to pass thread ID to thread select command (PR #73596)

2023-12-05 Thread Michael Christensen via lldb-commits



@@ -1270,36 +1270,37 @@ enum WatchpointValueKind {
 };
 
 enum CompletionType {
-  eNoCompletion = 0u,
-  eSourceFileCompletion = (1u << 0),
-  eDiskFileCompletion = (1u << 1),
-  eDiskDirectoryCompletion = (1u << 2),
-  eSymbolCompletion = (1u << 3),
-  eModuleCompletion = (1u << 4),
-  eSettingsNameCompletion = (1u << 5),
-  ePlatformPluginCompletion = (1u << 6),
-  eArchitectureCompletion = (1u << 7),
-  eVariablePathCompletion = (1u << 8),
-  eRegisterCompletion = (1u << 9),
-  eBreakpointCompletion = (1u << 10),
-  eProcessPluginCompletion = (1u << 11),
-  eDisassemblyFlavorCompletion = (1u << 12),
-  eTypeLanguageCompletion = (1u << 13),
-  eFrameIndexCompletion = (1u << 14),
-  eModuleUUIDCompletion = (1u << 15),
-  eStopHookIDCompletion = (1u << 16),
-  eThreadIndexCompletion = (1u << 17),
-  eWatchpointIDCompletion = (1u << 18),
-  eBreakpointNameCompletion = (1u << 19),
-  eProcessIDCompletion = (1u << 20),
-  eProcessNameCompletion = (1u << 21),
-  eRemoteDiskFileCompletion = (1u << 22),
-  eRemoteDiskDirectoryCompletion = (1u << 23),
-  eTypeCategoryNameCompletion = (1u << 24),
-  // This item serves two purposes.  It is the last element in the enum, so
-  // you can add custom enums starting from here in your Option class. Also
-  // if you & in this bit the base code will not process the option.
-  eCustomCompletion = (1u << 25)
+  eNoCompletion = 0ul,
+  eSourceFileCompletion = (1ul << 0),
+  eDiskFileCompletion = (1ul << 1),
+  eDiskDirectoryCompletion = (1ul << 2),
+  eSymbolCompletion = (1ul << 3),
+  eModuleCompletion = (1ul << 4),
+  eSettingsNameCompletion = (1ul << 5),
+  ePlatformPluginCompletion = (1ul << 6),
+  eArchitectureCompletion = (1ul << 7),
+  eVariablePathCompletion = (1ul << 8),
+  eRegisterCompletion = (1ul << 9),
+  eBreakpointCompletion = (1ul << 10),
+  eProcessPluginCompletion = (1ul << 11),
+  eDisassemblyFlavorCompletion = (1ul << 12),
+  eTypeLanguageCompletion = (1ul << 13),
+  eFrameIndexCompletion = (1ul << 14),
+  eModuleUUIDCompletion = (1ul << 15),
+  eStopHookIDCompletion = (1ul << 16),
+  eThreadIndexCompletion = (1ul << 17),
+  eWatchpointIDCompletion = (1ul << 18),
+  eBreakpointNameCompletion = (1ul << 19),
+  eProcessIDCompletion = (1ul << 20),
+  eProcessNameCompletion = (1ul << 21),
+  eRemoteDiskFileCompletion = (1ul << 22),
+  eRemoteDiskDirectoryCompletion = (1ul << 23),
+  eTypeCategoryNameCompletion = (1ul << 24),
+  eCustomCompletion = (1ul << 25),
+  eThreadIDCompletion = (1ul << 26),
+  // This last enum element is just for input validation.
+  // Add new completions before this element.
+  eTerminatorCompletion = (1ul << 63)

mdko wrote:

@jimingham Thanks for the quick feedback, makes sense. Latest changes update 
`eTerminatorCompletion` value based on your comments.

https://github.com/llvm/llvm-project/pull/73596
___
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 CompilerType class (second try). (PR #73472)

2023-12-05 Thread via lldb-commits



@@ -194,6 +192,54 @@ class CompilerType {
   bool IsTypedefType() const;
 
   bool IsVoidType() const;
+
+  bool IsSmartPtrType() const;
+
+  bool IsInteger() const;
+
+  bool IsFloat() const;
+
+  bool IsEnumerationType() const;
+
+  bool IsUnscopedEnumerationType() const;
+
+  bool IsIntegerOrUnscopedEnumerationType() const;
+
+  bool IsSigned() const;
+
+  bool IsNullPtrType() const;
+
+  bool IsBoolean() const;
+
+  bool IsEnumerationIntegerTypeSigned() const;
+
+  bool IsScalarOrUnscopedEnumerationType() const;
+
+  bool IsPromotableIntegerType() const;
+
+  bool IsPointerToVoid() const;
+
+  bool IsRecordType() const;
+
+  bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
+ bool carry_virtual = false) const;
+
+  bool IsContextuallyConvertibleToBool() const;
+
+  bool IsBasicType() const;
+
+  std::string TypeDescription();
+
+  bool CompareTypes(CompilerType rhs) const;
+
+  const char *GetTypeTag();
+
+  uint32_t GetNumberOfNonEmptyBaseClasses();
+
+  CompilerType GetTemplateArgumentType(uint32_t idx);
+
+  CompilerType GetSmartPtrPointeeType();

jimingham wrote:

Note that this function returns the type of the shared pointer, whereas the 
synthetic child providers return values of that type.  So if anything you would 
implement the formatter on top of this type recognition (though that only gets 
you a little way there, you also have to find where the value is in the smart 
pointer.)

It's a little awkward that these API's speak of "smart pointer" when they 
really mean "the system library provided memory managing smart pointer".  But I 
can't think of a good name to make this explicit.

However, that brings us round to the synthetic child support for "smart 
pointers".  That is a feature that's not limited to the standard library's 
notion of a smart pointer.  It really just tells lldb how to interpret the `->` 
in:

(lldb) frame var foo->bar

The implementation of this feature doesn't require any knowledge of what the 
arrow operator for foo does (it is not even required to have one).  For 
instance, you could use it to have lldb log uses of the `->` operator for this 
type in the expression parser, or whatever.  The only requirement is that you 
define a synthetic child provider that emulates the -> operator, returning a 
ValueObject from the appropriate API in the provider.

So at some point someone could redo the STL smart pointer comprehension in lldb 
to use the synthetic child arrow operator emulation, that's a much broader 
feature that what this API is promising.

https://github.com/llvm/llvm-project/pull/73472
___
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 CompilerType class (second try). (PR #73472)

2023-12-05 Thread via lldb-commits


https://github.com/jimingham edited 
https://github.com/llvm/llvm-project/pull/73472
___
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 CompilerType class (second try). (PR #73472)

2023-12-05 Thread via lldb-commits



@@ -194,6 +192,54 @@ class CompilerType {
   bool IsTypedefType() const;
 
   bool IsVoidType() const;
+
+  bool IsSmartPtrType() const;
+
+  bool IsInteger() const;
+
+  bool IsFloat() const;
+
+  bool IsEnumerationType() const;
+
+  bool IsUnscopedEnumerationType() const;
+
+  bool IsIntegerOrUnscopedEnumerationType() const;
+
+  bool IsSigned() const;
+
+  bool IsNullPtrType() const;
+
+  bool IsBoolean() const;
+
+  bool IsEnumerationIntegerTypeSigned() const;
+
+  bool IsScalarOrUnscopedEnumerationType() const;
+
+  bool IsPromotableIntegerType() const;
+
+  bool IsPointerToVoid() const;
+
+  bool IsRecordType() const;
+
+  bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
+ bool carry_virtual = false) const;
+
+  bool IsContextuallyConvertibleToBool() const;
+
+  bool IsBasicType() const;
+
+  std::string TypeDescription();
+
+  bool CompareTypes(CompilerType rhs) const;
+
+  const char *GetTypeTag();
+
+  uint32_t GetNumberOfNonEmptyBaseClasses();
+
+  CompilerType GetTemplateArgumentType(uint32_t idx);
+
+  CompilerType GetSmartPtrPointeeType();

cmtice wrote:

Do you want me to try to update the data formatter to you my function in this 
PR, or should we commit this PR without that change, with the promise that I 
will submit a follow-up PR with the data formatter change?

Jim, I follow what you're saying but I'm not sure if there's a concrete action 
you're asking me to take?

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

[Lldb-commits] [lldb] [lldb] Return index of element in ValueObject path instead of the element's value (PR #74413)

2023-12-05 Thread Chelsea Cassanova via lldb-commits



@@ -414,13 +417,17 @@ lldb::ValueObjectSP ValueObject::GetChildAtIndexPath(
   if (idxs.size() == 0)
 return GetSP();
   ValueObjectSP root(GetSP());
+
+  size_t current_index = 0;
   for (std::pair idx : idxs) {
 root = root->GetChildAtIndex(idx.first, idx.second);
 if (!root) {
   if (index_of_error)
-*index_of_error = idx.first;
+*index_of_error = current_index;
   return root;
 }
+
+current_index += 1;

chelcassanova wrote:

Ditto for `current_index++`

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

[Lldb-commits] [lld] [llvm] [lldb] [libc] [clang] [openmp] [clang-tools-extra] [flang] [compiler-rt] [libcxx] [mlir] [MLIR] Enable GPU Dialect to SYCL runtime integration (PR #71430)

2023-12-05 Thread Sang Ik Lee via lldb-commits


https://github.com/silee2 updated 
https://github.com/llvm/llvm-project/pull/71430

>From c76403cf8629b8f7d8a5b7a3ee5da2881713a7f8 Mon Sep 17 00:00:00 2001
From: "Lee, Sang Ik" 
Date: Mon, 6 Nov 2023 18:47:23 +
Subject: [PATCH 1/6] [MLIR] Enable GPU Dialect to SYCL runtime integration

GPU Dialect lowering to SYCL runtime is driven by spirv.target_env
attached to gpu.module. As a result of this, spirv.target_env remains
as an input to LLVMIR Translation.
A SPIRVToLLVMIRTranslation without any actual translation is added to
avoid an unregistered error in mlir-cpu-runner.
SelectObjectAttr.cpp is updated to
1) Pass binary size argument to getModuleLoadFn
2) Pass parameter count to getKernelLaunchFn
This change does not impact CUDA and ROCM usage since both
mlir_cuda_runtime and mlir_rocm_runtime are already updated to
accept and ignore the extra arguments.
---
 mlir/include/mlir/Target/LLVMIR/Dialect/All.h |  3 ++
 .../Dialect/SPIRV/SPIRVToLLVMIRTranslation.h  | 31 +++
 mlir/lib/Target/LLVMIR/CMakeLists.txt |  1 +
 mlir/lib/Target/LLVMIR/Dialect/CMakeLists.txt |  1 +
 .../LLVMIR/Dialect/GPU/SelectObjectAttr.cpp   | 50 +
 .../LLVMIR/Dialect/SPIRV/CMakeLists.txt   | 13 +
 .../SPIRV/SPIRVToLLVMIRTranslation.cpp| 31 +++
 mlir/test/CMakeLists.txt  |  4 ++
 .../Integration/GPU/SYCL/gpu-to-spirv.mlir| 54 +++
 mlir/test/Integration/GPU/SYCL/lit.local.cfg  |  2 +
 mlir/test/Target/LLVMIR/gpu.mlir  |  9 ++--
 mlir/test/lit.cfg.py  |  3 ++
 mlir/test/lit.site.cfg.py.in  |  1 +
 13 files changed, 188 insertions(+), 15 deletions(-)
 create mode 100644 
mlir/include/mlir/Target/LLVMIR/Dialect/SPIRV/SPIRVToLLVMIRTranslation.h
 create mode 100644 mlir/lib/Target/LLVMIR/Dialect/SPIRV/CMakeLists.txt
 create mode 100644 
mlir/lib/Target/LLVMIR/Dialect/SPIRV/SPIRVToLLVMIRTranslation.cpp
 create mode 100644 mlir/test/Integration/GPU/SYCL/gpu-to-spirv.mlir
 create mode 100644 mlir/test/Integration/GPU/SYCL/lit.local.cfg

diff --git a/mlir/include/mlir/Target/LLVMIR/Dialect/All.h 
b/mlir/include/mlir/Target/LLVMIR/Dialect/All.h
index 0563b9bf3d475..5dfc15afb7593 100644
--- a/mlir/include/mlir/Target/LLVMIR/Dialect/All.h
+++ b/mlir/include/mlir/Target/LLVMIR/Dialect/All.h
@@ -26,6 +26,7 @@
 #include "mlir/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.h"
 #include "mlir/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.h"
 #include "mlir/Target/LLVMIR/Dialect/ROCDL/ROCDLToLLVMIRTranslation.h"
+#include "mlir/Target/LLVMIR/Dialect/SPIRV/SPIRVToLLVMIRTranslation.h"
 #include "mlir/Target/LLVMIR/Dialect/X86Vector/X86VectorToLLVMIRTranslation.h"
 
 namespace mlir {
@@ -45,6 +46,7 @@ static inline void 
registerAllToLLVMIRTranslations(DialectRegistry ®istry) {
   registerOpenACCDialectTranslation(registry);
   registerOpenMPDialectTranslation(registry);
   registerROCDLDialectTranslation(registry);
+  registerSPIRVDialectTranslation(registry);
   registerX86VectorDialectTranslation(registry);
 
   // Extension required for translating GPU offloading Ops.
@@ -61,6 +63,7 @@ registerAllGPUToLLVMIRTranslations(DialectRegistry ®istry) 
{
   registerLLVMDialectTranslation(registry);
   registerNVVMDialectTranslation(registry);
   registerROCDLDialectTranslation(registry);
+  registerSPIRVDialectTranslation(registry);
 
   // Extension required for translating GPU offloading Ops.
   gpu::registerOffloadingLLVMTranslationInterfaceExternalModels(registry);
diff --git 
a/mlir/include/mlir/Target/LLVMIR/Dialect/SPIRV/SPIRVToLLVMIRTranslation.h 
b/mlir/include/mlir/Target/LLVMIR/Dialect/SPIRV/SPIRVToLLVMIRTranslation.h
new file mode 100644
index 0..e9580a10b4ca7
--- /dev/null
+++ b/mlir/include/mlir/Target/LLVMIR/Dialect/SPIRV/SPIRVToLLVMIRTranslation.h
@@ -0,0 +1,31 @@
+//===- SPIRVToLLVMIRTranslation.h - SPIRV to LLVM IR *- 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
+//
+//===--===//
+//
+// This provides registration calls for SPIRV dialect to LLVM IR translation.
+//
+//===--===//
+
+#ifndef MLIR_TARGET_LLVMIR_DIALECT_SPIRV_SPIRVTOLLVMIRTRANSLATION_H
+#define MLIR_TARGET_LLVMIR_DIALECT_SPIRV_SPIRVTOLLVMIRTRANSLATION_H
+
+namespace mlir {
+
+class DialectRegistry;
+class MLIRContext;
+
+/// Register the SPIRV dialect and the translation from it to the LLVM IR in 
the
+/// given registry;
+void registerSPIRVDialectTranslation(DialectRegistry ®istry);
+
+/// Register the SPIRV dialect and the translation from it in the registry
+/// associated with the given context.
+void registerSPIRVDialectTranslation(MLIRContext &context);
+
+} // namespace mlir

[Lldb-commits] [clang-tools-extra] [llvm] [lldb] [openmp] [lld] [libc] [flang] [mlir] [libcxx] [clang] [compiler-rt] [MLIR] Enable GPU Dialect to SYCL runtime integration (PR #71430)

2023-12-05 Thread Sang Ik Lee via lldb-commits



@@ -61,6 +63,7 @@ registerAllGPUToLLVMIRTranslations(DialectRegistry ®istry) 
{
   registerLLVMDialectTranslation(registry);
   registerNVVMDialectTranslation(registry);
   registerROCDLDialectTranslation(registry);
+  registerSPIRVDialectTranslation(registry);

silee2 wrote:

@fabianmcg Added test.
Any other request? The PR has been open for a while and blocking other work 
that depends on it. Would be great if you can approve soon.

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

[Lldb-commits] [flang] [libcxx] [lldb] [clang] [compiler-rt] [lld] [libc] [clang-tools-extra] [llvm] [Clang] Fix linker error for function multiversioning (PR #71706)

2023-12-05 Thread Tom Honermann via lldb-commits


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

This looks good to me. I suggested some edits to the doc; take or leave as you 
see fit!

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

[Lldb-commits] [lldb] [compiler-rt] [libcxx] [clang] [flang] [clang-tools-extra] [llvm] [lld] [libc] [Clang] Fix linker error for function multiversioning (PR #71706)

2023-12-05 Thread Tom Honermann via lldb-commits


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

[Lldb-commits] [lld] [clang] [flang] [libcxx] [clang-tools-extra] [llvm] [compiler-rt] [lldb] [libc] [Clang] Fix linker error for function multiversioning (PR #71706)

2023-12-05 Thread Tom Honermann via lldb-commits



@@ -2515,6 +2515,12 @@ example, the following will emit 4 versions of the 
function:
 __attribute__((target_clones("arch=atom,avx2","arch=ivybridge","default")))
 void foo() {}
 
+Dispatch is done via ``ifunc`` mechanism. The assembler name of the indirect
+function is the original assembler name of the multiversioned function. For
+backward compatibility, an alias to this function is currently generated
+with an ``.ifunc`` suffix. This symbol is deprecated and may be removed
+in the future.
+

tahonermann wrote:

Not all x86/x86-64 targets support the ifunc feature.
```suggestion
For targets that support the GNU indirect function (IFUNC) feature, dispatch
is performed by emitting an indirect function that is resolved to the 
appropriate
target clone at load time. The indirect function is given the name the
multiversioned function would have if it had been declared without the 
attribute.
For backward compatibility with earlier Clang releases, a function alias with an
``.ifunc`` suffix is also emitted. The  ``.ifunc`` suffixed symbol is a 
deprecated
feature and support for it may be removed in the future.
```

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

[Lldb-commits] [flang] [libcxx] [lldb] [clang] [compiler-rt] [lld] [mlir] [libc] [clang-tools-extra] [openmp] [llvm] [MLIR] Enable GPU Dialect to SYCL runtime integration (PR #71430)

2023-12-05 Thread Fabian Mora via lldb-commits


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

LGTM! I'll squash and merge as soon it passes all pre check tests.

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

[Lldb-commits] [lldb] [lldb] Correctly check and report error states in StackFrame.cpp (PR #74414)

2023-12-05 Thread Pete Lawrence via lldb-commits


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

[Lldb-commits] [clang] [clang-tools-extra] [llvm] [lldb] [lldb][test] Apply @expectedFailureAll/@skipIf early for debug_info tests (PR #73067)

2023-12-05 Thread Jordan Rupprecht via lldb-commits


rupprecht wrote:

ping :)

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

[Lldb-commits] [lldb] [lldb] Correctly check and report error states in StackFrame.cpp (PR #74414)

2023-12-05 Thread Pete Lawrence via lldb-commits


https://github.com/PortalPete updated 
https://github.com/llvm/llvm-project/pull/74414

>From 0ea80f827993cb9993931304a53aac69a8276bef Mon Sep 17 00:00:00 2001
From: Pete Lawrence 
Date: Mon, 4 Dec 2023 13:56:38 -1000
Subject: [PATCH] [lldb] Correctly check and report error states in
 StackFrame.cpp

This commits fixes a few subtle bugs where the method:
1. Declares a local `Status error` which eclipses the method's parameter 
`Status &error`.
- The method then sets the error state to the local `error` and returns 
without ever touching the parameter `&error`.
- This effectively traps the error state and its message from ever 
reaching the caller.
- I also threw in a null pointer check in case the callee doesn't set 
its `Status` parameter but returns `0`/`nullptr`.

2. Declares a local `Status deref_error` (good), passes it to the `Dereference` 
method (also good), but then checks the status of the method's `Status &error` 
parameter (not good).
- The fix checks `deref_error` instead and also checks for a `nullptr` 
return value.
- There's a good opportunity here for a future PR that changes the 
`Dereference` method to fold an error state into the `ValueObject` return 
value's `m_error` instead of using a parameter.

3. Declares another local `Status error`, which it doesn't pass to a method 
(because there isn't a parameter for it), and then checks for an error 
condition that never happens.
- The fix just checks the callee's return value, because that's all it 
has to go on.
- This likely comes from a copy/paste from issue 1 above.

rdar://119155810
---
 lldb/source/Target/StackFrame.cpp | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/lldb/source/Target/StackFrame.cpp 
b/lldb/source/Target/StackFrame.cpp
index f0d78d8aa5fef..50cf01e63cd49 100644
--- a/lldb/source/Target/StackFrame.cpp
+++ b/lldb/source/Target/StackFrame.cpp
@@ -652,7 +652,7 @@ ValueObjectSP StackFrame::GetValueForVariableExpressionPath(
 Status deref_error;
 if (valobj_sp->GetCompilerType().IsReferenceType()) {
   valobj_sp = valobj_sp->GetSyntheticValue()->Dereference(deref_error);
-  if (error.Fail()) {
+  if (!valobj_sp || deref_error.Fail()) {
 error.SetErrorStringWithFormatv(
 "Failed to dereference reference type: %s", deref_error);
 return ValueObjectSP();
@@ -660,7 +660,7 @@ ValueObjectSP StackFrame::GetValueForVariableExpressionPath(
 }
 
 valobj_sp = valobj_sp->Dereference(deref_error);
-if (error.Fail()) {
+if (!valobj_sp || deref_error.Fail()) {
   error.SetErrorStringWithFormatv(
   "Failed to dereference sythetic value: {0}", deref_error);
   return ValueObjectSP();
@@ -795,9 +795,9 @@ ValueObjectSP StackFrame::GetValueForVariableExpressionPath(
   // what we have is *ptr[low]. the most similar C++ syntax is to deref
   // ptr and extract bit low out of it. reading array item low would be
   // done by saying ptr[low], without a deref * sign
-  Status error;
-  ValueObjectSP temp(valobj_sp->Dereference(error));
-  if (error.Fail()) {
+  Status deref_error;
+  ValueObjectSP temp(valobj_sp->Dereference(deref_error));
+  if (!temp || deref_error.Fail()) {
 valobj_sp->GetExpressionPath(var_expr_path_strm);
 error.SetErrorStringWithFormat(
 "could not dereference \"(%s) %s\"",
@@ -813,9 +813,8 @@ ValueObjectSP StackFrame::GetValueForVariableExpressionPath(
   // arr[0] (an operation that is equivalent to deref-ing arr) and
   // extract bit low out of it. reading array item low would be done by
   // saying arr[low], without a deref * sign
-  Status error;
   ValueObjectSP temp(valobj_sp->GetChildAtIndex(0));
-  if (error.Fail()) {
+  if (!temp) {
 valobj_sp->GetExpressionPath(var_expr_path_strm);
 error.SetErrorStringWithFormat(
 "could not get item 0 for \"(%s) %s\"",
@@ -994,9 +993,9 @@ ValueObjectSP StackFrame::GetValueForVariableExpressionPath(
 // deref ptr and extract bits low thru high out of it. reading array
 // items low thru high would be done by saying ptr[low-high], without a
 // deref * sign
-Status error;
-ValueObjectSP temp(valobj_sp->Dereference(error));
-if (error.Fail()) {
+Status deref_error;
+ValueObjectSP temp(valobj_sp->Dereference(deref_error));
+if (!temp || deref_error.Fail()) {
   valobj_sp->GetExpressionPath(var_expr_path_strm);
   error.SetErrorStringWithFormat(
   "could not dereference \"(%s) %s\"",
@@ -1011,9 +1010,8 @@ ValueObjectSP 
StackFrame::GetValueForVariableExpressionPath(
 // get arr[0] (an operation that is equivalent to deref-ing arr) a

[Lldb-commits] [llvm] [lldb] [flang] [lld] [libc] [clang] [compiler-rt] [clang-tools-extra] [libcxx] [Clang] Fix linker error for function multiversioning (PR #71706)

2023-12-05 Thread via lldb-commits


https://github.com/elizabethandrews updated 
https://github.com/llvm/llvm-project/pull/71706

>From 534fad70af45a6a22ba2d03f474089e896f4fcd6 Mon Sep 17 00:00:00 2001
From: Elizabeth Andrews 
Date: Thu, 26 Oct 2023 08:53:54 -0700
Subject: [PATCH 1/5] [Clang]  Fix linker error for function multiversioning
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Currently target_clones attribute results in a linker error when
there are no multi-versioned function declarations in the calling TU.

In the calling TU, the call is generated with the ‘normal’ assembly name.
This does not match any of the versions or the ifunc, since version mangling
includes a .versionstring, and the ifunc includes .ifunc suffix. The linker
error is not seen with GCC since the mangling for the ifunc symbol in GCC
is the ‘normal’ assembly name for function i.e. no ifunc suffix.

This PR removes the .ifunc suffix to match GCC. It also adds alias with
the .ifunc suffix so as to ensure backward compatibility.

The changes exclude aarch64 target because the mangling for default
versions on aarch64 does not include a .default suffix and is the
'normal' assembly name, unlike other targets. It is not clear to me
what the correct behavior for this target is.
---
 clang/docs/ReleaseNotes.rst  |  1 +
 clang/lib/CodeGen/CodeGenModule.cpp  | 35 +---
 clang/test/CodeGen/attr-target-clones.c  | 33 +++---
 clang/test/CodeGenCXX/attr-target-clones.cpp | 27 +--
 4 files changed, 70 insertions(+), 26 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 8bac599f88503..9e73fa03a0355 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -550,6 +550,7 @@ Bug Fixes in This Version
   Fixes (`#67687 `_)
 - Fix crash from constexpr evaluator evaluating uninitialized arrays as rvalue.
   Fixes (`#67317 `_)
+- Fix linker error when using multiversioned function defined in a different 
TU.
 
 Bug Fixes to Compiler Builtins
 ^^
diff --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 2e96fff808113..b54c4296a0f9d 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -4098,8 +4098,26 @@ void CodeGenModule::emitMultiVersionFunctions() {
 }
 
 llvm::Constant *ResolverConstant = GetOrCreateMultiVersionResolver(GD);
-if (auto *IFunc = dyn_cast(ResolverConstant))
+if (auto *IFunc = dyn_cast(ResolverConstant)) {
   ResolverConstant = IFunc->getResolver();
+  // In Aarch64, default versions of multiversioned functions are mangled 
to
+  // their 'normal' assembly name. This deviates from other targets which
+  // append a '.default' string. As a result we need to continue appending
+  // .ifunc in Aarch64.
+  // FIXME: Should Aarch64 mangling for 'default' multiversion function and
+  // in turn ifunc function match that of other targets?
+  if (FD->isTargetClonesMultiVersion() &&
+  !getTarget().getTriple().isAArch64()) {
+const CGFunctionInfo &FI = getTypes().arrangeGlobalDeclaration(GD);
+llvm::FunctionType *DeclTy = getTypes().GetFunctionType(FI);
+std::string MangledName = getMangledNameImpl(
+*this, GD, FD, /*OmitMultiVersionMangling=*/true);
+auto *Alias = llvm::GlobalAlias::create(
+DeclTy, 0, llvm::Function::WeakODRLinkage, MangledName + ".ifunc",
+IFunc, &getModule());
+SetCommonAttributes(FD, Alias);
+  }
+}
 llvm::Function *ResolverFunc = cast(ResolverConstant);
 
 ResolverFunc->setLinkage(getMultiversionLinkage(*this, GD));
@@ -4266,10 +4284,19 @@ llvm::Constant 
*CodeGenModule::GetOrCreateMultiVersionResolver(GlobalDecl GD) {
   // Holds the name of the resolver, in ifunc mode this is the ifunc (which has
   // a separate resolver).
   std::string ResolverName = MangledName;
-  if (getTarget().supportsIFunc())
-ResolverName += ".ifunc";
-  else if (FD->isTargetMultiVersion())
+  if (getTarget().supportsIFunc()) {
+// In Aarch64, default versions of multiversioned functions are mangled to
+// their 'normal' assembly name. This deviates from other targets which
+// append a '.default' string. As a result we need to continue appending
+// .ifunc in Aarch64.
+// FIXME: Should Aarch64 mangling for 'default' multiversion function and
+// in turn ifunc function match that of other targets?
+if (!FD->isTargetClonesMultiVersion() ||
+getTarget().getTriple().isAArch64())
+  ResolverName += ".ifunc";
+  } else if (FD->isTargetMultiVersion()) {
 ResolverName += ".resolver";
+  }
 
   // If the resolver has already been created, just return it.
   if (llvm::GlobalValue *ResolverGV = GetGlobalValue(ResolverName))

[Lldb-commits] [lldb] [lldb] Return index of element in ValueObject path instead of the element's value (PR #74413)

2023-12-05 Thread Pete Lawrence via lldb-commits



@@ -398,13 +398,16 @@ ValueObject::GetChildAtIndexPath(llvm::ArrayRef 
idxs,
   if (idxs.size() == 0)
 return GetSP();
   ValueObjectSP root(GetSP());
+
+  size_t current_index = 0;
   for (size_t idx : idxs) {
 root = root->GetChildAtIndex(idx);
 if (!root) {
   if (index_of_error)
-*index_of_error = idx;
+*index_of_error = current_index;
   return root;
 }
+current_index += 1;

PortalPete wrote:

Sure!
I had a hunch someone would point this one out, but I thought it'd be fun to 
see who, if anyone, would.
You passed the test! 😂 

Personally, I prefer `+= 1` because:
- Swift doesn't have the `++` operator.
- In my mind `+= 1` more explicitly communicates my intent.
- I've seen people get burned by the "post" part of a post-increment operator 
too many times. 🙃


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

[Lldb-commits] [lldb] [lldb] Return index of element in ValueObject path instead of the element's value (PR #74413)

2023-12-05 Thread Pete Lawrence via lldb-commits


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

[Lldb-commits] [lldb] [libcxx] [clang] [clang-tools-extra] [llvm] [lld] [compiler-rt] [libc] [flang] [Clang] Fix linker error for function multiversioning (PR #71706)

2023-12-05 Thread via lldb-commits


elizabethandrews wrote:

Thanks for reviews everyone! I think I have addressed all pending comments. I 
will merge the PR in a couple of hours unless someone has remaining concerns. 

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

[Lldb-commits] [lldb] [lldb] Return index of element in ValueObject path instead of the element's value (PR #74413)

2023-12-05 Thread Pete Lawrence via lldb-commits



@@ -414,13 +417,17 @@ lldb::ValueObjectSP ValueObject::GetChildAtIndexPath(
   if (idxs.size() == 0)
 return GetSP();
   ValueObjectSP root(GetSP());
+
+  size_t current_index = 0;
   for (std::pair idx : idxs) {
 root = root->GetChildAtIndex(idx.first, idx.second);
 if (!root) {
   if (index_of_error)
-*index_of_error = idx.first;
+*index_of_error = current_index;
   return root;
 }
+
+current_index += 1;

PortalPete wrote:

I'm actually going to go with `++current_index` because that's what [the LLVM 
coding style](https://llvm.org/docs/CodingStandards.html#prefer-preincrement) 
recommends.


> Hard fast rule: Preincrement (++X) may be no slower than postincrement (X++) 
> and could very well be a lot faster than it. Use preincrementation whenever 
> possible.
>
> ...

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

[Lldb-commits] [lldb] [lldb] Return index of element in ValueObject path instead of the element's value (PR #74413)

2023-12-05 Thread Pete Lawrence via lldb-commits


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

[Lldb-commits] [llvm] [clang-tools-extra] [lldb] [clang] [lldb][test] Apply @expectedFailureAll/@skipIf early for debug_info tests (PR #73067)

2023-12-05 Thread Adrian Prantl via lldb-commits


adrian-prantl wrote:

Is this a performance optimization or a function al change?

https://github.com/llvm/llvm-project/pull/73067
___
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 CompilerType class (second try). (PR #73472)

2023-12-05 Thread Adrian Prantl via lldb-commits



@@ -194,6 +192,54 @@ class CompilerType {
   bool IsTypedefType() const;
 
   bool IsVoidType() const;
+
+  bool IsSmartPtrType() const;
+
+  bool IsInteger() const;
+
+  bool IsFloat() const;
+
+  bool IsEnumerationType() const;
+
+  bool IsUnscopedEnumerationType() const;
+
+  bool IsIntegerOrUnscopedEnumerationType() const;
+
+  bool IsSigned() const;
+
+  bool IsNullPtrType() const;
+
+  bool IsBoolean() const;
+
+  bool IsEnumerationIntegerTypeSigned() const;
+
+  bool IsScalarOrUnscopedEnumerationType() const;
+
+  bool IsPromotableIntegerType() const;
+
+  bool IsPointerToVoid() const;
+
+  bool IsRecordType() const;
+
+  bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
+ bool carry_virtual = false) const;
+
+  bool IsContextuallyConvertibleToBool() const;
+
+  bool IsBasicType() const;
+
+  std::string TypeDescription();
+
+  bool CompareTypes(CompilerType rhs) const;
+
+  const char *GetTypeTag();
+
+  uint32_t GetNumberOfNonEmptyBaseClasses();
+
+  CompilerType GetTemplateArgumentType(uint32_t idx);
+
+  CompilerType GetSmartPtrPointeeType();

adrian-prantl wrote:

> Do you want me to try to update the data formatter to you my function in this 
> PR, or should we commit this PR without that change, with the promise that I 
> will submit a follow-up PR with the data formatter change?

If it's easy to do, sure — but I'm also fine with postponing it for a follow-up 
commit. I just want to make sure we have a clear plan for how to make that 
happen.

https://github.com/llvm/llvm-project/pull/73472
___
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 CompilerType class (second try). (PR #73472)

2023-12-05 Thread Adrian Prantl via lldb-commits


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

[Lldb-commits] [clang-tools-extra] [mlir] [compiler-rt] [llvm] [lldb] [clang] [flang] [Profile] Add binary profile correlation for code coverage. (PR #69493)

2023-12-05 Thread Petr Hosek via lldb-commits



@@ -702,6 +708,8 @@ serializeValueProfDataFrom(ValueProfRecordClosure *Closure,
 #define INSTR_PROF_COVMAP_COMMON __llvm_covmap
 #define INSTR_PROF_COVFUN_COMMON __llvm_covfun
 #define INSTR_PROF_ORDERFILE_COMMON __llvm_orderfile

petrhosek wrote:

This just a nit, but could you move `orderfile` here and elsewhere to the 
bottom so that all `__llvm_cov*` entries are next to each other for easier 
readability.

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

[Lldb-commits] [clang-tools-extra] [mlir] [compiler-rt] [llvm] [lldb] [clang] [flang] [Profile] Add binary profile correlation for code coverage. (PR #69493)

2023-12-05 Thread Petr Hosek via lldb-commits


petrhosek wrote:

Can you break up all the changes to tests that replace `-debug-info-correlate` 
with `--profile-correlate=debug-info` into a separate PR to reduce the size of 
this PR?

https://github.com/llvm/llvm-project/pull/69493
___
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 CompilerType class (second try). (PR #73472)

2023-12-05 Thread via lldb-commits



@@ -194,6 +192,54 @@ class CompilerType {
   bool IsTypedefType() const;
 
   bool IsVoidType() const;
+
+  bool IsSmartPtrType() const;
+
+  bool IsInteger() const;
+
+  bool IsFloat() const;
+
+  bool IsEnumerationType() const;
+
+  bool IsUnscopedEnumerationType() const;
+
+  bool IsIntegerOrUnscopedEnumerationType() const;
+
+  bool IsSigned() const;
+
+  bool IsNullPtrType() const;
+
+  bool IsBoolean() const;
+
+  bool IsEnumerationIntegerTypeSigned() const;
+
+  bool IsScalarOrUnscopedEnumerationType() const;
+
+  bool IsPromotableIntegerType() const;
+
+  bool IsPointerToVoid() const;
+
+  bool IsRecordType() const;
+
+  bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
+ bool carry_virtual = false) const;
+
+  bool IsContextuallyConvertibleToBool() const;
+
+  bool IsBasicType() const;
+
+  std::string TypeDescription();
+
+  bool CompareTypes(CompilerType rhs) const;
+
+  const char *GetTypeTag();
+
+  uint32_t GetNumberOfNonEmptyBaseClasses();
+
+  CompilerType GetTemplateArgumentType(uint32_t idx);
+
+  CompilerType GetSmartPtrPointeeType();

cmtice wrote:

I would prefer to do it in a follow-up commit. (My next PR!).

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

[Lldb-commits] [lldb] 901bc51 - [NFC][lldb] Implement DiagnosticManager::Consume (#74011)

2023-12-05 Thread via lldb-commits


Author: Augusto Noronha
Date: 2023-12-05T12:26:10-08:00
New Revision: 901bc5129d1a1e8ad47801343d48dcd9e01ad386

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

LOG: [NFC][lldb] Implement DiagnosticManager::Consume (#74011)

In some situations it may be useful to have a separate DiagnosticManager
instance, and then later of move the contents of that instance back to
the "main" DiagnosticManager. For example, when silently retrying some
operation with different parameters, depending on whether the retry
succeeded or failed, LLDB may want to present a different set of
diagnostics to the user (the ones generated on the first try vs the
retry). Implement DiagnosticManager::Consume to allow for this use case.

Added: 


Modified: 
lldb/include/lldb/Expression/DiagnosticManager.h

Removed: 




diff  --git a/lldb/include/lldb/Expression/DiagnosticManager.h 
b/lldb/include/lldb/Expression/DiagnosticManager.h
index df9ba3b245f51..06bf1d115f154 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -118,6 +118,15 @@ class DiagnosticManager {
   m_diagnostics.push_back(std::move(diagnostic));
   }
 
+  /// Moves over the contents of a second diagnostic manager over. Leaves other
+  /// diagnostic manager in an empty state.
+  void Consume(DiagnosticManager &&other) {
+std::move(other.m_diagnostics.begin(), other.m_diagnostics.end(),
+  std::back_inserter(m_diagnostics));
+m_fixed_expression = std::move(other.m_fixed_expression);
+other.Clear();
+  }
+
   size_t Printf(DiagnosticSeverity severity, const char *format, ...)
   __attribute__((format(printf, 3, 4)));
   void PutString(DiagnosticSeverity severity, llvm::StringRef str);



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

[Lldb-commits] [lldb] [NFC][lldb] Implement DiagnosticManager::Consume (PR #74011)

2023-12-05 Thread Augusto Noronha via lldb-commits


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

[Lldb-commits] [lldb] Add option to pass thread ID to thread select command (PR #73596)

2023-12-05 Thread via lldb-commits


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

LGTM.  

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

[Lldb-commits] [lld] [llvm] [clang-tools-extra] [compiler-rt] [clang] [lldb] [flang] [libc] [libcxx] [Clang] Fix linker error for function multiversioning (PR #71706)

2023-12-05 Thread Tom Honermann via lldb-commits



@@ -4114,8 +4114,26 @@ void CodeGenModule::emitMultiVersionFunctions() {
 }
 
 llvm::Constant *ResolverConstant = GetOrCreateMultiVersionResolver(GD);
-if (auto *IFunc = dyn_cast(ResolverConstant))
+if (auto *IFunc = dyn_cast(ResolverConstant)) {
   ResolverConstant = IFunc->getResolver();
+  // In Aarch64, default versions of multiversioned functions are mangled 
to
+  // their 'normal' assembly name. This deviates from other targets which
+  // append a '.default' string. As a result we need to continue appending
+  // .ifunc in Aarch64.
+  // FIXME: Should Aarch64 mangling for 'default' multiversion function and
+  // in turn ifunc function match that of other targets?

tahonermann wrote:

Since `target_version` is new, I think it is reasonable to change its behavior 
(via a different github PR).

I suspect the `target` behavior is an artifact of how the multiversion function 
features evolved. My best guess is that the original implementation didn't 
support an indirect function facility that enabled dynamic resolution from 
outside a defining TU. Perhaps that was part of the motivation for adding 
`target_clones`.

I just discovered that gcc doesn't support the `target` attribute when 
compiling for C. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108964. I had 
been under the impression that it just didn't support overloading on the 
`target` attribute (but that the attribute still affected code generation). 
Interesting that no warning is given for an ignored attribute. Here is the 
example from the doc Elizabeth linked compiling as C. 
https://godbolt.org/z/asfrhG51G.

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

[Lldb-commits] [lldb] [lldb] Return index of element in ValueObject path instead of the element's value (PR #74413)

2023-12-05 Thread Chelsea Cassanova via lldb-commits



@@ -398,13 +398,16 @@ ValueObject::GetChildAtIndexPath(llvm::ArrayRef 
idxs,
   if (idxs.size() == 0)
 return GetSP();
   ValueObjectSP root(GetSP());
+
+  size_t current_index = 0;
   for (size_t idx : idxs) {
 root = root->GetChildAtIndex(idx);
 if (!root) {
   if (index_of_error)
-*index_of_error = idx;
+*index_of_error = current_index;
   return root;
 }
+current_index += 1;

chelcassanova wrote:

After reading the Swift rationale for removing the `++` operator I understand 
why you'd use `+= 1` instead.

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

[Lldb-commits] [lldb] [lldb] Return index of element in ValueObject path instead of the element's value (PR #74413)

2023-12-05 Thread Felipe de Azevedo Piovezan via lldb-commits



@@ -414,13 +417,17 @@ lldb::ValueObjectSP ValueObject::GetChildAtIndexPath(
   if (idxs.size() == 0)
 return GetSP();
   ValueObjectSP root(GetSP());
+
+  size_t current_index = 0;
   for (std::pair idx : idxs) {
 root = root->GetChildAtIndex(idx.first, idx.second);
 if (!root) {
   if (index_of_error)
-*index_of_error = idx.first;
+*index_of_error = current_index;
   return root;
 }
+
+current_index += 1;

felipepiovezan wrote:

Note this guideline is about pre vs post, and it refers to iterators mostly.

I don't think you need to change anything here!

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

[Lldb-commits] [lldb] [lldb] Return index of element in ValueObject path instead of the element's value (PR #74413)

2023-12-05 Thread Felipe de Azevedo Piovezan via lldb-commits


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

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-05 Thread José Lira Junior via lldb-commits



@@ -70,6 +72,31 @@ size_t Stream::PutCString(llvm::StringRef str) {
   return bytes_written;
 }
 
+void Stream::PutCStringColorHighlighted(llvm::StringRef text,
+const char *pattern) {
+  if (!pattern) {
+PutCString(text);
+return;
+  }
+
+  // If pattern is not nullptr, we should use color
+  llvm::Regex reg_pattern(pattern);
+  llvm::SmallVector matches;
+  llvm::StringRef remaining = text;
+  std::string format_str = lldb_private::ansi::FormatAnsiTerminalCodes(
+  "${ansi.fg.red}%.*s${ansi.normal}");

junior-jl wrote:

What are your thoughts on this approach? (In `SymbolContext.cpp` - line 98). I 
tested it and it only fails on the new test this PR creates, so we would only 
need to adapt it.

```cpp
if (name) {
llvm::StringRef ansi_prefix;
llvm::StringRef ansi_suffix;
if (target_sp) {
  ansi_prefix = target_sp->GetDebugger().GetRegexMatchAnsiPrefix();
  ansi_suffix = target_sp->GetDebugger().GetRegexMatchAnsiSuffix();
}
s->PutCStringColorHighlighted(name.GetStringRef(), pattern, ansi_prefix,
  ansi_suffix);
  }
```

Or even forcing the red color when there is no target? Honestly, I do not 
completely understand what would mean not having a target.

https://github.com/llvm/llvm-project/pull/69422
___
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 CompilerType class (second try). (PR #73472)

2023-12-05 Thread via lldb-commits



@@ -194,6 +192,54 @@ class CompilerType {
   bool IsTypedefType() const;
 
   bool IsVoidType() const;
+
+  bool IsSmartPtrType() const;
+
+  bool IsInteger() const;
+
+  bool IsFloat() const;
+
+  bool IsEnumerationType() const;
+
+  bool IsUnscopedEnumerationType() const;
+
+  bool IsIntegerOrUnscopedEnumerationType() const;
+
+  bool IsSigned() const;
+
+  bool IsNullPtrType() const;
+
+  bool IsBoolean() const;
+
+  bool IsEnumerationIntegerTypeSigned() const;
+
+  bool IsScalarOrUnscopedEnumerationType() const;
+
+  bool IsPromotableIntegerType() const;
+
+  bool IsPointerToVoid() const;
+
+  bool IsRecordType() const;
+
+  bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
+ bool carry_virtual = false) const;
+
+  bool IsContextuallyConvertibleToBool() const;
+
+  bool IsBasicType() const;
+
+  std::string TypeDescription();
+
+  bool CompareTypes(CompilerType rhs) const;
+
+  const char *GetTypeTag();
+
+  uint32_t GetNumberOfNonEmptyBaseClasses();
+
+  CompilerType GetTemplateArgumentType(uint32_t idx);
+
+  CompilerType GetSmartPtrPointeeType();

jimingham wrote:

I was mostly trying to say that the ValueObject support for "faking the arrow 
operator effects" is orthogonal to having the type system contain the notion of 
"smart pointers".  

I also think the whole naming of this is confusing.  What is a "smart pointer"? 
 The IsSmartPtr states some intent about this:

`  /// This determines if the type is a shared, unique or weak pointer, either
  /// from stdlibc++ or libc+++.
  bool IsSmartPtrType() const;
`

But that is also a little odd.  This is a general type system query but doesn't 
in fact have anything to do with the type system.  Rather with a particular 
implementation in the C++ STL - which is orthogonal to the C++ type system...  
So it seems like an awfully C++ specific API to have in the Typesystem.



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

[Lldb-commits] [lldb] [lldb][SymbolFileDWARF][NFC] Remove unnecessary calls to GetDWARFDeclContext (PR #74523)

2023-12-05 Thread Felipe de Azevedo Piovezan via lldb-commits


https://github.com/felipepiovezan created 
https://github.com/llvm/llvm-project/pull/74523

The function FindDefinitionTypeForDWARFDeclContext loops over all DIEs 
corresponding to types with a certain name and compares the context of each 
found DIE with the context of a target DIE. However, the target DIE never 
changes throughout this search, and yet we recompute its DeclContext on every 
iteration of the search. This is wasteful because the method is not exactly 
free (see DWARFDebugInfoEntry::GetDWARFDeclContextStatic).

>From f101f4386e9d164b654f0a2176c228e9debb2a47 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Thu, 19 Oct 2023 13:45:09 -0700
Subject: [PATCH] [lldb][SymbolFileDWARF][NFC] Remove unnecessary calls to
 GetDWARFDeclContext

The function FindDefinitionTypeForDWARFDeclContext loops over all DIEs
corresponding to types with a certain name and compares the context of each
found DIE with the context of a target DIE. However, the target DIE never
changes throughout this search, and yet we recompute its DeclContext on every
iteration of the search. This is wasteful because the method is not exactly free
(see DWARFDebugInfoEntry::GetDWARFDeclContextStatic).
---
 lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 142d092e6d2ee..d4cc26a3c329b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -3120,7 +3120,8 @@ 
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE &die) {
 template_params = dwarf_ast->GetDIEClassTemplateParams(die);
 }
 
-m_index->GetTypes(GetDWARFDeclContext(die), [&](DWARFDIE type_die) {
+const DWARFDeclContext die_dwarf_decl_ctx = GetDWARFDeclContext(die);
+m_index->GetTypes(die_dwarf_decl_ctx, [&](DWARFDIE type_die) {
   // Make sure type_die's language matches the type system we are
   // looking for. We don't want to find a "Foo" type from Java if we
   // are looking for a "Foo" type for C, C++, ObjC, or ObjC++.
@@ -3184,7 +3185,7 @@ 
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE &die) {
   }
 
   // Make sure the decl contexts match all the way up
-  if (GetDWARFDeclContext(die) != type_dwarf_decl_ctx)
+  if (die_dwarf_decl_ctx != type_dwarf_decl_ctx)
 return true;
 
   Type *resolved_type = ResolveType(type_die, false);

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

[Lldb-commits] [lldb] [lldb][SymbolFileDWARF][NFC] Remove unnecessary calls to GetDWARFDeclContext (PR #74523)

2023-12-05 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Felipe de Azevedo Piovezan (felipepiovezan)


Changes

The function FindDefinitionTypeForDWARFDeclContext loops over all DIEs 
corresponding to types with a certain name and compares the context of each 
found DIE with the context of a target DIE. However, the target DIE never 
changes throughout this search, and yet we recompute its DeclContext on every 
iteration of the search. This is wasteful because the method is not exactly 
free (see DWARFDebugInfoEntry::GetDWARFDeclContextStatic).

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


1 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+3-2) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 142d092e6d2ee..d4cc26a3c329b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -3120,7 +3120,8 @@ 
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE &die) {
 template_params = dwarf_ast->GetDIEClassTemplateParams(die);
 }
 
-m_index->GetTypes(GetDWARFDeclContext(die), [&](DWARFDIE type_die) {
+const DWARFDeclContext die_dwarf_decl_ctx = GetDWARFDeclContext(die);
+m_index->GetTypes(die_dwarf_decl_ctx, [&](DWARFDIE type_die) {
   // Make sure type_die's language matches the type system we are
   // looking for. We don't want to find a "Foo" type from Java if we
   // are looking for a "Foo" type for C, C++, ObjC, or ObjC++.
@@ -3184,7 +3185,7 @@ 
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE &die) {
   }
 
   // Make sure the decl contexts match all the way up
-  if (GetDWARFDeclContext(die) != type_dwarf_decl_ctx)
+  if (die_dwarf_decl_ctx != type_dwarf_decl_ctx)
 return true;
 
   Type *resolved_type = ResolveType(type_die, false);

``




https://github.com/llvm/llvm-project/pull/74523
___
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 CompilerType class (second try). (PR #73472)

2023-12-05 Thread via lldb-commits



@@ -194,6 +192,54 @@ class CompilerType {
   bool IsTypedefType() const;
 
   bool IsVoidType() const;
+
+  bool IsSmartPtrType() const;
+
+  bool IsInteger() const;
+
+  bool IsFloat() const;
+
+  bool IsEnumerationType() const;
+
+  bool IsUnscopedEnumerationType() const;
+
+  bool IsIntegerOrUnscopedEnumerationType() const;
+
+  bool IsSigned() const;
+
+  bool IsNullPtrType() const;
+
+  bool IsBoolean() const;
+
+  bool IsEnumerationIntegerTypeSigned() const;
+
+  bool IsScalarOrUnscopedEnumerationType() const;
+
+  bool IsPromotableIntegerType() const;
+
+  bool IsPointerToVoid() const;
+
+  bool IsRecordType() const;
+
+  bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
+ bool carry_virtual = false) const;
+
+  bool IsContextuallyConvertibleToBool() const;
+
+  bool IsBasicType() const;
+
+  std::string TypeDescription();
+
+  bool CompareTypes(CompilerType rhs) const;
+
+  const char *GetTypeTag();
+
+  uint32_t GetNumberOfNonEmptyBaseClasses();
+
+  CompilerType GetTemplateArgumentType(uint32_t idx);
+
+  CompilerType GetSmartPtrPointeeType();

jimingham wrote:

Having a comment saying "This is defined only for C++ types" in a function from 
CompilerType.h seems wrong.

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

[Lldb-commits] [clang-tools-extra] [lld] [compiler-rt] [libcxx] [clang] [llvm] [lldb] [libc] [flang] [Clang] Fix linker error for function multiversioning (PR #71706)

2023-12-05 Thread via lldb-commits


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


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

[Lldb-commits] [mlir] [llvm] [lldb] [flang] [clang] [compiler-rt] [clang-tools-extra] [Profile] Add binary profile correlation for code coverage. (PR #69493)

2023-12-05 Thread Zequan Wu via lldb-commits


ZequanWu wrote:

> Can you break up all the changes to tests that replace 
> `-debug-info-correlate` with `--profile-correlate=debug-info` into a separate 
> PR to reduce the size of this PR?

Done.

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

[Lldb-commits] [clang] [flang] [llvm] [clang-tools-extra] [mlir] [lldb] [compiler-rt] [Profile] Add binary profile correlation for code coverage. (PR #69493)

2023-12-05 Thread Zequan Wu via lldb-commits



@@ -702,6 +708,8 @@ serializeValueProfDataFrom(ValueProfRecordClosure *Closure,
 #define INSTR_PROF_COVMAP_COMMON __llvm_covmap
 #define INSTR_PROF_COVFUN_COMMON __llvm_covfun
 #define INSTR_PROF_ORDERFILE_COMMON __llvm_orderfile

ZequanWu wrote:

Done.

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

[Lldb-commits] [lldb] [lldb][SymbolFileDWARF][NFC] Remove unnecessary calls to GetDWARFDeclContext (PR #74523)

2023-12-05 Thread Adrian Prantl via lldb-commits


https://github.com/adrian-prantl approved this pull request.


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

[Lldb-commits] [lldb] [lldb][SymbolFileDWARF][NFC] Remove unnecessary calls to GetDWARFDeclContext (PR #74523)

2023-12-05 Thread Greg Clayton via lldb-commits


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


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

[Lldb-commits] [clang] [libc] [compiler-rt] [libcxx] [lld] [mlir] [clang-tools-extra] [llvm] [flang] [openmp] [lldb] [MLIR] Enable GPU Dialect to SYCL runtime integration (PR #71430)

2023-12-05 Thread Fabian Mora via lldb-commits


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

[Lldb-commits] [clang-tools-extra] [lldb] [llvm] [clang] [lldb][test] Apply @expectedFailureAll/@skipIf early for debug_info tests (PR #73067)

2023-12-05 Thread Jordan Rupprecht via lldb-commits


rupprecht wrote:

> Is this a performance optimization or a function al change?

Neither. This should only affect tests, and the set of tests we skip/mark as 
xfail should not change, we just generally know about it earlier in the test 
setup.

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

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-05 Thread Chelsea Cassanova via lldb-commits


chelcassanova wrote:

@clayborg Just pinging on this PR (when you have the chance) :)

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

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-05 Thread Greg Clayton via lldb-commits


clayborg wrote:

So we have a function in SBDebugger:
```
  static const char *GetProgressFromEvent(const lldb::SBEvent &event,
  uint64_t &progress_id,
  uint64_t &completed, uint64_t &total,
  bool &is_debugger_specific);
```
Do we need an overload to allow access to the Progress::ProgressReportType? If 
so, then we need to move the Progress::ProgressReportType enum into 
lldb-enumerations. In our public API we can never remove or change the 
arguments in a function call, so we would need to add another overload if we 
want this.

We also have:
```
  static lldb::SBStructuredData 
lldb::SBDebugger::GetProgressDataFromEvent(const lldb::SBEvent &event);
```
I am guessing that the report type shows up in here?


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

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-05 Thread Greg Clayton via lldb-commits



@@ -55,6 +55,11 @@ namespace lldb_private {
 
 class Progress {
 public:
+  /// Enum that indicates the type of progress report
+  enum class ProgressReportType {
+eAggregateProgressReport,
+eNonAggregateProgressReport
+  };

clayborg wrote:

This might need to belong in lldb-enumerations if we want 
`SBDebugger::GetProgressFromEvent(...)` to have an overload where this is 
supplied.

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

[Lldb-commits] [lldb] Add option to pass thread ID to thread select command (PR #73596)

2023-12-05 Thread Greg Clayton via lldb-commits


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


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

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [lldb][test] Apply @expectedFailureAll/@skipIf early for debug_info tests (PR #73067)

2023-12-05 Thread Adrian Prantl via lldb-commits


adrian-prantl wrote:

SGTM, maybe wait one more day for @JDevlieghere to chime in.

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

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-05 Thread Chelsea Cassanova via lldb-commits


chelcassanova wrote:

The report type has been added as a key in the dictionary that gets returned 
from `SBDebugger::GetProgressDataFromEvent` (specifically it's the key 
`is_aggregate`) and that key is added in `DebuggerEvents.cpp`. To my 
understanding since we can get the report type from `GetProgressDataFromEvent` 
we shouldn't have to overload `GetProgressFromEvent`.

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

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-05 Thread Jason Molenda via lldb-commits



@@ -63,13 +68,30 @@ class Progress {
   ///
   /// @param [in] title The title of this progress activity.
   ///
-  /// @param [in] total The total units of work to be done if specified, if
-  /// set to UINT64_MAX then an indeterminate progress indicator should be
+  /// @param [in] report_type Enum value indicating how the progress is being

jasonmolenda wrote:

Normally these start with `@param [in] variable_name`, and then on the next 
line the description starts.  I see @clayborg wrote the current header in this 
style, maybe it was a clang-format artifact?  Or possibly the preferred style 
has shifted while I wasn't paying attention.

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

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-05 Thread Jason Molenda via lldb-commits



@@ -63,13 +68,30 @@ class Progress {
   ///
   /// @param [in] title The title of this progress activity.
   ///
-  /// @param [in] total The total units of work to be done if specified, if
-  /// set to UINT64_MAX then an indeterminate progress indicator should be
+  /// @param [in] report_type Enum value indicating how the progress is being
+  /// reported. Progress reports considered "aggregate" are reports done for
+  /// operations that may happen multiple times during a debug session.
+  ///
+  /// For example, when a debug session is first started it needs to parse the

jasonmolenda wrote:

Is this the case that I attach to a running process and I find 100 binaries 
loaded in the process.  I create Module/ObjectFile's for each binary, including 
parsing the symbol table, possibly looking for a dSYM or a dwp symbol file with 
debug information for each of those.  If dSYMs are an example of additional 
binaries that may need to be scanned (and report progress as they're being 
scanned), is it sufficient to simply mention how each of the hundred binaries 
in the process will report a status update as its Module is created, and not 
mention dSYMs specifically?

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

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-05 Thread Jason Molenda via lldb-commits



@@ -97,12 +119,17 @@ class Progress {
   /// The title of the progress activity.
   std::string m_title;
   std::mutex m_mutex;
+  /// Set to eNonAggregateProgressReport if the progress event is aggregate;

jasonmolenda wrote:

I'm a little confused by this comment.  Set to eNonAggregateProgressReport if 
the progress report is aggregate?

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

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-05 Thread Jason Molenda via lldb-commits



@@ -55,6 +55,11 @@ namespace lldb_private {
 
 class Progress {
 public:
+  /// Enum that indicates the type of progress report
+  enum class ProgressReportType {
+eAggregateProgressReport,
+eNonAggregateProgressReport

jasonmolenda wrote:

I wonder if it might be a little easier to intuit if the enums were 
eAggregateProgressReport and eIndividualProgressReport?  Then someone might 
look at this and say "oh I have a single thing I'm providing progress on, I 
probably want eIndividualProgressReport".  I don't feel strongly that I'm 
correct here, just throwing it out.

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

[Lldb-commits] [flang] [clang-tools-extra] [compiler-rt] [libcxx] [lld] [llvm] [clang] [libc] [lldb] [Clang] Fix linker error for function multiversioning (PR #71706)

2023-12-05 Thread via lldb-commits


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

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-05 Thread Jason Molenda via lldb-commits



@@ -55,6 +55,11 @@ namespace lldb_private {
 
 class Progress {
 public:
+  /// Enum that indicates the type of progress report
+  enum class ProgressReportType {
+eAggregateProgressReport,
+eNonAggregateProgressReport

jasonmolenda wrote:

Maybe eSolitaryProgressReport

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

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-05 Thread Chelsea Cassanova via lldb-commits


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

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-05 Thread Chelsea Cassanova via lldb-commits



@@ -63,13 +68,30 @@ class Progress {
   ///
   /// @param [in] title The title of this progress activity.
   ///
-  /// @param [in] total The total units of work to be done if specified, if
-  /// set to UINT64_MAX then an indeterminate progress indicator should be
+  /// @param [in] report_type Enum value indicating how the progress is being

chelcassanova wrote:

I've clang-formatted these files and that didn't change this comment style so I 
guess clang-format is just going with was already here, strange 🤔 

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

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-05 Thread Chelsea Cassanova via lldb-commits



@@ -97,12 +119,17 @@ class Progress {
   /// The title of the progress activity.
   std::string m_title;
   std::mutex m_mutex;
+  /// Set to eNonAggregateProgressReport if the progress event is aggregate;

chelcassanova wrote:

Mistake by me 😓 

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

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-05 Thread Chelsea Cassanova via lldb-commits


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

1 2 >

1 - 100 of 121 matches

Mail list logo