[Lldb-commits] [clang] [clang-tools-extra] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread via lldb-commits

chrisPyr wrote:

Ok, to make it clear, I’ll split it up by projects.
And I will leave function local variables as-is.
Is that fair enough?

On Sat, Feb 8, 2025 at 04:45 Vitaly Buka ***@***.***> wrote:

> All these changes are independent and quite straight forward.
>
> I'd suggest to split in some way, so it's easier to review, land, and
> revert if we miss and break something.
>
> Maybe by component.
> also globals vs function local etc.
>
> —
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>


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


[Lldb-commits] [lldb] [LLDB][LoongArch] Extend the maximum number of watchpoints (PR #126204)

2025-02-07 Thread Lu Weining via lldb-commits

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


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


[Lldb-commits] [lldb] ff79d83 - [LLDB][LoongArch] Extend the maximum number of watchpoints (#126204)

2025-02-07 Thread via lldb-commits

Author: Tiezhu Yang
Date: 2025-02-08T10:31:48+08:00
New Revision: ff79d83caeeea8457f69406f38801fe8893bbfd8

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

LOG: [LLDB][LoongArch] Extend the maximum number of watchpoints (#126204)

The maximum number of load/store watchpoints and fetch instruction
watchpoints is 14 each according to LoongArch Reference Manual [1],
so extend the maximum number of watchpoints from 8 to 14 for ptrace.

A new struct user_watch_state_v2 was added into uapi in the related
kernel commit 531936dee53e ("LoongArch: Extend the maximum number of
watchpoints") [2], but there may be no struct user_watch_state_v2 in
the system header in time.

In order to avoid undefined or redefined error, just add a new struct
loongarch_user_watch_state in LLDB which is same with the uapi struct
user_watch_state_v2, then replace the current user_watch_state with
loongarch_user_watch_state.

As far as I can tell, the only users for this struct in the userspace
are GDB and LLDB, there are no any problems of software compatibility
between the application and kernel according to the analysis.

The compatibility problem has been considered while developing and
testing. When the applications in the userspace get watchpoint state,
the length will be specified which is no bigger than the sizeof struct
user_watch_state or user_watch_state_v2, the actual length is assigned
as the minimal value of the application and kernel in the generic code
of ptrace:

```
kernel/ptrace.c: ptrace_regset():

kiov->iov_len = min(kiov->iov_len,
(__kernel_size_t) (regset->n * regset->size));

if (req == PTRACE_GETREGSET)
return copy_regset_to_user(task, view, regset_no, 0,
   kiov->iov_len, kiov->iov_base);
else
return copy_regset_from_user(task, view, regset_no, 0,
 kiov->iov_len, kiov->iov_base);
```

For example, there are four kind of combinations, all of them work well.

(1) "older kernel + older app", the actual length is 8+(8+8+4+4)*8=200;
(2) "newer kernel + newer app", the actual length is 8+(8+8+4+4)*14=344;
(3) "older kernel + newer app", the actual length is 8+(8+8+4+4)*8=200;
(4) "newer kernel + older app", the actual length is 8+(8+8+4+4)*8=200.

[1]
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=531936dee53e

Signed-off-by: Tiezhu Yang 

Added: 


Modified: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
index 601dde250094892..c4841950f1e07c9 100644
--- 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
+++ 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
@@ -50,6 +50,23 @@
 #define REG_CONTEXT_SIZE   
\
   (GetGPRSize() + GetFPRSize() + sizeof(m_lsx) + sizeof(m_lasx))
 
+// ptrace has a struct type user_watch_state, which was replaced by
+// user_watch_state_v2 when more watchpoints were added, so this file
+// may be built on systems with one or both in the system headers.
+// The type below has the same layout as user_watch_state_v2 but will
+// not clash with that name if it exists. We can use the v2 layout even
+// on old kernels as we will only see 8 watchpoints and the kernel will
+// truncate any extra data we send to it.
+struct loongarch_user_watch_state {
+  uint64_t dbg_info;
+  struct {
+uint64_t addr;
+uint64_t mask;
+uint32_t ctrl;
+uint32_t pad;
+  } dbg_regs[14];
+};
+
 using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::process_linux;
@@ -539,7 +556,7 @@ llvm::Error 
NativeRegisterContextLinux_loongarch64::ReadHardwareDebugInfo() {
 
   int regset = NT_LOONGARCH_HW_WATCH;
   struct iovec ioVec;
-  struct user_watch_state dreg_state;
+  struct loongarch_user_watch_state dreg_state;
   Status error;
 
   ioVec.iov_base = &dreg_state;
@@ -567,7 +584,7 @@ llvm::Error 
NativeRegisterContextLinux_loongarch64::ReadHardwareDebugInfo() {
 llvm::Error NativeRegisterContextLinux_loongarch64::WriteHardwareDebugRegs(
 DREGType hwbType) {
   struct iovec ioVec;
-  struct user_watch_state dreg_state;
+  struct loongarch_user_watch_state dreg_state;
   int regset;
 
   memset(&dreg_state, 0, sizeof(dreg_state));



___
lldb-commits mailin

[Lldb-commits] [lldb] [LLDB][LoongArch] Extend the maximum number of watchpoints (PR #126204)

2025-02-07 Thread Lu Weining via lldb-commits

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


[Lldb-commits] [lldb] [lldb-dap] Refactoring lldb-dap port listening mode to allow multiple connections. (PR #116392)

2025-02-07 Thread John Harrison via lldb-commits

https://github.com/ashgti updated 
https://github.com/llvm/llvm-project/pull/116392

>From 88a8522f1b29b2ff392974322acdb722b7e00b70 Mon Sep 17 00:00:00 2001
From: John Harrison 
Date: Tue, 28 Jan 2025 12:39:38 -0800
Subject: [PATCH 1/5] [lldb-dap] Refactoring lldb-dap port listening mode to
 allow multiple connections.

This adjusts the lldb-dap listening mode to accept multiple clients.
Each client initializes a new instance of DAP and an associated 
`lldb::SBDebugger` instance.

The listening mode is configured with the `--connection` option and supports 
listening on a port or a unix socket on supported platforms.
---
 .../test/tools/lldb-dap/dap_server.py |  74 -
 .../test/tools/lldb-dap/lldbdap_testcase.py   |   6 +-
 lldb/test/API/tools/lldb-dap/server/Makefile  |   3 +
 .../tools/lldb-dap/server/TestDAP_server.py   |  77 +
 lldb/test/API/tools/lldb-dap/server/main.c|  10 +
 lldb/test/Shell/DAP/TestOptions.test  |   4 +-
 lldb/tools/lldb-dap/DAP.cpp   |  18 +-
 lldb/tools/lldb-dap/DAP.h |   6 +-
 lldb/tools/lldb-dap/DAPForward.h  |   2 +
 lldb/tools/lldb-dap/Options.td|  22 +-
 lldb/tools/lldb-dap/lldb-dap.cpp  | 283 +++---
 11 files changed, 358 insertions(+), 147 deletions(-)
 create mode 100644 lldb/test/API/tools/lldb-dap/server/Makefile
 create mode 100644 lldb/test/API/tools/lldb-dap/server/TestDAP_server.py
 create mode 100644 lldb/test/API/tools/lldb-dap/server/main.c

diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index c29992ce9c7848e..6d765e10236733a 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -903,7 +903,7 @@ def request_setBreakpoints(self, file_path, line_array, 
data=None):
 "sourceModified": False,
 }
 if line_array is not None:
-args_dict["lines"] = "%s" % line_array
+args_dict["lines"] = line_array
 breakpoints = []
 for i, line in enumerate(line_array):
 breakpoint_data = None
@@ -1150,11 +1150,12 @@ def request_setInstructionBreakpoints(self, 
memory_reference=[]):
 }
 return self.send_recv(command_dict)
 
+
 class DebugAdaptorServer(DebugCommunication):
 def __init__(
 self,
 executable=None,
-port=None,
+connection=None,
 init_commands=[],
 log_file=None,
 env=None,
@@ -1167,21 +1168,62 @@ def __init__(
 
 if log_file:
 adaptor_env["LLDBDAP_LOG"] = log_file
+args = [executable]
+
+if connection is not None:
+args.append("--connection")
+args.append(connection)
+
 self.process = subprocess.Popen(
-[executable],
+args,
 stdin=subprocess.PIPE,
 stdout=subprocess.PIPE,
 stderr=subprocess.PIPE,
 env=adaptor_env,
 )
+
+if connection is not None:
+# If the process was also launched, parse the connection from the
+# resolved connection. For example, if the connection
+# `connection://localhost:0` was specified then the OS would pick a
+# random port for listening and lldb-dap would print the listening
+# port to stdout.
+if self.process is not None:
+# lldb-dap will print the listening address once the listener 
is
+# made to stdout. The listener is formatted like
+# `connection://host:port` or `unix-connection:///path`.
+expected_prefix = "Listening for: "
+out = self.process.stdout.readline().decode()
+if not out.startswith(expected_prefix):
+self.process.kill()
+raise ValueError(
+"lldb-dap failed to print listening address, expected 
'{}', got '{}'".format(
+expected_prefix, out
+)
+)
+
+# If the listener expanded into multiple addresses, use the 
first.
+connection = (
+
out.removeprefix(expected_prefix).rstrip("\r\n").split(",", 1)[0]
+)
+
+scheme, address = connection.split("://")
+if scheme == "unix-connect":  # unix-connect:///path
+s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
+s.connect(address)
+elif scheme == "connection":  # connection://[host]:port
+host, port = address.rsplit(":", 1)
+# create_connection with try both ipv4 and ipv6.
+s = socket.create_connection((host.strip("[]"), int(port)))
+

[Lldb-commits] [clang] [lldb] Reland: [clang] fix P3310 overload resolution flag propagation (PR #125791)

2025-02-07 Thread Matheus Izvekov via lldb-commits

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


[Lldb-commits] [clang] [lldb] [lldb][TypeSystemClang] Initialize ClassTemplateSpecializationDecl's StrictPackMatch field (PR #126215)

2025-02-07 Thread Matheus Izvekov via lldb-commits

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


[Lldb-commits] [lldb] [lldb][NFC] Replace GetLocalBufferSize() with GetLocalBuffer() (PR #126333)

2025-02-07 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Augusto Noronha (augusto2112)


Changes

GetLocalBuffer() makes more sense as an API.

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


4 Files Affected:

- (modified) lldb/include/lldb/ValueObject/ValueObject.h (+9-8) 
- (modified) lldb/source/ValueObject/ValueObject.cpp (+6-6) 
- (modified) lldb/source/ValueObject/ValueObjectDynamicValue.cpp (+1-1) 
- (modified) lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp 
(+1-4) 


``diff
diff --git a/lldb/include/lldb/ValueObject/ValueObject.h 
b/lldb/include/lldb/ValueObject/ValueObject.h
index c8d5c2723106d6d..a0f53d20327cdc5 100644
--- a/lldb/include/lldb/ValueObject/ValueObject.h
+++ b/lldb/include/lldb/ValueObject/ValueObject.h
@@ -865,17 +865,18 @@ class ValueObject {
 
   virtual void SetLanguageFlags(uint64_t flags) { m_language_flags = flags; }
 
-  /// Returns the size of the local buffer if it's available.
+  /// Returns the local buffer that this ValueObject points to if it's
+  /// available.
   /// \return
-  /// The size of the local buffer if this value object's value points to a
-  /// host address, and if that size can be determined. Otherwise, returns
-  /// LLDB_INVALID_ADDRESS.
+  /// The local buffer if this value object's value points to a
+  /// host address, and if that buffer can be determined. Otherwise, 
returns
+  /// an empty ArrayRef.
   ///
   /// TODO: Because a ValueObject's Value can point to any arbitrary memory
-  /// location, it is possible that the size of the local buffer can't be
-  /// determined at all. See the comment in Value::m_value for a more thorough
-  /// explanation of why that is.
-  uint64_t GetLocalBufferSize();
+  /// location, it is possible that we can't find what what buffer we're
+  /// pointing to, and thus also can't know its size. See the comment in
+  /// Value::m_value for a more thorough explanation of why that is.
+  llvm::ArrayRef GetLocalBuffer() const;
 
 protected:
   typedef ClusterManager ValueObjectManager;
diff --git a/lldb/source/ValueObject/ValueObject.cpp 
b/lldb/source/ValueObject/ValueObject.cpp
index 551d882a48d40f6..9d98f62c0379b65 100644
--- a/lldb/source/ValueObject/ValueObject.cpp
+++ b/lldb/source/ValueObject/ValueObject.cpp
@@ -849,20 +849,20 @@ bool ValueObject::SetData(DataExtractor &data, Status 
&error) {
   return true;
 }
 
-uint64_t ValueObject::GetLocalBufferSize() {
+llvm::ArrayRef ValueObject::GetLocalBuffer() const {
   if (m_value.GetValueType() != Value::ValueType::HostAddress)
-return LLDB_INVALID_ADDRESS;
+return {};
   auto start = m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
   if (start == LLDB_INVALID_ADDRESS)
-return LLDB_INVALID_ADDRESS;
+return {};
   // Does our pointer point to this value object's m_data buffer?
   if ((uint64_t)m_data.GetDataStart() == start)
-return m_data.GetByteSize();
+return m_data.GetData();
   // Does our pointer point to the value's buffer?
   if ((uint64_t)m_value.GetBuffer().GetBytes() == start)
-return m_value.GetBuffer().GetByteSize();
+return m_value.GetBuffer().GetData();
   // Our pointer points to something else. We can't know what the size is.
-  return LLDB_INVALID_ADDRESS;
+  return {};
 }
 
 static bool CopyStringDataToBufferSP(const StreamString &source,
diff --git a/lldb/source/ValueObject/ValueObjectDynamicValue.cpp 
b/lldb/source/ValueObject/ValueObjectDynamicValue.cpp
index dddb0f0700b38a4..ecd663af68c2dbe 100644
--- a/lldb/source/ValueObject/ValueObjectDynamicValue.cpp
+++ b/lldb/source/ValueObject/ValueObjectDynamicValue.cpp
@@ -241,7 +241,7 @@ bool ValueObjectDynamicValue::UpdateValue() {
   SetValueDidChange(true);
 
 // If we found a host address, and the dynamic type fits in the local 
buffer
-// that was found, point to thar buffer. Later on this function will copy
+// that was found, point to that buffer. Later on this function will copy
 // the buffer over.
 if (value_type == Value::ValueType::HostAddress && !local_buffer.empty()) {
   auto *exe_scope = exe_ctx.GetBestExecutionContextScope();
diff --git a/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp 
b/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp
index e3cf0f8a87bd2a3..417708dd2dc226c 100644
--- a/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp
+++ b/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp
@@ -66,11 +66,8 @@ struct MockLanguageRuntime : public LanguageRuntime {
 *ast, "TypeWitInt", ast->GetBasicType(lldb::BasicType::eBasicTypeInt),
 "theIntField", LanguageType::eLanguageTypeC_plus_plus);
 class_type_or_name.SetCompilerType(int_type);
-local_buffer = {(uint8_t *)in_value.GetValue().GetScalar().ULongLong(
-LLDB_INVALID_ADDRESS),
-static_cast(in_value.GetLocalBufferSize())};
+local_buffer = in_value.GetLocalBuffer();
 value_type = 

[Lldb-commits] [clang] [clang-tools-extra] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Rahul Joshi via lldb-commits


@@ -20,7 +20,7 @@ using namespace mlir::lsp;
 
 LogicalResult mlir::MlirLspServerMain(int argc, char **argv,
   DialectRegistry ®istry) {
-  llvm::cl::opt inputStyle{
+  static llvm::cl::opt inputStyle{

jurahul wrote:

These are function local variables and need not be changed to static.

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


[Lldb-commits] [lldb] [lldb][NFC] Defer python init until ScriptInterpreter is created (PR #105757)

2025-02-07 Thread Daniel Xu via lldb-commits

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


[Lldb-commits] [lldb] [lldb][NFC] Defer python init until ScriptInterpreter is created (PR #105757)

2025-02-07 Thread Daniel Xu via lldb-commits

danobi wrote:

Hi @labath, sorry for late reply, I must've missed a notification :(

That makes sense to me - perhaps LLDB is not the right dependency for us to 
take.

https://github.com/llvm/llvm-project/pull/105757
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread David Blaikie via lldb-commits

dwblaikie wrote:

> I don't quite follow the motivation for this, can you expand on this in the 
> description please? Right now this seems unnecessary for the changes I can 
> see in MLIR for example.

The linked bug seems to explain it, I think? It seems to be the usual "if 
something isn't/doesn't need to be declared in a header, then it should be 
file-local static, so as to not conflict with other local names in other files"?

https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Rahul Joshi via lldb-commits


@@ -119,24 +119,24 @@ int main(int argc, char **argv) {
   // options as static variables.. some of which overlap with our options.
   llvm::cl::ResetCommandLineParser();
 
-  llvm::cl::opt inputFilename(
+  static llvm::cl::opt inputFilename(

jurahul wrote:

These are function local variables and need not be changed to static.

https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread David Blaikie via lldb-commits

dwblaikie wrote:

> > > I don't quite follow the motivation for this, can you expand on this in 
> > > the description please? Right now this seems unnecessary for the changes 
> > > I can see in MLIR for example.
> > 
> > 
> > The linked bug seems to explain it, I think? It seems to be the usual "if 
> > something isn't/doesn't need to be declared in a header, then it should be 
> > file-local static, so as to not conflict with other local names in other 
> > files"?
> 
> Right, though I think @joker-eph comment is that for lot of the MLIR changes, 
> these option variables are function local and they need not be changed to 
> static. This issue is only applicable to file scoped variables.

ah, fair enough - yeah, not sure what the right thihng to do with the locals 
is. At least in some cases I glanced at, the categories were static local, so 
arguably the opts could be too - but because it's not clear which way, and 
doesn't have the same problems as globals - best to leave them as-is.

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


[Lldb-commits] [lldb] [lldb] Implement a statusline in LLDB (PR #121860)

2025-02-07 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere updated 
https://github.com/llvm/llvm-project/pull/121860

>From 19f5185ac5b19a656e0109d8aa011c49b36c5934 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Fri, 17 Jan 2025 17:10:36 -0800
Subject: [PATCH 1/2] [lldb] Implement a statusline in LLDB
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Add a statusline to command-line LLDB to display progress events and
other information related to the current state of the debugger. The
statusline is a dedicated area displayed the bottom of the screen. The
contents of the status line are configurable through a setting
consisting of LLDB’s format strings.

The statusline is configurable through the `statusline-format` setting.
The default configuration shows the target name, the current file, the
stop reason and the current progress event.

```
(lldb) settings show statusline-format
statusline-format (format-string) = 
"${ansi.bg.cyan}${ansi.fg.black}{${target.file.basename}}{ | 
${line.file.basename}:${line.number}:${line.column}}{ | ${thread.stop-reason}}{ 
| {${progress.count} }${progress.message}}"
```

The statusline is enabled by default, but can be disabled with the
following setting:

```
(lldb) settings set show-statusline false
```

The statusline supersedes the current progress reporting implementation.
Consequently, the following settings no longer have any effect (but
continue to exist):

```
show-progress -- Whether to show progress or not if the debugger's 
output is an interactive color-enabled terminal.
show-progress-ansi-prefix -- When displaying progress in a color-enabled 
terminal, use the ANSI terminal code specified in this format immediately 
before the progress message.
show-progress-ansi-suffix -- When displaying progress in a color-enabled 
terminal, use the ANSI terminal code specified in this format immediately after 
the progress message.
```

RFC: https://discourse.llvm.org/t/rfc-lldb-statusline/83948
---
 lldb/include/lldb/Core/Debugger.h |  23 ++-
 lldb/include/lldb/Core/FormatEntity.h |   4 +-
 lldb/include/lldb/Core/Statusline.h   |  60 +++
 .../Python/lldbsuite/test/lldbtest.py |   2 +
 lldb/source/Core/CMakeLists.txt   |   1 +
 lldb/source/Core/CoreProperties.td|   8 +
 lldb/source/Core/Debugger.cpp | 157 +
 lldb/source/Core/FormatEntity.cpp |  44 -
 lldb/source/Core/Statusline.cpp   | 160 ++
 .../TestTrimmedProgressReporting.py   |  51 --
 .../API/functionalities/statusline/Makefile   |   3 +
 .../statusline/TestStatusline.py  |  38 +
 .../API/functionalities/statusline/main.c |  11 ++
 13 files changed, 427 insertions(+), 135 deletions(-)
 create mode 100644 lldb/include/lldb/Core/Statusline.h
 create mode 100644 lldb/source/Core/Statusline.cpp
 delete mode 100644 
lldb/test/API/functionalities/progress_reporting/TestTrimmedProgressReporting.py
 create mode 100644 lldb/test/API/functionalities/statusline/Makefile
 create mode 100644 lldb/test/API/functionalities/statusline/TestStatusline.py
 create mode 100644 lldb/test/API/functionalities/statusline/main.c

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 70f4c4216221c65..716e0e830371d03 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -19,6 +19,7 @@
 #include "lldb/Core/FormatEntity.h"
 #include "lldb/Core/IOHandler.h"
 #include "lldb/Core/SourceManager.h"
+#include "lldb/Core/Statusline.h"
 #include "lldb/Core/UserSettingsController.h"
 #include "lldb/Host/HostThread.h"
 #include "lldb/Host/StreamFile.h"
@@ -308,6 +309,10 @@ class Debugger : public 
std::enable_shared_from_this,
 
   bool SetShowProgress(bool show_progress);
 
+  bool GetShowStatusline() const;
+
+  const FormatEntity::Entry *GetStatuslineFormat() const;
+
   llvm::StringRef GetShowProgressAnsiPrefix() const;
 
   llvm::StringRef GetShowProgressAnsiSuffix() const;
@@ -604,6 +609,14 @@ class Debugger : public 
std::enable_shared_from_this,
 return m_source_file_cache;
   }
 
+  struct ProgressReport {
+uint64_t id;
+uint64_t completed;
+uint64_t total;
+std::string message;
+  };
+  std::optional GetCurrentProgressReport() const;
+
 protected:
   friend class CommandInterpreter;
   friend class REPL;
@@ -653,6 +666,8 @@ class Debugger : public 
std::enable_shared_from_this,
 
   void PrintProgress(const ProgressEventData &data);
 
+  bool StatuslineSupported();
+
   void PushIOHandler(const lldb::IOHandlerSP &reader_sp,
  bool cancel_top_handler = true);
 
@@ -728,7 +743,7 @@ class Debugger : public 
std::enable_shared_from_this,
   IOHandlerStack m_io_handler_stack;
   std::recursive_mutex m_io_handler_synchronous_mutex;
 
-  std::optional m_current_event_id;
+  std::optional m_statusline;
 
   llvm::StringMap> m_stream_handler

[Lldb-commits] [lldb] [lldb] Implement a statusline in LLDB (PR #121860)

2025-02-07 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere updated 
https://github.com/llvm/llvm-project/pull/121860

>From 19f5185ac5b19a656e0109d8aa011c49b36c5934 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Fri, 17 Jan 2025 17:10:36 -0800
Subject: [PATCH] [lldb] Implement a statusline in LLDB
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Add a statusline to command-line LLDB to display progress events and
other information related to the current state of the debugger. The
statusline is a dedicated area displayed the bottom of the screen. The
contents of the status line are configurable through a setting
consisting of LLDB’s format strings.

The statusline is configurable through the `statusline-format` setting.
The default configuration shows the target name, the current file, the
stop reason and the current progress event.

```
(lldb) settings show statusline-format
statusline-format (format-string) = 
"${ansi.bg.cyan}${ansi.fg.black}{${target.file.basename}}{ | 
${line.file.basename}:${line.number}:${line.column}}{ | ${thread.stop-reason}}{ 
| {${progress.count} }${progress.message}}"
```

The statusline is enabled by default, but can be disabled with the
following setting:

```
(lldb) settings set show-statusline false
```

The statusline supersedes the current progress reporting implementation.
Consequently, the following settings no longer have any effect (but
continue to exist):

```
show-progress -- Whether to show progress or not if the debugger's 
output is an interactive color-enabled terminal.
show-progress-ansi-prefix -- When displaying progress in a color-enabled 
terminal, use the ANSI terminal code specified in this format immediately 
before the progress message.
show-progress-ansi-suffix -- When displaying progress in a color-enabled 
terminal, use the ANSI terminal code specified in this format immediately after 
the progress message.
```

RFC: https://discourse.llvm.org/t/rfc-lldb-statusline/83948
---
 lldb/include/lldb/Core/Debugger.h |  23 ++-
 lldb/include/lldb/Core/FormatEntity.h |   4 +-
 lldb/include/lldb/Core/Statusline.h   |  60 +++
 .../Python/lldbsuite/test/lldbtest.py |   2 +
 lldb/source/Core/CMakeLists.txt   |   1 +
 lldb/source/Core/CoreProperties.td|   8 +
 lldb/source/Core/Debugger.cpp | 157 +
 lldb/source/Core/FormatEntity.cpp |  44 -
 lldb/source/Core/Statusline.cpp   | 160 ++
 .../TestTrimmedProgressReporting.py   |  51 --
 .../API/functionalities/statusline/Makefile   |   3 +
 .../statusline/TestStatusline.py  |  38 +
 .../API/functionalities/statusline/main.c |  11 ++
 13 files changed, 427 insertions(+), 135 deletions(-)
 create mode 100644 lldb/include/lldb/Core/Statusline.h
 create mode 100644 lldb/source/Core/Statusline.cpp
 delete mode 100644 
lldb/test/API/functionalities/progress_reporting/TestTrimmedProgressReporting.py
 create mode 100644 lldb/test/API/functionalities/statusline/Makefile
 create mode 100644 lldb/test/API/functionalities/statusline/TestStatusline.py
 create mode 100644 lldb/test/API/functionalities/statusline/main.c

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 70f4c4216221c65..716e0e830371d03 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -19,6 +19,7 @@
 #include "lldb/Core/FormatEntity.h"
 #include "lldb/Core/IOHandler.h"
 #include "lldb/Core/SourceManager.h"
+#include "lldb/Core/Statusline.h"
 #include "lldb/Core/UserSettingsController.h"
 #include "lldb/Host/HostThread.h"
 #include "lldb/Host/StreamFile.h"
@@ -308,6 +309,10 @@ class Debugger : public 
std::enable_shared_from_this,
 
   bool SetShowProgress(bool show_progress);
 
+  bool GetShowStatusline() const;
+
+  const FormatEntity::Entry *GetStatuslineFormat() const;
+
   llvm::StringRef GetShowProgressAnsiPrefix() const;
 
   llvm::StringRef GetShowProgressAnsiSuffix() const;
@@ -604,6 +609,14 @@ class Debugger : public 
std::enable_shared_from_this,
 return m_source_file_cache;
   }
 
+  struct ProgressReport {
+uint64_t id;
+uint64_t completed;
+uint64_t total;
+std::string message;
+  };
+  std::optional GetCurrentProgressReport() const;
+
 protected:
   friend class CommandInterpreter;
   friend class REPL;
@@ -653,6 +666,8 @@ class Debugger : public 
std::enable_shared_from_this,
 
   void PrintProgress(const ProgressEventData &data);
 
+  bool StatuslineSupported();
+
   void PushIOHandler(const lldb::IOHandlerSP &reader_sp,
  bool cancel_top_handler = true);
 
@@ -728,7 +743,7 @@ class Debugger : public 
std::enable_shared_from_this,
   IOHandlerStack m_io_handler_stack;
   std::recursive_mutex m_io_handler_synchronous_mutex;
 
-  std::optional m_current_event_id;
+  std::optional m_statusline;
 
   llvm::StringMap> m_stream_handlers;
 

[Lldb-commits] [lldb] [lldb] Implement a statusline in LLDB (PR #121860)

2025-02-07 Thread via lldb-commits

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
darker --check --diff -r 
51759ffc4408e9eb5c2d40c9489ce3b98de233d5...19f5185ac5b19a656e0109d8aa011c49b36c5934
 lldb/test/API/functionalities/statusline/TestStatusline.py 
lldb/packages/Python/lldbsuite/test/lldbtest.py
``





View the diff from darker here.


``diff
--- test/API/functionalities/statusline/TestStatusline.py   2025-02-07 
21:10:41.00 +
+++ test/API/functionalities/statusline/TestStatusline.py   2025-02-07 
21:13:45.348701 +
@@ -5,11 +5,10 @@
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test.lldbpexpect import PExpectTest
 
 
 class TestStatusline(PExpectTest):
-
 # PExpect uses many timeouts internally and doesn't play well
 # under ASAN on a loaded machine..
 @skipIfAsan
 def test(self):
 """Basic test for the statusline.

``




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


[Lldb-commits] [lldb] [LLDB-DAP] SBDebugger don't prefix title on progress updates (PR #124648)

2025-02-07 Thread Jonas Devlieghere via lldb-commits


@@ -427,14 +452,27 @@ void ProgressEventThreadFunction(DAP &dap) {
   done = true;
 }
   } else {
-uint64_t progress_id = 0;
-uint64_t completed = 0;
-uint64_t total = 0;
-bool is_debugger_specific = false;
-const char *message = lldb::SBDebugger::GetProgressFromEvent(
-event, progress_id, completed, total, is_debugger_specific);
-if (message)
-  dap.SendProgressEvent(progress_id, message, completed, total);
+lldb::SBStructuredData data =
+lldb::SBDebugger::GetProgressDataFromEvent(event);
+
+uint64_t progress_id = GetUintFromStructuredData(data, "progress_id");
+uint64_t completed = GetUintFromStructuredData(data, "completed");
+uint64_t total = GetUintFromStructuredData(data, "total");

JDevlieghere wrote:

```suggestion
const uint64_t progress_id = GetUintFromStructuredData(data, 
"progress_id");
const uint64_t completed = GetUintFromStructuredData(data, "completed");
const uint64_t total = GetUintFromStructuredData(data, "total");
const std::string details = GetStringFromStructuredData(data, 
"details");
```

Nit: I'd make these const to make it clear that we're not going to change 
these, as opposed to the message that we're building. I'd also move details up 
here so that all the message building is co-located. 

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


[Lldb-commits] [lldb] [LLDB-DAP] SBDebugger don't prefix title on progress updates (PR #124648)

2025-02-07 Thread Jonas Devlieghere via lldb-commits


@@ -427,14 +452,27 @@ void ProgressEventThreadFunction(DAP &dap) {
   done = true;
 }
   } else {
-uint64_t progress_id = 0;
-uint64_t completed = 0;
-uint64_t total = 0;
-bool is_debugger_specific = false;
-const char *message = lldb::SBDebugger::GetProgressFromEvent(
-event, progress_id, completed, total, is_debugger_specific);
-if (message)
-  dap.SendProgressEvent(progress_id, message, completed, total);
+lldb::SBStructuredData data =
+lldb::SBDebugger::GetProgressDataFromEvent(event);
+
+uint64_t progress_id = GetUintFromStructuredData(data, "progress_id");
+uint64_t completed = GetUintFromStructuredData(data, "completed");
+uint64_t total = GetUintFromStructuredData(data, "total");
+std::string message;
+// Include the title on the first event.
+if (completed == 0) {
+  std::string title = GetStringFromStructuredData(data, "title");
+  message += title;
+  message += ": ";
+}
+
+std::string details = GetStringFromStructuredData(data, "details");
+message += details;
+// Verbose check, but we get -1 for the uint64 on failure to read
+// so we check everything before broadcasting an event.
+if (message.length() > 0 && progress_id > 0 && total >= 0 &&
+completed >= 0)

JDevlieghere wrote:

`total` and `completed` are unsigned so isn't `total >= 0 && completed >= 0` 
always true?

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


[Lldb-commits] [lldb] [LLDB-DAP] SBDebugger don't prefix title on progress updates (PR #124648)

2025-02-07 Thread Jonas Devlieghere via lldb-commits


@@ -411,6 +412,30 @@ void SendStdOutStdErr(DAP &dap, lldb::SBProcess &process) {
 dap.SendOutput(OutputType::Stderr, llvm::StringRef(buffer, count));
 }
 
+static std::string GetStringFromStructuredData(lldb::SBStructuredData &data,
+   const char *key) {
+  lldb::SBStructuredData keyValue = data.GetValueForKey(key);
+  if (!keyValue)
+return std::string();
+
+  size_t size = keyValue.GetStringValue(nullptr, 0);
+  std::cout << "Size for " << key << " " << size << std::endl;
+  std::string stringValue;
+  stringValue.resize(size);
+  keyValue.GetStringValue(&stringValue[0], size + 1);
+  std::cout << "String value after: " << stringValue << std::endl;
+  return stringValue;

JDevlieghere wrote:

```suggestion
  lldb::SBStructuredData keyValue = data.GetValueForKey(key);
  if (!keyValue)
return std::string();

const size_t length = keyValue.GetStringValue(nullptr, 0);
std::string str(length + 1, 0);
value.GetStringValue(&str[0], length);
return str;
```

Not really, you can avoid the resize with the ctor but otherwise that's as good 
as it gets (without the logging). 

https://github.com/llvm/llvm-project/pull/124648
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Mehdi Amini via lldb-commits

joker-eph wrote:

I don't quite follow the motivation for this, can you expand on this in the 
description please? Right now this seems unnecessary for the changes I can see 
in MLIR for example.

https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Rahul Joshi via lldb-commits

jurahul wrote:

> > I don't quite follow the motivation for this, can you expand on this in the 
> > description please? Right now this seems unnecessary for the changes I can 
> > see in MLIR for example.
> 
> The linked bug seems to explain it, I think? It seems to be the usual "if 
> something isn't/doesn't need to be declared in a header, then it should be 
> file-local static, so as to not conflict with other local names in other 
> files"?

Right, though I think @joker-eph comment is that for lot of the MLIR changes, 
these option variables are function local and they need not be changed to 
static.

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


[Lldb-commits] [lldb] [lldb] Implement a statusline in LLDB (PR #121860)

2025-02-07 Thread Alex Langford via lldb-commits

bulbazord wrote:

> Rebased & fixed the existing tests.

Looks like 
`lldb/test/API/functionalities/progress_reporting/TestTrimmedProgressReporting.py`
 was deleted entirely. Was this intentional?

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


[Lldb-commits] [lldb] [lldb][TypeSystemClang] Create EnumExtensibilityAttr from DW_AT_APPLE_enum_kind (PR #126221)

2025-02-07 Thread Adrian Prantl via lldb-commits

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

Nice!

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


[Lldb-commits] [lldb] [lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… (PR #125143)

2025-02-07 Thread Augusto Noronha via lldb-commits

augusto2112 wrote:

Thanks @DavidSpickett 

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


[Lldb-commits] [lldb] [lldb] Implement a statusline in LLDB (PR #121860)

2025-02-07 Thread Jonas Devlieghere via lldb-commits

JDevlieghere wrote:

Rebased & fixed the existing tests.

https://github.com/llvm/llvm-project/pull/121860
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Rahul Joshi via lldb-commits

jurahul wrote:

Also, the commit description should be something like: "[NFC] Make file-local 
cl::opt global variables static" or something like that

https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Vitaly Buka via lldb-commits

vitalybuka wrote:

All these changes are independent and quite straight forward.

I'd suggest to split in some way, so it's easier to review, land, and revert if 
we miss and break something.

Maybe by component.
also globals vs function local etc.


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


[Lldb-commits] [lldb] [lldb] Upstream a few remaining Triple::XROS patches (PR #126335)

2025-02-07 Thread Jason Molenda via lldb-commits

https://github.com/jasonmolenda created 
https://github.com/llvm/llvm-project/pull/126335

Recognize the visionOS Triple::OSType::XROS os type. Some of these have already 
been landed on main, but I reviewed the downstream sources and there were a few 
that still needed to be landed upstream.

>From 81ef3d1b169a689c8da464b1c580f92b9f404a98 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Fri, 7 Feb 2025 18:50:54 -0800
Subject: [PATCH] [lldb] Upstream a few remaining Triple::XROS patches

Recognize the visionOS Triple::OSType::XROS os type.
Some of these have already been landed on main, but
I reviewed the downstream sources and there were a
few that still needed to be landed upstream.
---
 lldb/source/Plugins/ABI/X86/ABISysV_x86_64.cpp |  1 +
 .../DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp  | 10 --
 .../Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp  |  5 ++---
 .../Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp   |  3 +++
 .../gdb-remote/GDBRemoteCommunicationServerCommon.cpp  |  2 ++
 lldb/tools/debugserver/source/RNBRemote.cpp|  4 
 6 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/lldb/source/Plugins/ABI/X86/ABISysV_x86_64.cpp 
b/lldb/source/Plugins/ABI/X86/ABISysV_x86_64.cpp
index 54028b1b3261a7c..83b01b14aedc5e3 100644
--- a/lldb/source/Plugins/ABI/X86/ABISysV_x86_64.cpp
+++ b/lldb/source/Plugins/ABI/X86/ABISysV_x86_64.cpp
@@ -79,6 +79,7 @@ ABISysV_x86_64::CreateInstance(lldb::ProcessSP process_sp, 
const ArchSpec &arch)
 case llvm::Triple::OSType::IOS:
 case llvm::Triple::OSType::TvOS:
 case llvm::Triple::OSType::WatchOS:
+case llvm::Triple::OSType::XROS:
   switch (os_env) {
   case llvm::Triple::EnvironmentType::MacABI:
   case llvm::Triple::EnvironmentType::Simulator:
diff --git 
a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp 
b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
index d512d6143639cd7..14d05a1a4494cfe 100644
--- a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
+++ b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
@@ -419,6 +419,8 @@ bool DynamicLoaderDarwin::JSONImageInformationIntoImageInfo(
 image_infos[i].os_type = llvm::Triple::WatchOS;
   else if (os_name == "bridgeos")
 image_infos[i].os_type = llvm::Triple::BridgeOS;
+  else if (os_name == "xros")
+image_infos[i].os_type = llvm::Triple::XROS;
   else if (os_name == "maccatalyst") {
 image_infos[i].os_type = llvm::Triple::IOS;
 image_infos[i].os_env = llvm::Triple::MacABI;
@@ -431,6 +433,9 @@ bool DynamicLoaderDarwin::JSONImageInformationIntoImageInfo(
   } else if (os_name == "watchossimulator") {
 image_infos[i].os_type = llvm::Triple::WatchOS;
 image_infos[i].os_env = llvm::Triple::Simulator;
+  } else if (os_name == "xrsimulator") {
+image_infos[i].os_type = llvm::Triple::XROS;
+image_infos[i].os_env = llvm::Triple::Simulator;
   }
 }
 if (image->HasKey("min_version_os_sdk")) {
@@ -765,7 +770,8 @@ bool DynamicLoaderDarwin::AddModulesUsingPreloadedModules(
   (dyld_triple.getEnvironment() == llvm::Triple::Simulator &&
(dyld_triple.getOS() == llvm::Triple::IOS ||
 dyld_triple.getOS() == llvm::Triple::TvOS ||
-dyld_triple.getOS() == llvm::Triple::WatchOS)))
+dyld_triple.getOS() == llvm::Triple::WatchOS ||
+dyld_triple.getOS() == llvm::Triple::XROS)))
 image_module_sp->MergeArchitecture(dyld_spec);
 }
   }
@@ -835,7 +841,7 @@ lldb_private::ArchSpec 
DynamicLoaderDarwin::ImageInfo::GetArchitecture() const {
   }
   if (os_env == llvm::Triple::Simulator &&
   (os_type == llvm::Triple::IOS || os_type == llvm::Triple::TvOS ||
-   os_type == llvm::Triple::WatchOS)) {
+   os_type == llvm::Triple::WatchOS || os_type == llvm::Triple::XROS)) {
 llvm::Triple triple(llvm::Twine(arch_spec.GetArchitectureName()) +
 "-apple-" + llvm::Triple::getOSTypeName(os_type) +
 min_version_os_sdk + "-simulator");
diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index bf2d293d2012ca4..4b69fa6e2bfb292 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -2848,7 +2848,7 @@ void ObjectFileMachO::ParseSymtab(Symtab &symtab) {
   "DSC unmapped local symbol[{0}] has invalid "
   "string table offset {1:x} in {2}, ignoring symbol",
   nlist_index, nlist.n_strx,
-  module_sp->GetFileSpec().GetPath());
+  module_sp->GetFileSpec().GetPath()));
   continue;
 }
 if (symbol_name[0] == '\0')
@@ -6557,9 +

[Lldb-commits] [lldb] [lldb] Upstream a few remaining Triple::XROS patches (PR #126335)

2025-02-07 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jason Molenda (jasonmolenda)


Changes

Recognize the visionOS Triple::OSType::XROS os type. Some of these have already 
been landed on main, but I reviewed the downstream sources and there were a few 
that still needed to be landed upstream.

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


6 Files Affected:

- (modified) lldb/source/Plugins/ABI/X86/ABISysV_x86_64.cpp (+1) 
- (modified) 
lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp (+8-2) 
- (modified) lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp (+2-3) 
- (modified) lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp (+3) 
- (modified) 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp 
(+2) 
- (modified) lldb/tools/debugserver/source/RNBRemote.cpp (+4) 


``diff
diff --git a/lldb/source/Plugins/ABI/X86/ABISysV_x86_64.cpp 
b/lldb/source/Plugins/ABI/X86/ABISysV_x86_64.cpp
index 54028b1b3261a7c..83b01b14aedc5e3 100644
--- a/lldb/source/Plugins/ABI/X86/ABISysV_x86_64.cpp
+++ b/lldb/source/Plugins/ABI/X86/ABISysV_x86_64.cpp
@@ -79,6 +79,7 @@ ABISysV_x86_64::CreateInstance(lldb::ProcessSP process_sp, 
const ArchSpec &arch)
 case llvm::Triple::OSType::IOS:
 case llvm::Triple::OSType::TvOS:
 case llvm::Triple::OSType::WatchOS:
+case llvm::Triple::OSType::XROS:
   switch (os_env) {
   case llvm::Triple::EnvironmentType::MacABI:
   case llvm::Triple::EnvironmentType::Simulator:
diff --git 
a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp 
b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
index d512d6143639cd7..14d05a1a4494cfe 100644
--- a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
+++ b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
@@ -419,6 +419,8 @@ bool DynamicLoaderDarwin::JSONImageInformationIntoImageInfo(
 image_infos[i].os_type = llvm::Triple::WatchOS;
   else if (os_name == "bridgeos")
 image_infos[i].os_type = llvm::Triple::BridgeOS;
+  else if (os_name == "xros")
+image_infos[i].os_type = llvm::Triple::XROS;
   else if (os_name == "maccatalyst") {
 image_infos[i].os_type = llvm::Triple::IOS;
 image_infos[i].os_env = llvm::Triple::MacABI;
@@ -431,6 +433,9 @@ bool DynamicLoaderDarwin::JSONImageInformationIntoImageInfo(
   } else if (os_name == "watchossimulator") {
 image_infos[i].os_type = llvm::Triple::WatchOS;
 image_infos[i].os_env = llvm::Triple::Simulator;
+  } else if (os_name == "xrsimulator") {
+image_infos[i].os_type = llvm::Triple::XROS;
+image_infos[i].os_env = llvm::Triple::Simulator;
   }
 }
 if (image->HasKey("min_version_os_sdk")) {
@@ -765,7 +770,8 @@ bool DynamicLoaderDarwin::AddModulesUsingPreloadedModules(
   (dyld_triple.getEnvironment() == llvm::Triple::Simulator &&
(dyld_triple.getOS() == llvm::Triple::IOS ||
 dyld_triple.getOS() == llvm::Triple::TvOS ||
-dyld_triple.getOS() == llvm::Triple::WatchOS)))
+dyld_triple.getOS() == llvm::Triple::WatchOS ||
+dyld_triple.getOS() == llvm::Triple::XROS)))
 image_module_sp->MergeArchitecture(dyld_spec);
 }
   }
@@ -835,7 +841,7 @@ lldb_private::ArchSpec 
DynamicLoaderDarwin::ImageInfo::GetArchitecture() const {
   }
   if (os_env == llvm::Triple::Simulator &&
   (os_type == llvm::Triple::IOS || os_type == llvm::Triple::TvOS ||
-   os_type == llvm::Triple::WatchOS)) {
+   os_type == llvm::Triple::WatchOS || os_type == llvm::Triple::XROS)) {
 llvm::Triple triple(llvm::Twine(arch_spec.GetArchitectureName()) +
 "-apple-" + llvm::Triple::getOSTypeName(os_type) +
 min_version_os_sdk + "-simulator");
diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index bf2d293d2012ca4..4b69fa6e2bfb292 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -2848,7 +2848,7 @@ void ObjectFileMachO::ParseSymtab(Symtab &symtab) {
   "DSC unmapped local symbol[{0}] has invalid "
   "string table offset {1:x} in {2}, ignoring symbol",
   nlist_index, nlist.n_strx,
-  module_sp->GetFileSpec().GetPath());
+  module_sp->GetFileSpec().GetPath()));
   continue;
 }
 if (symbol_name[0] == '\0')
@@ -6557,9 +6557,8 @@ bool ObjectFileMachO::SaveCore(const lldb::ProcessSP 
&process_sp,
target_triple.getOS() == llvm::Triple::IOS ||
target_triple.getOS() == llvm::Triple::WatchOS ||
target_triple.getOS() == llvm::Triple::TvOS ||
+   target_triple.

[Lldb-commits] [lldb] 9d5edc9 - [lldb][NFC] Replace GetLocalBufferSize() with GetLocalBuffer() (#126333)

2025-02-07 Thread via lldb-commits

Author: Augusto Noronha
Date: 2025-02-07T19:12:35-08:00
New Revision: 9d5edc9a0dd35049017aad2a9d3f4a4a2746fec9

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

LOG: [lldb][NFC] Replace GetLocalBufferSize() with GetLocalBuffer() (#126333)

Added: 


Modified: 
lldb/include/lldb/ValueObject/ValueObject.h
lldb/source/ValueObject/ValueObject.cpp
lldb/source/ValueObject/ValueObjectDynamicValue.cpp
lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp

Removed: 




diff  --git a/lldb/include/lldb/ValueObject/ValueObject.h 
b/lldb/include/lldb/ValueObject/ValueObject.h
index c8d5c2723106d6d..a0f53d20327cdc5 100644
--- a/lldb/include/lldb/ValueObject/ValueObject.h
+++ b/lldb/include/lldb/ValueObject/ValueObject.h
@@ -865,17 +865,18 @@ class ValueObject {
 
   virtual void SetLanguageFlags(uint64_t flags) { m_language_flags = flags; }
 
-  /// Returns the size of the local buffer if it's available.
+  /// Returns the local buffer that this ValueObject points to if it's
+  /// available.
   /// \return
-  /// The size of the local buffer if this value object's value points to a
-  /// host address, and if that size can be determined. Otherwise, returns
-  /// LLDB_INVALID_ADDRESS.
+  /// The local buffer if this value object's value points to a
+  /// host address, and if that buffer can be determined. Otherwise, 
returns
+  /// an empty ArrayRef.
   ///
   /// TODO: Because a ValueObject's Value can point to any arbitrary memory
-  /// location, it is possible that the size of the local buffer can't be
-  /// determined at all. See the comment in Value::m_value for a more thorough
-  /// explanation of why that is.
-  uint64_t GetLocalBufferSize();
+  /// location, it is possible that we can't find what what buffer we're
+  /// pointing to, and thus also can't know its size. See the comment in
+  /// Value::m_value for a more thorough explanation of why that is.
+  llvm::ArrayRef GetLocalBuffer() const;
 
 protected:
   typedef ClusterManager ValueObjectManager;

diff  --git a/lldb/source/ValueObject/ValueObject.cpp 
b/lldb/source/ValueObject/ValueObject.cpp
index 551d882a48d40f6..9d98f62c0379b65 100644
--- a/lldb/source/ValueObject/ValueObject.cpp
+++ b/lldb/source/ValueObject/ValueObject.cpp
@@ -849,20 +849,20 @@ bool ValueObject::SetData(DataExtractor &data, Status 
&error) {
   return true;
 }
 
-uint64_t ValueObject::GetLocalBufferSize() {
+llvm::ArrayRef ValueObject::GetLocalBuffer() const {
   if (m_value.GetValueType() != Value::ValueType::HostAddress)
-return LLDB_INVALID_ADDRESS;
+return {};
   auto start = m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
   if (start == LLDB_INVALID_ADDRESS)
-return LLDB_INVALID_ADDRESS;
+return {};
   // Does our pointer point to this value object's m_data buffer?
   if ((uint64_t)m_data.GetDataStart() == start)
-return m_data.GetByteSize();
+return m_data.GetData();
   // Does our pointer point to the value's buffer?
   if ((uint64_t)m_value.GetBuffer().GetBytes() == start)
-return m_value.GetBuffer().GetByteSize();
+return m_value.GetBuffer().GetData();
   // Our pointer points to something else. We can't know what the size is.
-  return LLDB_INVALID_ADDRESS;
+  return {};
 }
 
 static bool CopyStringDataToBufferSP(const StreamString &source,

diff  --git a/lldb/source/ValueObject/ValueObjectDynamicValue.cpp 
b/lldb/source/ValueObject/ValueObjectDynamicValue.cpp
index dddb0f0700b38a4..ecd663af68c2dbe 100644
--- a/lldb/source/ValueObject/ValueObjectDynamicValue.cpp
+++ b/lldb/source/ValueObject/ValueObjectDynamicValue.cpp
@@ -241,7 +241,7 @@ bool ValueObjectDynamicValue::UpdateValue() {
   SetValueDidChange(true);
 
 // If we found a host address, and the dynamic type fits in the local 
buffer
-// that was found, point to thar buffer. Later on this function will copy
+// that was found, point to that buffer. Later on this function will copy
 // the buffer over.
 if (value_type == Value::ValueType::HostAddress && !local_buffer.empty()) {
   auto *exe_scope = exe_ctx.GetBestExecutionContextScope();

diff  --git a/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp 
b/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp
index e3cf0f8a87bd2a3..417708dd2dc226c 100644
--- a/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp
+++ b/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp
@@ -66,11 +66,8 @@ struct MockLanguageRuntime : public LanguageRuntime {
 *ast, "TypeWitInt", ast->GetBasicType(lldb::BasicType::eBasicTypeInt),
 "theIntField", LanguageType::eLanguageTypeC_plus_plus);
 class_type_or_name.SetCompilerType(int_type);
-local_buffer = {(uint8_t *)in_value.GetValue().GetScala

[Lldb-commits] [lldb] [lldb][NFC] Replace GetLocalBufferSize() with GetLocalBuffer() (PR #126333)

2025-02-07 Thread Augusto Noronha via lldb-commits

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


[Lldb-commits] [clang] [libc] [libcxx] [lldb] [llvm] [doc] Add Discord invite link alongside channel links (PR #126352)

2025-02-07 Thread Alex Bradbury via lldb-commits

https://github.com/asb created https://github.com/llvm/llvm-project/pull/126352

By far the most important part of this patch is updating GettingInvolved.rst to 
include the invite link, but I've grepped for any other discord.com links.

I'm no Discord expert, but from my experience (confirmed via @preames kindly 
testing as well) the direct channel links provide a confusing experience if you 
haven't already found and used an invite link to the LLVM Discord server. If 
you're logged into Discord, the web app opens and then...nothing. No channel 
opens, no prompt to join the server or even a hint that you need to find an 
invite link (and if you're not used to Discord, you likely don't even know 
that's necessary).

This patch addresses the issue by providing the invite link where Discord is 
mentioned.

>From 446b59bd47eb5356454665eeb82e75a77862350a Mon Sep 17 00:00:00 2001
From: Alex Bradbury 
Date: Sat, 8 Feb 2025 06:27:26 +
Subject: [PATCH] [doc] Add Discord invite link alongside channel links

By far the most important part of this patch is updating
GettingInvolved.rst to include the invite link, but I've grepped for
any other discord.com links.

I'm no Discord expert, but from my experience (confirmed via @preames
kindly testing as well) the direct channel links provide a confusing
experience if you haven't already found and used an invite link to the
LLVM Discord server. If you're logged into Discord, the web app opens
and then...nothing. No prompt to join the server or even a hint that you
need to find an invite link (and if you're not used to Discord, you may
not even know that's necessary).

This patch addresses the issue by providing the invite link where
Discord is mentioned.
---
 clang/www/OpenProjects.html   | 2 +-
 libc/docs/index.rst   | 3 ++-
 libcxx/docs/index.rst | 2 +-
 lldb/docs/index.rst   | 3 ++-
 llvm/docs/GettingInvolved.rst | 2 +-
 5 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/clang/www/OpenProjects.html b/clang/www/OpenProjects.html
index a9efdb8d762d763..6e32488b47b3381 100755
--- a/clang/www/OpenProjects.html
+++ b/clang/www/OpenProjects.html
@@ -149,7 +149,7 @@ Open Clang Projects
 If you hit a bug with Clang, it is very useful for us if you reduce the code
 that demonstrates the problem down to something small. There are many ways to
 do this; ask on https://discourse.llvm.org/c/clang";>Discourse,
-https://discord.com/channels/636084430946959380/636725486533345280";>Discord
+https://discord.gg/xS7Z362";>Discord
 for advice.
 
 
diff --git a/libc/docs/index.rst b/libc/docs/index.rst
index 12dcba27a906bb7..f0e5c9db79b40d3 100644
--- a/libc/docs/index.rst
+++ b/libc/docs/index.rst
@@ -12,7 +12,8 @@ The LLVM C Library
   LLVM-libc is not fully complete right now. Some programs may fail to build 
due
   to missing functions. If you would like to help us finish LLVM-libc, check
   out "`Contributing to the libc project `__" in the sidebar
-  or ask on `discord 
`__.
+  or ask on `discord 
`__
+  (`invite link `__).
 
 Introduction
 
diff --git a/libcxx/docs/index.rst b/libcxx/docs/index.rst
index 37912e9f8d03e6b..53c6b84c22ea7e4 100644
--- a/libcxx/docs/index.rst
+++ b/libcxx/docs/index.rst
@@ -242,5 +242,5 @@ Quick Links
 * `LLVM Bug Tracker `_
 * `libcxx-commits Mailing List 
`_
 * `libc++ forum `_
-* `libc++ chat 
`_
+* `libc++ chat 
`_ (`invite 
link `_)
 * `Browse libc++ Sources 
`_
diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 5686a33e94c9389..1ffdb08a1ca2cfe 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -182,7 +182,8 @@ interesting areas to contribute to lldb.
 
Source Code 
Releases 
-   Discord 
+   Join the Discord 
+   Discord Channel 

Discussion Forums 
Developer Policy 
Bug Reports 

diff --git a/llvm/docs/GettingInvolved.rst b/llvm/docs/GettingInvolved.rst
index 99e8d1e46738483..d3663491766c20b 100644
--- a/llvm/docs/GettingInvolved.rst
+++ b/llvm/docs/GettingInvolved.rst
@@ -392,7 +392,7 @@ Discord
 ---
 
 Users

[Lldb-commits] [clang] [libc] [libcxx] [lldb] [llvm] [doc] Add Discord invite link alongside channel links (PR #126352)

2025-02-07 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-libcxx

Author: Alex Bradbury (asb)


Changes

By far the most important part of this patch is updating GettingInvolved.rst to 
include the invite link, but I've grepped for any other discord.com links.

I'm no Discord expert, but from my experience (confirmed via @preames 
kindly testing as well) the direct channel links provide a confusing experience 
if you haven't already found and used an invite link to the LLVM Discord 
server. If you're logged into Discord, the web app opens and then...nothing. No 
channel opens, no prompt to join the server or even a hint that you need to 
find an invite link (and if you're not used to Discord, you likely don't even 
know that's necessary).

This patch addresses the issue by providing the invite link where Discord is 
mentioned.

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


5 Files Affected:

- (modified) clang/www/OpenProjects.html (+1-1) 
- (modified) libc/docs/index.rst (+2-1) 
- (modified) libcxx/docs/index.rst (+1-1) 
- (modified) lldb/docs/index.rst (+2-1) 
- (modified) llvm/docs/GettingInvolved.rst (+1-1) 


``diff
diff --git a/clang/www/OpenProjects.html b/clang/www/OpenProjects.html
index a9efdb8d762d763..6e32488b47b3381 100755
--- a/clang/www/OpenProjects.html
+++ b/clang/www/OpenProjects.html
@@ -149,7 +149,7 @@ Open Clang Projects
 If you hit a bug with Clang, it is very useful for us if you reduce the code
 that demonstrates the problem down to something small. There are many ways to
 do this; ask on https://discourse.llvm.org/c/clang";>Discourse,
-https://discord.com/channels/636084430946959380/636725486533345280";>Discord
+https://discord.gg/xS7Z362";>Discord
 for advice.
 
 
diff --git a/libc/docs/index.rst b/libc/docs/index.rst
index 12dcba27a906bb7..f0e5c9db79b40d3 100644
--- a/libc/docs/index.rst
+++ b/libc/docs/index.rst
@@ -12,7 +12,8 @@ The LLVM C Library
   LLVM-libc is not fully complete right now. Some programs may fail to build 
due
   to missing functions. If you would like to help us finish LLVM-libc, check
   out "`Contributing to the libc project `__" in the sidebar
-  or ask on `discord 
`__.
+  or ask on `discord 
`__
+  (`invite link `__).
 
 Introduction
 
diff --git a/libcxx/docs/index.rst b/libcxx/docs/index.rst
index 37912e9f8d03e6b..53c6b84c22ea7e4 100644
--- a/libcxx/docs/index.rst
+++ b/libcxx/docs/index.rst
@@ -242,5 +242,5 @@ Quick Links
 * `LLVM Bug Tracker `_
 * `libcxx-commits Mailing List 
`_
 * `libc++ forum `_
-* `libc++ chat 
`_
+* `libc++ chat 
`_ (`invite 
link `_)
 * `Browse libc++ Sources 
`_
diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 5686a33e94c9389..1ffdb08a1ca2cfe 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -182,7 +182,8 @@ interesting areas to contribute to lldb.
 
Source Code 
Releases 
-   Discord 
+   Join the Discord 
+   Discord Channel 

Discussion Forums 
Developer Policy 
Bug Reports 

diff --git a/llvm/docs/GettingInvolved.rst b/llvm/docs/GettingInvolved.rst
index 99e8d1e46738483..d3663491766c20b 100644
--- a/llvm/docs/GettingInvolved.rst
+++ b/llvm/docs/GettingInvolved.rst
@@ -392,7 +392,7 @@ Discord
 ---
 
 Users and developers of the LLVM project (including subprojects such as Clang)
-can be found on the community's `Discord 
`_
+can be found on the community's `Discord `_
 chat server. The server is actively moderated.
 
 The #buildbot-status channel has a bot for

``




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


[Lldb-commits] [clang] [libc] [libcxx] [lldb] [llvm] [doc] Add Discord invite link alongside channel links (PR #126352)

2025-02-07 Thread Alex Bradbury via lldb-commits

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


[Lldb-commits] [clang] [libc] [libcxx] [lldb] [llvm] [doc] Add Discord invite link alongside channel links (PR #126352)

2025-02-07 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-libc

Author: Alex Bradbury (asb)


Changes

By far the most important part of this patch is updating GettingInvolved.rst to 
include the invite link, but I've grepped for any other discord.com links.

I'm no Discord expert, but from my experience (confirmed via @preames 
kindly testing as well) the direct channel links provide a confusing experience 
if you haven't already found and used an invite link to the LLVM Discord 
server. If you're logged into Discord, the web app opens and then...nothing. No 
channel opens, no prompt to join the server or even a hint that you need to 
find an invite link (and if you're not used to Discord, you likely don't even 
know that's necessary).

This patch addresses the issue by providing the invite link where Discord is 
mentioned.

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


5 Files Affected:

- (modified) clang/www/OpenProjects.html (+1-1) 
- (modified) libc/docs/index.rst (+2-1) 
- (modified) libcxx/docs/index.rst (+1-1) 
- (modified) lldb/docs/index.rst (+2-1) 
- (modified) llvm/docs/GettingInvolved.rst (+1-1) 


``diff
diff --git a/clang/www/OpenProjects.html b/clang/www/OpenProjects.html
index a9efdb8d762d763..6e32488b47b3381 100755
--- a/clang/www/OpenProjects.html
+++ b/clang/www/OpenProjects.html
@@ -149,7 +149,7 @@ Open Clang Projects
 If you hit a bug with Clang, it is very useful for us if you reduce the code
 that demonstrates the problem down to something small. There are many ways to
 do this; ask on https://discourse.llvm.org/c/clang";>Discourse,
-https://discord.com/channels/636084430946959380/636725486533345280";>Discord
+https://discord.gg/xS7Z362";>Discord
 for advice.
 
 
diff --git a/libc/docs/index.rst b/libc/docs/index.rst
index 12dcba27a906bb7..f0e5c9db79b40d3 100644
--- a/libc/docs/index.rst
+++ b/libc/docs/index.rst
@@ -12,7 +12,8 @@ The LLVM C Library
   LLVM-libc is not fully complete right now. Some programs may fail to build 
due
   to missing functions. If you would like to help us finish LLVM-libc, check
   out "`Contributing to the libc project `__" in the sidebar
-  or ask on `discord 
`__.
+  or ask on `discord 
`__
+  (`invite link `__).
 
 Introduction
 
diff --git a/libcxx/docs/index.rst b/libcxx/docs/index.rst
index 37912e9f8d03e6b..53c6b84c22ea7e4 100644
--- a/libcxx/docs/index.rst
+++ b/libcxx/docs/index.rst
@@ -242,5 +242,5 @@ Quick Links
 * `LLVM Bug Tracker `_
 * `libcxx-commits Mailing List 
`_
 * `libc++ forum `_
-* `libc++ chat 
`_
+* `libc++ chat 
`_ (`invite 
link `_)
 * `Browse libc++ Sources 
`_
diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 5686a33e94c9389..1ffdb08a1ca2cfe 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -182,7 +182,8 @@ interesting areas to contribute to lldb.
 
Source Code 
Releases 
-   Discord 
+   Join the Discord 
+   Discord Channel 

Discussion Forums 
Developer Policy 
Bug Reports 

diff --git a/llvm/docs/GettingInvolved.rst b/llvm/docs/GettingInvolved.rst
index 99e8d1e46738483..d3663491766c20b 100644
--- a/llvm/docs/GettingInvolved.rst
+++ b/llvm/docs/GettingInvolved.rst
@@ -392,7 +392,7 @@ Discord
 ---
 
 Users and developers of the LLVM project (including subprojects such as Clang)
-can be found on the community's `Discord 
`_
+can be found on the community's `Discord `_
 chat server. The server is actively moderated.
 
 The #buildbot-status channel has a bot for

``




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


[Lldb-commits] [lldb] [lldb] Implement a statusline in LLDB (PR #121860)

2025-02-07 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere updated 
https://github.com/llvm/llvm-project/pull/121860

>From ed0cf2866638162ff7314d31ee8325dc492060dd Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Fri, 17 Jan 2025 17:10:36 -0800
Subject: [PATCH] [lldb] Implement a statusline in LLDB
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Add a statusline to command-line LLDB to display progress events and
other information related to the current state of the debugger. The
statusline is a dedicated area displayed the bottom of the screen. The
contents of the status line are configurable through a setting
consisting of LLDB’s format strings.

The statusline is configurable through the `statusline-format` setting.
The default configuration shows the target name, the current file, the
stop reason and the current progress event.

```
(lldb) settings show statusline-format
statusline-format (format-string) = 
"${ansi.bg.cyan}${ansi.fg.black}{${target.file.basename}}{ | 
${line.file.basename}:${line.number}:${line.column}}{ | ${thread.stop-reason}}{ 
| {${progress.count} }${progress.message}}"
```

The statusline is enabled by default, but can be disabled with the
following setting:

```
(lldb) settings set show-statusline false
```

The statusline supersedes the current progress reporting implementation.
Consequently, the following settings no longer have any effect (but
continue to exist):

```
show-progress -- Whether to show progress or not if the debugger's 
output is an interactive color-enabled terminal.
show-progress-ansi-prefix -- When displaying progress in a color-enabled 
terminal, use the ANSI terminal code specified in this format immediately 
before the progress message.
show-progress-ansi-suffix -- When displaying progress in a color-enabled 
terminal, use the ANSI terminal code specified in this format immediately after 
the progress message.
```

RFC: https://discourse.llvm.org/t/rfc-lldb-statusline/83948
---
 lldb/include/lldb/Core/Debugger.h |  23 ++-
 lldb/include/lldb/Core/FormatEntity.h |   4 +-
 lldb/include/lldb/Core/Statusline.h   |  60 +++
 .../Python/lldbsuite/test/lldbtest.py |   2 +
 lldb/source/Core/CMakeLists.txt   |   1 +
 lldb/source/Core/CoreProperties.td|   8 +
 lldb/source/Core/Debugger.cpp | 157 +
 lldb/source/Core/FormatEntity.cpp |  44 -
 lldb/source/Core/Statusline.cpp   | 160 ++
 .../TestTrimmedProgressReporting.py   |  51 --
 10 files changed, 375 insertions(+), 135 deletions(-)
 create mode 100644 lldb/include/lldb/Core/Statusline.h
 create mode 100644 lldb/source/Core/Statusline.cpp
 delete mode 100644 
lldb/test/API/functionalities/progress_reporting/TestTrimmedProgressReporting.py

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 70f4c4216221c65..716e0e830371d03 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -19,6 +19,7 @@
 #include "lldb/Core/FormatEntity.h"
 #include "lldb/Core/IOHandler.h"
 #include "lldb/Core/SourceManager.h"
+#include "lldb/Core/Statusline.h"
 #include "lldb/Core/UserSettingsController.h"
 #include "lldb/Host/HostThread.h"
 #include "lldb/Host/StreamFile.h"
@@ -308,6 +309,10 @@ class Debugger : public 
std::enable_shared_from_this,
 
   bool SetShowProgress(bool show_progress);
 
+  bool GetShowStatusline() const;
+
+  const FormatEntity::Entry *GetStatuslineFormat() const;
+
   llvm::StringRef GetShowProgressAnsiPrefix() const;
 
   llvm::StringRef GetShowProgressAnsiSuffix() const;
@@ -604,6 +609,14 @@ class Debugger : public 
std::enable_shared_from_this,
 return m_source_file_cache;
   }
 
+  struct ProgressReport {
+uint64_t id;
+uint64_t completed;
+uint64_t total;
+std::string message;
+  };
+  std::optional GetCurrentProgressReport() const;
+
 protected:
   friend class CommandInterpreter;
   friend class REPL;
@@ -653,6 +666,8 @@ class Debugger : public 
std::enable_shared_from_this,
 
   void PrintProgress(const ProgressEventData &data);
 
+  bool StatuslineSupported();
+
   void PushIOHandler(const lldb::IOHandlerSP &reader_sp,
  bool cancel_top_handler = true);
 
@@ -728,7 +743,7 @@ class Debugger : public 
std::enable_shared_from_this,
   IOHandlerStack m_io_handler_stack;
   std::recursive_mutex m_io_handler_synchronous_mutex;
 
-  std::optional m_current_event_id;
+  std::optional m_statusline;
 
   llvm::StringMap> m_stream_handlers;
   std::shared_ptr m_callback_handler_sp;
@@ -745,6 +760,12 @@ class Debugger : public 
std::enable_shared_from_this,
   lldb::TargetSP m_dummy_target_sp;
   Diagnostics::CallbackID m_diagnostics_callback_id;
 
+  /// Bookkeeping for command line progress events.
+  /// @{
+  llvm::SmallVector m_progress_reports;
+  mutable std::mutex m_progress_reports_mutex;
+  /// @}
+
   std::mutex

[Lldb-commits] [lldb] [LLDB][LoongArch] Extend the maximum number of watchpoints (PR #126204)

2025-02-07 Thread Tiezhu Yang via lldb-commits

https://github.com/seehearfeel created 
https://github.com/llvm/llvm-project/pull/126204

The maximum number of load/store watchpoints and fetch instruction
watchpoints is 14 each according to LoongArch Reference Manual [1],
so extend the maximum number of watchpoints from 8 to 14 for ptrace.

A new struct user_watch_state_v2 was added into uapi in the related
kernel commit 531936dee53e ("LoongArch: Extend the maximum number of
watchpoints") [2], but there may be no struct user_watch_state_v2 in
the system header in time.

In order to avoid undefined or redefined error, just add a new struct
loongarch_user_watch_state in LLDB which is same with the uapi struct
user_watch_state_v2, then replace the current user_watch_state with
loongarch_user_watch_state.

As far as I can tell, the only users for this struct in the userspace
are GDB and LLDB, there are no any problems of software compatibility
between the application and kernel according to the analysis.

The compatibility problem has been considered while developing and
testing. When the applications in the userspace get watchpoint state,
the length will be specified which is no bigger than the sizeof struct
user_watch_state or user_watch_state_v2, the actual length is assigned
as the minimal value of the application and kernel in the generic code
of ptrace:

```
kernel/ptrace.c: ptrace_regset():

kiov->iov_len = min(kiov->iov_len,
(__kernel_size_t) (regset->n * regset->size));

if (req == PTRACE_GETREGSET)
return copy_regset_to_user(task, view, regset_no, 0,
   kiov->iov_len, kiov->iov_base);
else
return copy_regset_from_user(task, view, regset_no, 0,
 kiov->iov_len, kiov->iov_base);
```

For example, there are four kind of combinations, all of them work well.

(1) "older kernel + older app", the actual length is 8+(8+8+4+4)*8=200;
(2) "newer kernel + newer app", the actual length is 8+(8+8+4+4)*14=344;
(3) "older kernel + newer app", the actual length is 8+(8+8+4+4)*8=200;
(4) "newer kernel + older app", the actual length is 8+(8+8+4+4)*8=200.

Signed-off-by: Tiezhu Yang \

>From ee852ce4b316b16f7facab42fc3510f0a97242f1 Mon Sep 17 00:00:00 2001
From: Tiezhu Yang 
Date: Fri, 7 Feb 2025 12:09:30 +0800
Subject: [PATCH] [LLDB][LoongArch] Extend the maximum number of watchpoints

The maximum number of load/store watchpoints and fetch instruction
watchpoints is 14 each according to LoongArch Reference Manual [1],
so extend the maximum number of watchpoints from 8 to 14 for ptrace.

A new struct user_watch_state_v2 was added into uapi in the related
kernel commit 531936dee53e ("LoongArch: Extend the maximum number of
watchpoints") [2], but there may be no struct user_watch_state_v2 in
the system header in time.

In order to avoid undefined or redefined error, just add a new struct
loongarch_user_watch_state in LLDB which is same with the uapi struct
user_watch_state_v2, then replace the current user_watch_state with
loongarch_user_watch_state.

As far as I can tell, the only users for this struct in the userspace
are GDB and LLDB, there are no any problems of software compatibility
between the application and kernel according to the analysis.

The compatibility problem has been considered while developing and
testing. When the applications in the userspace get watchpoint state,
the length will be specified which is no bigger than the sizeof struct
user_watch_state or user_watch_state_v2, the actual length is assigned
as the minimal value of the application and kernel in the generic code
of ptrace:

```
kernel/ptrace.c: ptrace_regset():

kiov->iov_len = min(kiov->iov_len,
(__kernel_size_t) (regset->n * regset->size));

if (req == PTRACE_GETREGSET)
return copy_regset_to_user(task, view, regset_no, 0,
   kiov->iov_len, kiov->iov_base);
else
return copy_regset_from_user(task, view, regset_no, 0,
 kiov->iov_len, kiov->iov_base);
```

For example, there are four kind of combinations, all of them work well.

(1) "older kernel + older app", the actual length is 8+(8+8+4+4)*8=200;
(2) "newer kernel + newer app", the actual length is 8+(8+8+4+4)*14=344;
(3) "older kernel + newer app", the actual length is 8+(8+8+4+4)*8=200;
(4) "newer kernel + older app", the actual length is 8+(8+8+4+4)*8=200.

Signed-off-by: Tiezhu Yang 
---
 .../NativeRegisterContextLinux_loongarch64.cpp  | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
index 601dde250094892..c197da595b984f2 100644
--- 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.c

[Lldb-commits] [lldb] [LLDB][LoongArch] Extend the maximum number of watchpoints (PR #126204)

2025-02-07 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Tiezhu Yang (seehearfeel)


Changes

The maximum number of load/store watchpoints and fetch instruction
watchpoints is 14 each according to LoongArch Reference Manual [1],
so extend the maximum number of watchpoints from 8 to 14 for ptrace.

A new struct user_watch_state_v2 was added into uapi in the related
kernel commit 531936dee53e ("LoongArch: Extend the maximum number of
watchpoints") [2], but there may be no struct user_watch_state_v2 in
the system header in time.

In order to avoid undefined or redefined error, just add a new struct
loongarch_user_watch_state in LLDB which is same with the uapi struct
user_watch_state_v2, then replace the current user_watch_state with
loongarch_user_watch_state.

As far as I can tell, the only users for this struct in the userspace
are GDB and LLDB, there are no any problems of software compatibility
between the application and kernel according to the analysis.

The compatibility problem has been considered while developing and
testing. When the applications in the userspace get watchpoint state,
the length will be specified which is no bigger than the sizeof struct
user_watch_state or user_watch_state_v2, the actual length is assigned
as the minimal value of the application and kernel in the generic code
of ptrace:

```
kernel/ptrace.c: ptrace_regset():

kiov->iov_len = min(kiov->iov_len,
(__kernel_size_t) (regset->n * regset->size));

if (req == PTRACE_GETREGSET)
return copy_regset_to_user(task, view, regset_no, 0,
   kiov->iov_len, kiov->iov_base);
else
return copy_regset_from_user(task, view, regset_no, 0,
 kiov->iov_len, 
kiov->iov_base);
```

For example, there are four kind of combinations, all of them work well.

(1) "older kernel + older app", the actual length is 8+(8+8+4+4)*8=200;
(2) "newer kernel + newer app", the actual length is 8+(8+8+4+4)*14=344;
(3) "older kernel + newer app", the actual length is 8+(8+8+4+4)*8=200;
(4) "newer kernel + older app", the actual length is 8+(8+8+4+4)*8=200.

Signed-off-by: Tiezhu Yang \

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


1 Files Affected:

- (modified) 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp 
(+15-2) 


``diff
diff --git 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
index 601dde250094892..c197da595b984f2 100644
--- 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
+++ 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
@@ -50,6 +50,19 @@
 #define REG_CONTEXT_SIZE   
\
   (GetGPRSize() + GetFPRSize() + sizeof(m_lsx) + sizeof(m_lasx))
 
+// In order to avoid undefined or redefined error, just add a new struct
+// loongarch_user_watch_state in LLDB which is same with the uapi struct
+// user_watch_state_v2.
+struct loongarch_user_watch_state {
+  uint64_t dbg_info;
+  struct {
+uint64_t addr;
+uint64_t mask;
+uint32_t ctrl;
+uint32_t pad;
+  } dbg_regs[14];
+};
+
 using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::process_linux;
@@ -539,7 +552,7 @@ llvm::Error 
NativeRegisterContextLinux_loongarch64::ReadHardwareDebugInfo() {
 
   int regset = NT_LOONGARCH_HW_WATCH;
   struct iovec ioVec;
-  struct user_watch_state dreg_state;
+  struct loongarch_user_watch_state dreg_state;
   Status error;
 
   ioVec.iov_base = &dreg_state;
@@ -567,7 +580,7 @@ llvm::Error 
NativeRegisterContextLinux_loongarch64::ReadHardwareDebugInfo() {
 llvm::Error NativeRegisterContextLinux_loongarch64::WriteHardwareDebugRegs(
 DREGType hwbType) {
   struct iovec ioVec;
-  struct user_watch_state dreg_state;
+  struct loongarch_user_watch_state dreg_state;
   int regset;
 
   memset(&dreg_state, 0, sizeof(dreg_state));

``




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


[Lldb-commits] [lldb] [LLDB][LoongArch] Extend the maximum number of watchpoints (PR #126204)

2025-02-07 Thread Tiezhu Yang via lldb-commits

https://github.com/seehearfeel updated 
https://github.com/llvm/llvm-project/pull/126204

>From 7f23aaea0abeafd408fbdd06f1b1a5393860af3a Mon Sep 17 00:00:00 2001
From: Tiezhu Yang 
Date: Fri, 7 Feb 2025 12:09:30 +0800
Subject: [PATCH] [LLDB][LoongArch] Extend the maximum number of watchpoints

The maximum number of load/store watchpoints and fetch instruction
watchpoints is 14 each according to LoongArch Reference Manual [1],
so extend the maximum number of watchpoints from 8 to 14 for ptrace.

A new struct user_watch_state_v2 was added into uapi in the related
kernel commit 531936dee53e ("LoongArch: Extend the maximum number of
watchpoints") [2], but there may be no struct user_watch_state_v2 in
the system header in time.

In order to avoid undefined or redefined error, just add a new struct
loongarch_user_watch_state in LLDB which is same with the uapi struct
user_watch_state_v2, then replace the current user_watch_state with
loongarch_user_watch_state.

As far as I can tell, the only users for this struct in the userspace
are GDB and LLDB, there are no any problems of software compatibility
between the application and kernel according to the analysis.

The compatibility problem has been considered while developing and
testing. When the applications in the userspace get watchpoint state,
the length will be specified which is no bigger than the sizeof struct
user_watch_state or user_watch_state_v2, the actual length is assigned
as the minimal value of the application and kernel in the generic code
of ptrace:

```
kernel/ptrace.c: ptrace_regset():

kiov->iov_len = min(kiov->iov_len,
(__kernel_size_t) (regset->n * regset->size));

if (req == PTRACE_GETREGSET)
return copy_regset_to_user(task, view, regset_no, 0,
   kiov->iov_len, kiov->iov_base);
else
return copy_regset_from_user(task, view, regset_no, 0,
 kiov->iov_len, kiov->iov_base);
```

For example, there are four kind of combinations, all of them work well.

(1) "older kernel + older app", the actual length is 8+(8+8+4+4)*8=200;
(2) "newer kernel + newer app", the actual length is 8+(8+8+4+4)*14=344;
(3) "older kernel + newer app", the actual length is 8+(8+8+4+4)*8=200;
(4) "newer kernel + older app", the actual length is 8+(8+8+4+4)*8=200.

[1] 
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=531936dee53e

Signed-off-by: Tiezhu Yang 
---
 .../NativeRegisterContextLinux_loongarch64.cpp  | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
index 601dde250094892..c197da595b984f2 100644
--- 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
+++ 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
@@ -50,6 +50,19 @@
 #define REG_CONTEXT_SIZE   
\
   (GetGPRSize() + GetFPRSize() + sizeof(m_lsx) + sizeof(m_lasx))
 
+// In order to avoid undefined or redefined error, just add a new struct
+// loongarch_user_watch_state in LLDB which is same with the uapi struct
+// user_watch_state_v2.
+struct loongarch_user_watch_state {
+  uint64_t dbg_info;
+  struct {
+uint64_t addr;
+uint64_t mask;
+uint32_t ctrl;
+uint32_t pad;
+  } dbg_regs[14];
+};
+
 using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::process_linux;
@@ -539,7 +552,7 @@ llvm::Error 
NativeRegisterContextLinux_loongarch64::ReadHardwareDebugInfo() {
 
   int regset = NT_LOONGARCH_HW_WATCH;
   struct iovec ioVec;
-  struct user_watch_state dreg_state;
+  struct loongarch_user_watch_state dreg_state;
   Status error;
 
   ioVec.iov_base = &dreg_state;
@@ -567,7 +580,7 @@ llvm::Error 
NativeRegisterContextLinux_loongarch64::ReadHardwareDebugInfo() {
 llvm::Error NativeRegisterContextLinux_loongarch64::WriteHardwareDebugRegs(
 DREGType hwbType) {
   struct iovec ioVec;
-  struct user_watch_state dreg_state;
+  struct loongarch_user_watch_state dreg_state;
   int regset;
 
   memset(&dreg_state, 0, sizeof(dreg_state));

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


[Lldb-commits] [lldb] [LLDB][LoongArch] Extend the maximum number of watchpoints (PR #126204)

2025-02-07 Thread Tiezhu Yang via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… (PR #125143)

2025-02-07 Thread Dmitry Vasilyev via lldb-commits

slydiman wrote:

Please fix ASAP
https://lab.llvm.org/buildbot/#/builders/197/builds/1717
```
llvm-project/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp(221): 
error C2065: 'u_int8_t': undeclared identifier
```

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


[Lldb-commits] [lldb] [lldb][telemetry] Implement LLDB Telemetry (part 1) (PR #119716)

2025-02-07 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,92 @@
+//===-- Telemetry.cpp 
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+#include "lldb/Core/Telemetry.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Target/Statistics.h"
+#include "lldb/Utility/ConstString.h"
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/UUID.h"
+#include "lldb/Version/Version.h"
+#include "lldb/lldb-enumerations.h"
+#include "lldb/lldb-forward.h"
+#include "llvm/ADT/SmallString.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/Twine.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Support/RandomNumberGenerator.h"
+#include "llvm/Telemetry/Telemetry.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace lldb_private {
+
+using ::llvm::Error;
+using ::llvm::telemetry::Destination;
+using ::llvm::telemetry::TelemetryInfo;
+
+static uint64_t ToNanosec(const SteadyTimePoint Point) {
+  return nanoseconds(Point.value().time_since_epoch()).count();
+}
+
+void LldbBaseTelemetryInfo::serialize(Serializer &serializer) const {
+  serializer.write("entry_kind", getKind());
+  serializer.write("session_id", SessionId);
+  serializer.write("start_time", ToNanosec(stats.start));
+  if (stats.end.has_value())
+serializer.write("end_time", ToNanosec(stats.end.value()));
+  if (exit_desc.has_value()) {
+serializer.write("exit_code", exit_desc->exit_code);
+serializer.write("exit_msg", exit_desc->description);
+  }
+}
+
+static std::string MakeUUID(lldb_private::Debugger *debugger) {
+  std::string ret;
+  uint8_t random_bytes[16];
+  if (auto ec = llvm::getRandomBytes(random_bytes, 16)) {
+LLDB_LOG(GetLog(LLDBLog::Object),
+ "Failed to generate random bytes for UUID: {0}", ec.message());
+// fallback to using timestamp + debugger ID.
+ret = std::to_string(
+  std::chrono::steady_clock::now().time_since_epoch().count()) +
+  "_" + std::to_string(debugger->GetID());
+  } else {
+ret = lldb_private::UUID(random_bytes).GetAsString();
+  }
+
+  return ret;
+}
+
+TelemetryManager::TelemetryManager(
+std::unique_ptr config,
+lldb_private::Debugger *debugger)
+: m_config(std::move(config)), m_debugger(debugger),

labath wrote:

SG

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


[Lldb-commits] [lldb] [lldb][telemetry] Implement LLDB Telemetry (part 1) (PR #119716)

2025-02-07 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,100 @@
+//===-- Telemetry.h --*- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_CORE_TELEMETRY_H
+#define LLDB_CORE_TELEMETRY_H
+
+#include "lldb/Core/StructuredDataImpl.h"
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Utility/StructuredData.h"
+#include "lldb/lldb-forward.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/JSON.h"
+#include "llvm/Telemetry/Telemetry.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace lldb_private {
+
+using llvm::telemetry::Destination;

labath wrote:

Yes, that's what I'd do. Particularly given that this code is going to be 
conditionally compiled, I think it'd be nice to isolate it as much as possible.

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


[Lldb-commits] [lldb] 1608fe8 - [lldb][Breakpoint] Allow whitespace in breakpoint address expression (#126053)

2025-02-07 Thread via lldb-commits

Author: Michael Buch
Date: 2025-02-07T09:27:04Z
New Revision: 1608fe8d56015719d5bf7abca608adad8a866f43

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

LOG: [lldb][Breakpoint] Allow whitespace in breakpoint address expression 
(#126053)

Setting a breakpoint on ` + ` used to work until
`2c76e88e9eb284d17cf409851fb01f1d583bb22a`, where this regex was
reworked. Now we only accept `+ ` or
`+`.

This patch fixes the regression by adding yet another `[[:space:]]*`
component to the regex.

One could probably simplify the regex (or even replace the regex by just
calling the relevent `consumeXXX` APIs on `llvm::StringRef`). Though I
left that for the future.

rdar://130780342

Added: 
lldb/test/Shell/Commands/command-breakpoint-by-addr.test

Modified: 
lldb/source/Interpreter/OptionArgParser.cpp

Removed: 




diff  --git a/lldb/source/Interpreter/OptionArgParser.cpp 
b/lldb/source/Interpreter/OptionArgParser.cpp
index 800f22b6169dc62..2d393a57452ee56 100644
--- a/lldb/source/Interpreter/OptionArgParser.cpp
+++ b/lldb/source/Interpreter/OptionArgParser.cpp
@@ -262,8 +262,10 @@ OptionArgParser::DoToAddress(const ExecutionContext 
*exe_ctx, llvm::StringRef s,
   // 3: The symbol/reg name if there is an offset
   // 4: +/-
   // 5: The offset value.
+  // clang-format off
   static RegularExpression g_symbol_plus_offset_regex(
-  "^(\\$[^ +-]+)|(([^ 
+-]+)([-\\+])[[:space:]]*(0x[0-9A-Fa-f]+|[0-9]+)[[:space:]]*)$");
+  "^(\\$[^ +-]+)|(([^ 
+-]+)[[:space:]]*([-\\+])[[:space:]]*(0x[0-9A-Fa-f]+|[0-9]+)[[:space:]]*)$");
+  // clang-format on
 
   llvm::SmallVector matches;
   if (g_symbol_plus_offset_regex.Execute(sref, &matches)) {

diff  --git a/lldb/test/Shell/Commands/command-breakpoint-by-addr.test 
b/lldb/test/Shell/Commands/command-breakpoint-by-addr.test
new file mode 100644
index 000..0a9dfd916a9c72e
--- /dev/null
+++ b/lldb/test/Shell/Commands/command-breakpoint-by-addr.test
@@ -0,0 +1,14 @@
+# RUN: %clang_host -g -O0 %S/Inputs/main.c -o %t.out
+# RUN: %lldb %t.out -b -s %s | FileCheck %s
+
+breakpoint set -a "main+26"
+breakpoint set -a "main+ 26"
+breakpoint set -a "main +26"
+breakpoint set -a "main + 26"
+breakpoint set -a "main  +26"
+
+# CHECK: Breakpoint 1: address = 
+# CHECK: Breakpoint 2: address = 
+# CHECK: Breakpoint 3: address = 
+# CHECK: Breakpoint 4: address = 
+# CHECK: Breakpoint 5: address = 



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


[Lldb-commits] [lldb] [lldb][Breakpoint] Allow whitespace in breakpoint address expression (PR #126053)

2025-02-07 Thread Michael Buch via lldb-commits

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


[Lldb-commits] [lldb] 7aeae73 - [lldb][TypeSystemClang] Fix typo in assertion

2025-02-07 Thread Michael Buch via lldb-commits

Author: Michael Buch
Date: 2025-02-07T09:30:27Z
New Revision: 7aeae7379d430404499f2929ffeea9416575a091

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

LOG: [lldb][TypeSystemClang] Fix typo in assertion

This was meant to assert that we have the same number of names as we do
formal parameter types (since callers of this API rely on this being true).

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 05625925d7cae37..39296ba5b437fe6 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -3190,7 +3190,7 @@ void DWARFASTParserClang::ParseChildParameters(
 }
   }
 
-  assert(function_param_names.size() == function_param_names.size());
+  assert(function_param_names.size() == function_param_types.size());
 }
 
 clang::Decl *DWARFASTParserClang::GetClangDeclForDIE(const DWARFDIE &die) {



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


[Lldb-commits] [lldb] [LLDB][LoongArch] Extend the maximum number of watchpoints (PR #126204)

2025-02-07 Thread David Spickett via lldb-commits

DavidSpickett wrote:

Thanks for the clear explanation. Part of my confusion before was that I 
mistakenly thought that the v2 struct added a padding field but this is not 
correct. The only thing that has changed is the number of debug regs.

We send one `user_watch_state` to the kernel, but in v2 this may contain 14 
instead of 8. This is a common technique I've also seen it done on AArch64 for 
expanding register sets.

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


[Lldb-commits] [lldb] [LLDB][LoongArch] Extend the maximum number of watchpoints (PR #126204)

2025-02-07 Thread David Spickett via lldb-commits


@@ -50,6 +50,19 @@
 #define REG_CONTEXT_SIZE   
\
   (GetGPRSize() + GetFPRSize() + sizeof(m_lsx) + sizeof(m_lasx))
 
+// In order to avoid undefined or redefined error, just add a new struct
+// loongarch_user_watch_state in LLDB which is same with the uapi struct
+// user_watch_state_v2.

DavidSpickett wrote:

This should reference `user_watch_state` version 1 and say that all that 
changed is the size of dbg_regs. Something like:
```
// ptrace has a type user_watch_state, which was replaced by 
user_watch_state_v2 when more watchpoints
// were added. So this file may be built on systems with one or both in the 
headers. The type below has the same
// layout as user_watch_v2 but will not clash with that name if it exists. We 
can use the v2 layout even on old
// kernels as we will only see 8 watchpoints and the kernel will truncate any 
extra data we send to it.
```

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


[Lldb-commits] [lldb] [llvm] [lldb] Extended if conditions to support alias names for registers (PR #124475)

2025-02-07 Thread via lldb-commits

kper wrote:

Thank you for detailed explanations and sorry for the delay.
I needed almost a week to fix the cross compiling for the lldb-server. FYI, it 
wanted to link the X86's libxml2 with RISCV which didn't work. Also the CMake 
flag for disabling libxml2 didn't work for me.
I deinstalled the dependency and then it worked but it took a week.

I think, I've got the setup now. But I am still struggling to test this 
particular test.

How far I have got:

(RISCV lldb-server)

```
cmake -S llvm -B build -G Ninja \
  -DCMAKE_BUILD_TYPE=MinSizeRel \
  -DLLVM_ENABLE_PROJECTS="clang;lld;lldb" \
  -DCMAKE_SYSTEM_NAME=Linux \
  -DCMAKE_SYSTEM_PROCESSOR=RISCV \
  -DCMAKE_C_COMPILER=riscv64-linux-gnu-gcc \
  -DCMAKE_CXX_COMPILER=riscv64-linux-gnu-g++ \
  -DLLVM_HOST_TRIPLE=riscv64-unknown-linux-gnu \
  -DLLVM_ENABLE_LIBXML2=0 \
  -DLLVM_ENABLE_TERMINFO=0 \
  -DLLDB_ENABLE_PYTHON=0 \
  -DLLDB_ENABLE_LIBEDIT=0 \
  -DLLDB_ENABLE_CURSES=0
```

(X86 lldb)

```
cmake -S llvm -B build -G Ninja -DCMAKE_BUILD_TYPE=MinSizeRel 
-DLLVM_ENABLE_PROJECTS="lldb;clang;lld" -DLLVM_CCACHE_BUILD=1 
-DCMAKE_C_COMPILER_LAUNCHER=sccache -DCMAKE_CXX_COMPILER_LAUNCHER=sccache 
-DLLVM_TARGETS_TO_BUILD="X86"  -DLLDB_ENABLE_PYTHON=ON
```

(Qemu)

You would need a debian image setup for that.

```
qemu-system-riscv64 \
-machine virt \
-cpu rv64 \
-m 2G \
-device virtio-blk-device,drive=hd \
-drive file=overlay.qcow2,if=none,id=hd \
-device virtio-net-device,netdev=net \
-netdev 
user,id=net,hostfwd=tcp::-:22,hostfwd=tcp::-:,hostfwd=tcp::1-:1
 \
-bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf \
-kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf \
-object rng-random,filename=/dev/urandom,id=rng \
-device virtio-rng-device,rng=rng \
-append "root=LABEL=rootfs console=ttyS0" \
-nographic \
-drive file=persistent_disk.qcow2,if=none,id=hd1 \
-device virtio-blk-device,drive=hd1
```

In the Qemu guest, I run the following command. I also receive "Connection 
established" so networking seems to work.

```
./lldb-server platform --server --listen 0.0.0.0: --gdbserver 1
```

(On the host X86)

```
./lldb-dotest --platform-name remote-linux --arch riscv --arch riscv64 
--compiler riscv64-linux-gnu-gcc --platform-url connect://localhost: -p 
riscv64-gp-read
```

The last piece of the puzzle is not working for me because it tells me that 
there are no matching tests. Could you tell me how to do this?

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


[Lldb-commits] [lldb] [LLDB][LoongArch] Extend the maximum number of watchpoints (PR #126204)

2025-02-07 Thread David Spickett via lldb-commits

DavidSpickett wrote:

LGTM, but @SixWeining for the final approval as the arch expert.

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


[Lldb-commits] [lldb] [LLDB][LoongArch] Extend the maximum number of watchpoints (PR #126204)

2025-02-07 Thread Tiezhu Yang via lldb-commits


@@ -50,6 +50,19 @@
 #define REG_CONTEXT_SIZE   
\
   (GetGPRSize() + GetFPRSize() + sizeof(m_lsx) + sizeof(m_lasx))
 
+// In order to avoid undefined or redefined error, just add a new struct
+// loongarch_user_watch_state in LLDB which is same with the uapi struct
+// user_watch_state_v2.

seehearfeel wrote:

OK, let me update it.

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


[Lldb-commits] [lldb] [LLDB][LoongArch] Extend the maximum number of watchpoints (PR #126204)

2025-02-07 Thread Tiezhu Yang via lldb-commits

https://github.com/seehearfeel updated 
https://github.com/llvm/llvm-project/pull/126204

>From d813d794f15b66f9f2036692cc99c241a365046d Mon Sep 17 00:00:00 2001
From: Tiezhu Yang 
Date: Fri, 7 Feb 2025 12:09:30 +0800
Subject: [PATCH] [LLDB][LoongArch] Extend the maximum number of watchpoints

The maximum number of load/store watchpoints and fetch instruction
watchpoints is 14 each according to LoongArch Reference Manual [1],
so extend the maximum number of watchpoints from 8 to 14 for ptrace.

A new struct user_watch_state_v2 was added into uapi in the related
kernel commit 531936dee53e ("LoongArch: Extend the maximum number of
watchpoints") [2], but there may be no struct user_watch_state_v2 in
the system header in time.

In order to avoid undefined or redefined error, just add a new struct
loongarch_user_watch_state in LLDB which is same with the uapi struct
user_watch_state_v2, then replace the current user_watch_state with
loongarch_user_watch_state.

As far as I can tell, the only users for this struct in the userspace
are GDB and LLDB, there are no any problems of software compatibility
between the application and kernel according to the analysis.

The compatibility problem has been considered while developing and
testing. When the applications in the userspace get watchpoint state,
the length will be specified which is no bigger than the sizeof struct
user_watch_state or user_watch_state_v2, the actual length is assigned
as the minimal value of the application and kernel in the generic code
of ptrace:

```
kernel/ptrace.c: ptrace_regset():

kiov->iov_len = min(kiov->iov_len,
(__kernel_size_t) (regset->n * regset->size));

if (req == PTRACE_GETREGSET)
return copy_regset_to_user(task, view, regset_no, 0,
   kiov->iov_len, kiov->iov_base);
else
return copy_regset_from_user(task, view, regset_no, 0,
 kiov->iov_len, kiov->iov_base);
```

For example, there are four kind of combinations, all of them work well.

(1) "older kernel + older app", the actual length is 8+(8+8+4+4)*8=200;
(2) "newer kernel + newer app", the actual length is 8+(8+8+4+4)*14=344;
(3) "older kernel + newer app", the actual length is 8+(8+8+4+4)*8=200;
(4) "newer kernel + older app", the actual length is 8+(8+8+4+4)*8=200.

[1] 
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=531936dee53e

Signed-off-by: Tiezhu Yang 
---
 ...NativeRegisterContextLinux_loongarch64.cpp | 21 +--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
index 601dde250094892..c4841950f1e07c9 100644
--- 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
+++ 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
@@ -50,6 +50,23 @@
 #define REG_CONTEXT_SIZE   
\
   (GetGPRSize() + GetFPRSize() + sizeof(m_lsx) + sizeof(m_lasx))
 
+// ptrace has a struct type user_watch_state, which was replaced by
+// user_watch_state_v2 when more watchpoints were added, so this file
+// may be built on systems with one or both in the system headers.
+// The type below has the same layout as user_watch_state_v2 but will
+// not clash with that name if it exists. We can use the v2 layout even
+// on old kernels as we will only see 8 watchpoints and the kernel will
+// truncate any extra data we send to it.
+struct loongarch_user_watch_state {
+  uint64_t dbg_info;
+  struct {
+uint64_t addr;
+uint64_t mask;
+uint32_t ctrl;
+uint32_t pad;
+  } dbg_regs[14];
+};
+
 using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::process_linux;
@@ -539,7 +556,7 @@ llvm::Error 
NativeRegisterContextLinux_loongarch64::ReadHardwareDebugInfo() {
 
   int regset = NT_LOONGARCH_HW_WATCH;
   struct iovec ioVec;
-  struct user_watch_state dreg_state;
+  struct loongarch_user_watch_state dreg_state;
   Status error;
 
   ioVec.iov_base = &dreg_state;
@@ -567,7 +584,7 @@ llvm::Error 
NativeRegisterContextLinux_loongarch64::ReadHardwareDebugInfo() {
 llvm::Error NativeRegisterContextLinux_loongarch64::WriteHardwareDebugRegs(
 DREGType hwbType) {
   struct iovec ioVec;
-  struct user_watch_state dreg_state;
+  struct loongarch_user_watch_state dreg_state;
   int regset;
 
   memset(&dreg_state, 0, sizeof(dreg_state));

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


[Lldb-commits] [clang] [lldb] [lldb][TypeSystemClang] Initialize ClassTemplateSpecializationDecl's StrictPackMatch field (PR #126215)

2025-02-07 Thread Michael Buch via lldb-commits

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


[Lldb-commits] [clang] [lldb] [lldb][TypeSystemClang] Initialize ClassTemplateSpecializationDecl's StrictPackMatch field (PR #126215)

2025-02-07 Thread LLVM Continuous Integration via lldb-commits

llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder `llvm-clang-aarch64-darwin` 
running on `doug-worker-5` while building `clang,lldb` at step 6 
"test-build-unified-tree-check-all".

Full details are available at: 
https://lab.llvm.org/buildbot/#/builders/190/builds/14274


Here is the relevant piece of the build log for the reference

```
Step 6 (test-build-unified-tree-check-all) failure: test (failure)
 TEST 'Clang :: Analysis/live-stmts.cpp' FAILED 

Exit Code: 1

Command Output (stderr):
--
RUN: at line 1: /Users/buildbot/buildbot-root/aarch64-darwin/build/bin/clang 
-cc1 -internal-isystem 
/Users/buildbot/buildbot-root/aarch64-darwin/build/lib/clang/21/include 
-nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -w 
-analyzer-checker=debug.DumpLiveExprs 
/Users/buildbot/buildbot-root/aarch64-darwin/llvm-project/clang/test/Analysis/live-stmts.cpp
 2>&1   | /Users/buildbot/buildbot-root/aarch64-darwin/build/bin/FileCheck 
/Users/buildbot/buildbot-root/aarch64-darwin/llvm-project/clang/test/Analysis/live-stmts.cpp
+ /Users/buildbot/buildbot-root/aarch64-darwin/build/bin/clang -cc1 
-internal-isystem 
/Users/buildbot/buildbot-root/aarch64-darwin/build/lib/clang/21/include 
-nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -w 
-analyzer-checker=debug.DumpLiveExprs 
/Users/buildbot/buildbot-root/aarch64-darwin/llvm-project/clang/test/Analysis/live-stmts.cpp
+ /Users/buildbot/buildbot-root/aarch64-darwin/build/bin/FileCheck 
/Users/buildbot/buildbot-root/aarch64-darwin/llvm-project/clang/test/Analysis/live-stmts.cpp
/Users/buildbot/buildbot-root/aarch64-darwin/llvm-project/clang/test/Analysis/live-stmts.cpp:239:16:
 error: CHECK-EMPTY: is not on the line after the previous 
match
// CHECK-EMPTY:
   ^
:180:1: note: 'next' match was here

^
:177:1: note: previous match ended here

^
:178:1: note: non-matching line after 
previous match is here
ImplicitCastExpr 0x12c8a1178 '_Bool' 
^

Input file: 
Check file: 
/Users/buildbot/buildbot-root/aarch64-darwin/llvm-project/clang/test/Analysis/live-stmts.cpp

-dump-input=help explains the following input dump.

Input was:
<<
   1:  
   2: [ B0 (live expressions at block 
exit) ] 
check:21  ^~~
   3:  
empty:22  ^
   4:  
empty:23  ^
   5: [ B1 (live expressions at block 
exit) ] 
check:24  ^~~
   6:  
empty:25  ^
   7:  
empty:26  ^
   8: [ B2 (live expressions at block 
exit) ] 
check:27  ^~~
   9:  
empty:28  ^
  10: DeclRefExpr 0x12c89dee0 'int' 
lvalue ParmVar 0x12c882070 'y' 'int' 
next:29   
^~
  11:  
empty:30  ^
  12: DeclRefExpr 0x12c89df00 'int' 
lvalue ParmVar 0x12c8820f0 'z' 'int' 
...

```



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


[Lldb-commits] [lldb] 83ba374 - [lldb] Clear cached unwind plans when adding symbols (#125839)

2025-02-07 Thread via lldb-commits

Author: Pavel Labath
Date: 2025-02-07T12:52:21+01:00
New Revision: 83ba3740bf51347307494d013099e392c310e32b

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

LOG: [lldb] Clear cached unwind plans when adding symbols (#125839)

PR #86603 broke unwinding in for unwind info added via "target symbols
add". #86770 attempted to fix this, but the fix was only partial -- it
accepted new sources of unwind information, but didn't take into account
that the symbol file can alter what lldb percieves as function
boundaries.

A stripped file will not contain information about private
(non-exported) symbols, which will make the public symbols appear very
large. If lldb tries to unwind from such a function before symbols are
added, then the cached unwind plan will prevent new (correct) unwind
plans from being created.

target-symbols-add-unwind.test might have caught this, were it not for
the fact that the "image show-unwind" command does *not* use cached
unwind information (it recomputes it from scratch).

The changes in this patch come in three pieces:
- Clear cached unwind plans when adding symbols. Since the symbol
boundaries can change, we cannot trust anything we've computed
previously.
- Add a flag to "image show-unwind" to display the cached unwind
information (mainly for the use in the test, but I think it's also
generally useful).
- Rewrite the test to better and more reliably simulate the real-world
scenario: I've swapped the running process for a core (minidump) file so
it can run anywhere; used the caching version of the show-unwind
command; and swapped C for assembly to better control the placement of
symbols

Added: 


Modified: 
lldb/include/lldb/Symbol/UnwindTable.h
lldb/source/Commands/CommandObjectTarget.cpp
lldb/source/Commands/Options.td
lldb/source/Symbol/UnwindTable.cpp
lldb/test/Shell/SymbolFile/target-symbols-add-unwind.test

Removed: 
lldb/test/Shell/SymbolFile/Inputs/target-symbols-add-unwind.c



diff  --git a/lldb/include/lldb/Symbol/UnwindTable.h 
b/lldb/include/lldb/Symbol/UnwindTable.h
index 29b7fa61b4849e0..3166fdec6ebaa77 100644
--- a/lldb/include/lldb/Symbol/UnwindTable.h
+++ b/lldb/include/lldb/Symbol/UnwindTable.h
@@ -38,8 +38,9 @@ class UnwindTable {
   ArmUnwindInfo *GetArmUnwindInfo();
   SymbolFile *GetSymbolFile();
 
-  lldb::FuncUnwindersSP GetFuncUnwindersContainingAddress(const Address &addr,
-  SymbolContext &sc);
+  lldb::FuncUnwindersSP
+  GetFuncUnwindersContainingAddress(const Address &addr,
+const SymbolContext &sc);
 
   bool GetAllowAssemblyEmulationUnwindPlans();
 

diff  --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index d0092c237b4c963..da50fe04fa2b60d 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -3474,6 +3474,17 @@ class CommandObjectTargetModulesShowUnwind : public 
CommandObjectParsed {
 m_type = eLookupTypeFunctionOrSymbol;
 break;
 
+  case 'c':
+bool value, success;
+value = OptionArgParser::ToBoolean(option_arg, false, &success);
+if (success) {
+  m_cached = value;
+} else {
+  return Status::FromErrorStringWithFormatv(
+  "invalid boolean value '%s' passed for -c option", option_arg);
+}
+break;
+
   default:
 llvm_unreachable("Unimplemented option");
   }
@@ -3485,6 +3496,7 @@ class CommandObjectTargetModulesShowUnwind : public 
CommandObjectParsed {
   m_type = eLookupTypeInvalid;
   m_str.clear();
   m_addr = LLDB_INVALID_ADDRESS;
+  m_cached = false;
 }
 
 llvm::ArrayRef GetDefinitions() override {
@@ -3497,6 +3509,7 @@ class CommandObjectTargetModulesShowUnwind : public 
CommandObjectParsed {
  // parsing options
 std::string m_str; // Holds name lookup
 lldb::addr_t m_addr = LLDB_INVALID_ADDRESS; // Holds the address to lookup
+bool m_cached = true;
   };
 
   CommandObjectTargetModulesShowUnwind(CommandInterpreter &interpreter)
@@ -3583,9 +3596,12 @@ class CommandObjectTargetModulesShowUnwind : public 
CommandObjectParsed {
   if (abi)
 start_addr = abi->FixCodeAddress(start_addr);
 
-  FuncUnwindersSP func_unwinders_sp(
-  sc.module_sp->GetUnwindTable()
-  .GetUncachedFuncUnwindersContainingAddress(start_addr, sc));
+  UnwindTable &uw_table = sc.module_sp->GetUnwindTable();
+  FuncUnwindersSP func_unwinders_sp =
+  m_options.m_cached
+  ? uw_table.GetFuncUnwindersContainingAddress(start_addr, sc)
+  : uw_table.GetUncachedFuncUnwindersContai

[Lldb-commits] [lldb] [lldb] Clear cached unwind plans when adding symbols (PR #125839)

2025-02-07 Thread Pavel Labath via lldb-commits

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


[Lldb-commits] [lldb] c269182 - [lldb][TypeSystemClang] Initialize ClassTemplateSpecializationDecl's StrictPackMatch field (#126215)

2025-02-07 Thread via lldb-commits

Author: Michael Buch
Date: 2025-02-07T11:10:09Z
New Revision: c269182b13abddc459820e57a4d2065f364b23dc

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

LOG: [lldb][TypeSystemClang] Initialize ClassTemplateSpecializationDecl's 
StrictPackMatch field (#126215)

This addresses the MSAN failure reported
in
https://github.com/llvm/llvm-project/pull/125791#issuecomment-2639183154:
```
==5633==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 in 
clang::ASTNodeImporter::CallOverloadedCreateFun::operator()
#1 in bool clang::ASTNodeImporter::GetImportedOrCreateSpecialDecl<...>
...
```

The ASTImporter reads `D->hasStrictPackMatch()` and forwards it to the
constructor of the destination `ClassTemplateSpecializationDecl`. But if
`D` is a decl that LLDB created from debug-info, it would've been
created using `ClassTemplateSpecializationDecl::CreateDeserialized`,
which doesn't initialize the `StrictPackMatch` field.

This patch just initializes the field to a fixed value of `false`, to
preserve previous behaviour and avoid the use-of-uninitialized-value.

An alternative would be to always initialize it in the
`ClassTemplateSpecializationDecl` constructor, but there were
reservations about providing a default value for it because it might
lead to hard-to-diagnose problems down the line.

Added: 


Modified: 
clang/include/clang/AST/DeclTemplate.h
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Removed: 




diff  --git a/clang/include/clang/AST/DeclTemplate.h 
b/clang/include/clang/AST/DeclTemplate.h
index a30ae798a99bc69..b82f75dd63fa508 100644
--- a/clang/include/clang/AST/DeclTemplate.h
+++ b/clang/include/clang/AST/DeclTemplate.h
@@ -1960,6 +1960,8 @@ class ClassTemplateSpecializationDecl : public 
CXXRecordDecl,
 
   bool hasStrictPackMatch() const { return StrictPackMatch; }
 
+  void setStrictPackMatch(bool Val) { StrictPackMatch = Val; }
+
   /// Get the point of instantiation (if any), or null if none.
   SourceLocation getPointOfInstantiation() const {
 return PointOfInstantiation;

diff  --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 1da8fbe0bcd6dda..ecb571b1161bbc6 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -1666,6 +1666,12 @@ TypeSystemClang::CreateClassTemplateSpecializationDecl(
   ast.getTypeDeclType(class_template_specialization_decl, nullptr);
   class_template_specialization_decl->setDeclName(
   class_template_decl->getDeclName());
+
+  // FIXME: set to fixed value for now so it's not uninitialized.
+  // One way to determine StrictPackMatch would be
+  // Sema::CheckTemplateTemplateArgument.
+  class_template_specialization_decl->setStrictPackMatch(false);
+
   SetOwningModule(class_template_specialization_decl, owning_module);
   decl_ctx->addDecl(class_template_specialization_decl);
 



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


[Lldb-commits] [clang] [lldb] [lldb][TypeSystemClang] Initialize ClassTemplateSpecializationDecl's StrictPackMatch field (PR #126215)

2025-02-07 Thread via lldb-commits

llvmbot wrote:



@llvm/pr-subscribers-lldb

@llvm/pr-subscribers-clang

Author: Michael Buch (Michael137)


Changes

This addresses the MSAN failure reported
in https://github.com/llvm/llvm-project/pull/125791#issuecomment-2639183154:
```
==5633==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 in 
clang::ASTNodeImporter::CallOverloadedCreateFun::operator()
#1 in bool 
clang::ASTNodeImporter::GetImportedOrCreateSpecialDecl<...>
...
```

The ASTImporter reads `D->hasStrictPackMatch()` and forwards it to the 
constructor of the destination `ClassTemplateSpecializationDecl`. But if `D` is 
a decl that LLDB created from debug-info, it would've been created using 
`ClassTemplateSpecializationDecl::CreateDeserialized`, which doesn't initialize 
the `StrictPackMatch` field.

This patch just initializes the field to a fixed value of `false`, to preserve 
previous behaviour and avoid the use-of-uninitialized-value.

An alternative would be to always initialize it in the 
`ClassTemplateSpecializationDecl` constructor, but there were reservations 
about providing a default value for it because it might lead to 
hard-to-diagnose problems down the line.

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


2 Files Affected:

- (modified) clang/include/clang/AST/DeclTemplate.h (+2) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp (+6) 


``diff
diff --git a/clang/include/clang/AST/DeclTemplate.h 
b/clang/include/clang/AST/DeclTemplate.h
index a30ae798a99bc69..b82f75dd63fa508 100644
--- a/clang/include/clang/AST/DeclTemplate.h
+++ b/clang/include/clang/AST/DeclTemplate.h
@@ -1960,6 +1960,8 @@ class ClassTemplateSpecializationDecl : public 
CXXRecordDecl,
 
   bool hasStrictPackMatch() const { return StrictPackMatch; }
 
+  void setStrictPackMatch(bool Val) { StrictPackMatch = Val; }
+
   /// Get the point of instantiation (if any), or null if none.
   SourceLocation getPointOfInstantiation() const {
 return PointOfInstantiation;
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 1da8fbe0bcd6dda..ecb571b1161bbc6 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -1666,6 +1666,12 @@ TypeSystemClang::CreateClassTemplateSpecializationDecl(
   ast.getTypeDeclType(class_template_specialization_decl, nullptr);
   class_template_specialization_decl->setDeclName(
   class_template_decl->getDeclName());
+
+  // FIXME: set to fixed value for now so it's not uninitialized.
+  // One way to determine StrictPackMatch would be
+  // Sema::CheckTemplateTemplateArgument.
+  class_template_specialization_decl->setStrictPackMatch(false);
+
   SetOwningModule(class_template_specialization_decl, owning_module);
   decl_ctx->addDecl(class_template_specialization_decl);
 

``




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


[Lldb-commits] [lldb] [lldb][telemetry] Implement LLDB Telemetry (part 1) (PR #119716)

2025-02-07 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,93 @@
+//===-- Telemetry.h --*- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_CORE_TELEMETRY_H
+#define LLDB_CORE_TELEMETRY_H
+
+#include "lldb/Core/StructuredDataImpl.h"
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Utility/StructuredData.h"
+#include "lldb/lldb-forward.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/JSON.h"
+#include "llvm/Telemetry/Telemetry.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace lldb_private {
+
+struct LldbEntryKind : public ::llvm::telemetry::EntryKind {
+  static const llvm::telemetry::KindType BaseInfo = 0b11000;
+};
+
+/// Defines a convenient type for timestamp of various events.
+/// This is used by the EventStats below.
+using SteadyTimePoint = std::chrono::time_point;
+
+/// Various time (and possibly memory) statistics of an event.
+struct EventStats {
+  // REQUIRED: Start time of an event
+  SteadyTimePoint start;
+  // OPTIONAL: End time of an event - may be empty if not meaningful.
+  std::optional end;
+  // TBD: could add some memory stats here too?
+
+  EventStats() = default;
+  EventStats(SteadyTimePoint start) : start(start) {}
+  EventStats(SteadyTimePoint start, SteadyTimePoint end)
+  : start(start), end(end) {}
+};
+
+/// Describes the exit signal of an event.

labath wrote:

I'm going to go with Jonas here. "Signal" is a very confusing word here, 
because a process can die from a (unix) signal (but lldb doesn't do a very good 
job of differentiating the "death by signal N" and "exit with status N"

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


[Lldb-commits] [lldb] [llvm] [lldb] Extended if conditions to support alias names for registers (PR #124475)

2025-02-07 Thread David Spickett via lldb-commits

DavidSpickett wrote:

> FYI, it wanted to link the X86's libxml2 with RISCV which didn't work.

This is known, from the cross building doc:
```
If you find that CMake is finding a version of an optional dependency that for 
whatever reason doesn’t work, consider simply disabling it if you don’t know 
that you need it.
```
But...

> Also the CMake flag for disabling libxml2 didn't work for me.

That should have been the workaround for you. =OFF should stop CMake looking 
for it at all. It might be solved by completely cleaning the build directory, 
but equally we could be caching the variable incorrectly.

If you are on Ubuntu/Debian, you can install the multiarch packages for these 
things. I did this to test s390x in the past.

> The last piece of the puzzle is not working for me because it tells me that 
> there are no matching tests. Could you tell me how to do this?

Sorry, I forgot that this is a shell test not an API test. I'm not sure if you 
can run those using dotest, normally on host you'd use llvm-lit for them like:
```
./bin/llvm-lit ../llvm-project//test_file
```
That might work, but if not, they will be run from `ninja check-lldb-shell`.

Either way you'll need to set the variables shown in the note at the bottom of 
https://lldb.llvm.org/resources/test.html#running-the-test-suite-remotely.

The bot I linked to does this:
```
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER_LAUNCHER=ccache 
-DCMAKE_CXX_COMPILER_LAUNCHER=ccache -DCMAKE_CXX_FLAGS=-D__OPTIMIZE__ 
-DLLVM_TARGETS_TO_BUILD=AArch64 -DLLVM_TARGET_TRIPLE=aarch64-unknown-linux-gnu 
-DLLVM_INCLUDE_BENCHMARKS=OFF -DLLVM_PARALLEL_LINK_JOBS=8 
-DCLANG_DEFAULT_LINKER=lld '-DLLVM_LIT_ARGS=-v -vv --threads=8 --time-tests' 
-DTOOLCHAIN_TARGET_TRIPLE=aarch64-unknown-linux-gnu 
-DTOOLCHAIN_TARGET_COMPILER_FLAGS=-mcpu=cortex-a78 
-DTOOLCHAIN_TARGET_SYSROOTFS=/mnt/fs/jetson-agx-ubuntu -DLIBCXX_ABI_VERSION=1 
-DLLVM_INSTALL_TOOLCHAIN_ONLY=OFF -DLLDB_TEST_ARCH=aarch64 
-DLLDB_TEST_COMPILER=/home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/build/bin/clang
 -DLLDB_TEST_PLATFORM_URL=connect://jetson-agx-2198.lab.llvm.org:1234 
-DLLDB_TEST_PLATFORM_WORKING_DIR=/home/ubuntu/lldb-tests 
-DLLDB_TEST_SYSROOT=/mnt/fs/jetson-agx-ubuntu -DLLDB_ENABLE_PYTHON=ON 
-DLLDB_ENABLE_SWIG=ON -DLLDB_ENABLE_LIBEDIT=OFF -DLLDB_ENABLE_CURSES=OFF 
-DLLDB_ENABLE_LZMA=OFF -DLLDB_ENABLE_LIBXML2=OFF -DLLDB_CAN_USE_LLDB_SERVER=OFF 
'-DLLDB_TEST_USER_ARGS=--env;ARCH_CFLAGS=-mcpu=cortex-a78;--platform-name;remote-linux;--skip-category=lldb-server'
 '-DLLVM_ENABLE_PROJECTS=clang;lld;lldb;llvm' -DCMAKE_INSTALL_PREFIX=../native 
-DLLVM_ENABLE_ASSERTIONS=ON -C 
../llvm-project/clang/cmake/caches/CrossWinToARMLinux.cmake ../llvm-project/llvm
```
**-DLLDB_TEST_SYSROOT=/mnt/fs/jetson-agx-ubuntu**

Sysroots are typically the parent folder of the compiler binaries, if it's a 
separate download, not sure what it will be if it's an apt installed version. 
Perhaps `/usr/something/riscv64`.

...also side note if you do manage to get `check-llvm` working remotely it 
would be great to see what the state of the test suite is so we can set 
expectations for future contributors (in the absence of regular bots).

If you don't give up after slogging through all these steps that is :) Thanks 
for sticking with us.

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


[Lldb-commits] [clang] [lldb] [lldb][TypeSystemClang] Initialize ClassTemplateSpecializationDecl's StrictPackMatch field (PR #126215)

2025-02-07 Thread Haojian Wu via lldb-commits

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

Thank you!

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


[Lldb-commits] [lldb] [lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… (PR #125143)

2025-02-07 Thread David Spickett via lldb-commits

DavidSpickett wrote:

https://github.com/llvm/llvm-project/commit/9d83790d170cc0a06179514e2ab739f7ecafb78c
https://github.com/llvm/llvm-project/commit/52db30ec4154b0ef21db546ed9b5a9bfe47859cd

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


[Lldb-commits] [lldb] [lldb] Clear cached unwind plans when adding symbols (PR #125839)

2025-02-07 Thread Pavel Labath via lldb-commits


@@ -3494,6 +3506,7 @@ class CommandObjectTargetModulesShowUnwind : public 
CommandObjectParsed {
  // parsing options
 std::string m_str; // Holds name lookup
 lldb::addr_t m_addr = LLDB_INVALID_ADDRESS; // Holds the address to lookup
+bool m_cached = false;

labath wrote:

I may be biased because this is the second time that the command has lied to me 
(the first time being when the propeller thingy caused a huge unwind plan 
covering the whole file to be inserted into the cache), but I think this would 
be a better default. I'll flip the flag here. Thanks.

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


[Lldb-commits] [lldb] Reland "[lldb] Implement basic support for reverse-continue" (#123906)" (PR #123945)

2025-02-07 Thread Robert O'Callahan via lldb-commits

rocallahan wrote:

@adrian-prantl can we have that help please?
Also, is that link supposed to be accessible to the public? Because it's 404 
for me.

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


[Lldb-commits] [clang] [lldb] [lldb][TypeSystemClang] Initialize ClassTemplateSpecializationDecl's StrictPackMatch field (PR #126215)

2025-02-07 Thread Matheus Izvekov via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb][telemetry] Implement LLDB Telemetry (part 1) (PR #119716)

2025-02-07 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,93 @@
+//===-- Telemetry.h --*- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_CORE_TELEMETRY_H
+#define LLDB_CORE_TELEMETRY_H
+
+#include "lldb/Core/StructuredDataImpl.h"
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Utility/StructuredData.h"
+#include "lldb/lldb-forward.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/JSON.h"
+#include "llvm/Telemetry/Telemetry.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace lldb_private {
+
+struct LldbEntryKind : public ::llvm::telemetry::EntryKind {
+  static const llvm::telemetry::KindType BaseInfo = 0b11000;
+};
+
+/// Defines a convenient type for timestamp of various events.
+/// This is used by the EventStats below.
+using SteadyTimePoint = std::chrono::time_point;
+
+/// Various time (and possibly memory) statistics of an event.
+struct EventStats {
+  // REQUIRED: Start time of an event
+  SteadyTimePoint start;

labath wrote:

I think what caught Jonas's eye (though he probably doesn't know it) is that 
this class was very protobuf-y. Let me try to unpack that. We don't have the 
(understandable if you know the background, but strange if you don't) situation 
of fields that are *optional* at the transport layer but *required* at the 
application layer elsewhere. And I don't think we need that here either because 
the transport layer is part of the downstream/vendor implementation, so we can 
just use regular c++ conventions for the application layer (if a type is 
std::optional, it's optional; if it's not, it's not).

That's one part of the issue. The second part is question whether the 
"required-ness" of a field can be enforced syntactically (through a constructor 
which intializes it). That's usually a nice property though it doesn't work in 
all situations, and I don't think it's that useful for objects which are plain 
data carriers (no internal logic). It also only works if *every* constructor 
initializes it, so the fact that you've added a constructor which does that, 
but then also kept the default one which does not (well, it initializes it, but 
to zero), doesn't really help there.

I'm saying this because this overload set is basically the same as what you'd 
get if you specified no explicit constructors -- you could still do the same 
thing, just with curly braces (`EventStats{}` default initializes everything, 
`EventStats{start}` initializes the first member, `EventStats{start, end}` 
initializes both). So, if this is the behavior you want, you can just delete 
all of them. If you want to enforce the requiredness (which might be nice, but 
I don't think it's necessary -- Jonas may disagree), then you should  delete 
the default constructor -- but then you also need to use these classes 
differently.

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


[Lldb-commits] [lldb] [lldb][telemetry] Implement LLDB Telemetry (part 1) (PR #119716)

2025-02-07 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,93 @@
+//===-- Telemetry.h --*- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_CORE_TELEMETRY_H
+#define LLDB_CORE_TELEMETRY_H
+
+#include "lldb/Core/StructuredDataImpl.h"
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Utility/StructuredData.h"
+#include "lldb/lldb-forward.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/JSON.h"
+#include "llvm/Telemetry/Telemetry.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace lldb_private {
+
+struct LldbEntryKind : public ::llvm::telemetry::EntryKind {
+  static const llvm::telemetry::KindType BaseInfo = 0b11000;
+};
+
+/// Defines a convenient type for timestamp of various events.
+/// This is used by the EventStats below.
+using SteadyTimePoint = std::chrono::time_point;
+
+/// Various time (and possibly memory) statistics of an event.
+struct EventStats {
+  // REQUIRED: Start time of an event
+  SteadyTimePoint start;
+  // OPTIONAL: End time of an event - may be empty if not meaningful.
+  std::optional end;
+  // TBD: could add some memory stats here too?
+
+  EventStats() = default;
+  EventStats(SteadyTimePoint start) : start(start) {}
+  EventStats(SteadyTimePoint start, SteadyTimePoint end)
+  : start(start), end(end) {}
+};
+
+/// Describes the exit signal of an event.
+struct ExitDescription {
+  int exit_code;
+  std::string description;
+};
+
+struct LldbBaseTelemetryInfo : public llvm::telemetry::TelemetryInfo {
+  EventStats stats;
+
+  std::optional exit_desc;

labath wrote:

I think it'd be better to remove the struct completely for now. It'll be easier 
to figure out the exact meaning/description for it in the context of the PR 
which uses it.

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


[Lldb-commits] [lldb] 52db30e - [lldb] Fix compiler error in ValueObject tests

2025-02-07 Thread David Spickett via lldb-commits

Author: David Spickett
Date: 2025-02-07T10:29:35Z
New Revision: 52db30ec4154b0ef21db546ed9b5a9bfe47859cd

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

LOG: [lldb] Fix compiler error in ValueObject tests

Fixes 0cbc4983adcdbbd85ccb38b2dfbfe5985367b1b2.

error: non-constant-expression cannot be narrowed from type 'uint64_t' (aka 
'unsigned long long') to 'size_t' (aka 'unsigned int') in initializer list 
[-Wc++11-narrowing]
   71 | in_value.GetLocalBufferSize()};
  | ^

Given this is test code, I think a static cast is fine here.

Tiny risk that it's actually a symptom of a bug that would
happen if you did 32-bit to 64-bit debugging. I expect you'd
find a lot more bugs than that though.

Added: 


Modified: 
lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp

Removed: 




diff  --git a/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp 
b/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp
index d311c05e511786..e3cf0f8a87bd2a 100644
--- a/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp
+++ b/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp
@@ -68,7 +68,7 @@ struct MockLanguageRuntime : public LanguageRuntime {
 class_type_or_name.SetCompilerType(int_type);
 local_buffer = {(uint8_t *)in_value.GetValue().GetScalar().ULongLong(
 LLDB_INVALID_ADDRESS),
-in_value.GetLocalBufferSize()};
+static_cast(in_value.GetLocalBufferSize())};
 value_type = Value::ValueType::HostAddress;
 
 return true;



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


[Lldb-commits] [lldb] [lldb][TypeSystemClang] Create EnumExtensibilityAttr from DW_AT_APPLE_enum_kind (PR #126221)

2025-02-07 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)


Changes

This patch consumes the `DW_AT_APPLE_enum_kind` attribute added in 
https://github.com/llvm/llvm-project/pull/124752 and turns it into a Clang 
attribute in the AST. This will currently be used by the Swift language plugin 
when it creates `EnumDecl`s from debug-info and passes it to Swift compiler, 
which expects these attributes

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


5 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
(+7-2) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h (+4) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp (+6-1) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h (+7-6) 
- (added) lldb/test/Shell/Expr/TestEnumExtensibility.m (+33) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 39296ba5b437fe6..ec0004c70c6dac6 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -492,6 +492,10 @@ ParsedDWARFTypeAttributes::ParsedDWARFTypeAttributes(const 
DWARFDIE &die) {
 case DW_AT_reference:
   ref_qual = clang::RQ_LValue;
   break;
+case DW_AT_APPLE_enum_kind:
+  enum_kind = static_cast(
+  form_value.Unsigned());
+  break;
 }
   }
 }
@@ -1001,9 +1005,10 @@ TypeSP DWARFASTParserClang::ParseEnum(const 
SymbolContext &sc,
   }
 
   CompilerType clang_type = m_ast.CreateEnumerationType(
-  attrs.name.GetStringRef(), GetClangDeclContextContainingDIE(def_die, 
nullptr),
+  attrs.name.GetStringRef(),
+  GetClangDeclContextContainingDIE(def_die, nullptr),
   GetOwningClangModule(def_die), attrs.decl, enumerator_clang_type,
-  attrs.is_scoped_enum);
+  attrs.is_scoped_enum, attrs.enum_kind);
   TypeSP type_sp =
   dwarf->MakeType(def_die.GetID(), attrs.name, attrs.byte_size, nullptr,
   attrs.type.Reference().GetID(), Type::eEncodingIsUID,
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
index 36fb381d3e291db..135dd06186c4bf4 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
@@ -568,6 +568,10 @@ struct ParsedDWARFTypeAttributes {
   ///< Indicates ref-qualifier of C++ member function if present.
   ///< Is RQ_None otherwise.
   clang::RefQualifierKind ref_qual = clang::RQ_None;
+
+  ///< Has a value if this DIE represents an enum that was declared
+  ///< with enum_extensibility.
+  std::optional enum_kind;
 };
 
 #endif // LLDB_SOURCE_PLUGINS_SYMBOLFILE_DWARF_DWARFASTPARSERCLANG_H
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 1da8fbe0bcd6dda..f91b608683420e2 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -2297,7 +2297,8 @@ CompilerType 
TypeSystemClang::GetOrCreateStructForIdentifier(
 CompilerType TypeSystemClang::CreateEnumerationType(
 llvm::StringRef name, clang::DeclContext *decl_ctx,
 OptionalClangModuleID owning_module, const Declaration &decl,
-const CompilerType &integer_clang_type, bool is_scoped) {
+const CompilerType &integer_clang_type, bool is_scoped,
+std::optional enum_kind) {
   // TODO: Do something intelligent with the Declaration object passed in
   // like maybe filling in the SourceLocation with it...
   ASTContext &ast = getASTContext();
@@ -2315,6 +2316,10 @@ CompilerType TypeSystemClang::CreateEnumerationType(
   if (decl_ctx)
 decl_ctx->addDecl(enum_decl);
 
+  if (enum_kind)
+enum_decl->addAttr(
+clang::EnumExtensibilityAttr::CreateImplicit(ast, *enum_kind));
+
   // TODO: check if we should be setting the promotion type too?
   enum_decl->setIntegerType(ClangUtil::GetQualType(integer_clang_type));
 
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
index e70ad4c2973a5cf..99d9becffd128c3 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
@@ -22,6 +22,7 @@
 
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/ASTFwd.h"
+#include "clang/AST/Attr.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/TemplateBase.h"
 #include "clang/AST/Type.h"
@@ -498,12 +499,12 @@ class TypeSystemClang : public TypeSystem {
bool is_vector);
 
   // Enumeration Types
-  CompilerType CreateEnumerationType(llvm::StringRef name,
- clang::DeclContext *decl_ctx,
- 

[Lldb-commits] [lldb] [lldb][TypeSystemClang] Create EnumExtensibilityAttr from DW_AT_APPLE_enum_kind (PR #126221)

2025-02-07 Thread Michael Buch via lldb-commits

https://github.com/Michael137 created 
https://github.com/llvm/llvm-project/pull/126221

This patch consumes the `DW_AT_APPLE_enum_kind` attribute added in 
https://github.com/llvm/llvm-project/pull/124752 and turns it into a Clang 
attribute in the AST. This will currently be used by the Swift language plugin 
when it creates `EnumDecl`s from debug-info and passes it to Swift compiler, 
which expects these attributes

>From 8a653e079dc4dc6cabad1ae8542f9b956935629d Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Fri, 7 Feb 2025 10:29:30 +
Subject: [PATCH] [lldb][TypeSystemClang] Create EnumExtensibilityAttr from
 DW_AT_APPLE_enum_kind

---
 .../SymbolFile/DWARF/DWARFASTParserClang.cpp  |  9 +++--
 .../SymbolFile/DWARF/DWARFASTParserClang.h|  4 +++
 .../TypeSystem/Clang/TypeSystemClang.cpp  |  7 +++-
 .../TypeSystem/Clang/TypeSystemClang.h| 13 
 lldb/test/Shell/Expr/TestEnumExtensibility.m  | 33 +++
 5 files changed, 57 insertions(+), 9 deletions(-)
 create mode 100644 lldb/test/Shell/Expr/TestEnumExtensibility.m

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 39296ba5b437fe6..ec0004c70c6dac6 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -492,6 +492,10 @@ ParsedDWARFTypeAttributes::ParsedDWARFTypeAttributes(const 
DWARFDIE &die) {
 case DW_AT_reference:
   ref_qual = clang::RQ_LValue;
   break;
+case DW_AT_APPLE_enum_kind:
+  enum_kind = static_cast(
+  form_value.Unsigned());
+  break;
 }
   }
 }
@@ -1001,9 +1005,10 @@ TypeSP DWARFASTParserClang::ParseEnum(const 
SymbolContext &sc,
   }
 
   CompilerType clang_type = m_ast.CreateEnumerationType(
-  attrs.name.GetStringRef(), GetClangDeclContextContainingDIE(def_die, 
nullptr),
+  attrs.name.GetStringRef(),
+  GetClangDeclContextContainingDIE(def_die, nullptr),
   GetOwningClangModule(def_die), attrs.decl, enumerator_clang_type,
-  attrs.is_scoped_enum);
+  attrs.is_scoped_enum, attrs.enum_kind);
   TypeSP type_sp =
   dwarf->MakeType(def_die.GetID(), attrs.name, attrs.byte_size, nullptr,
   attrs.type.Reference().GetID(), Type::eEncodingIsUID,
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
index 36fb381d3e291db..135dd06186c4bf4 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
@@ -568,6 +568,10 @@ struct ParsedDWARFTypeAttributes {
   ///< Indicates ref-qualifier of C++ member function if present.
   ///< Is RQ_None otherwise.
   clang::RefQualifierKind ref_qual = clang::RQ_None;
+
+  ///< Has a value if this DIE represents an enum that was declared
+  ///< with enum_extensibility.
+  std::optional enum_kind;
 };
 
 #endif // LLDB_SOURCE_PLUGINS_SYMBOLFILE_DWARF_DWARFASTPARSERCLANG_H
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 1da8fbe0bcd6dda..f91b608683420e2 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -2297,7 +2297,8 @@ CompilerType 
TypeSystemClang::GetOrCreateStructForIdentifier(
 CompilerType TypeSystemClang::CreateEnumerationType(
 llvm::StringRef name, clang::DeclContext *decl_ctx,
 OptionalClangModuleID owning_module, const Declaration &decl,
-const CompilerType &integer_clang_type, bool is_scoped) {
+const CompilerType &integer_clang_type, bool is_scoped,
+std::optional enum_kind) {
   // TODO: Do something intelligent with the Declaration object passed in
   // like maybe filling in the SourceLocation with it...
   ASTContext &ast = getASTContext();
@@ -2315,6 +2316,10 @@ CompilerType TypeSystemClang::CreateEnumerationType(
   if (decl_ctx)
 decl_ctx->addDecl(enum_decl);
 
+  if (enum_kind)
+enum_decl->addAttr(
+clang::EnumExtensibilityAttr::CreateImplicit(ast, *enum_kind));
+
   // TODO: check if we should be setting the promotion type too?
   enum_decl->setIntegerType(ClangUtil::GetQualType(integer_clang_type));
 
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
index e70ad4c2973a5cf..99d9becffd128c3 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
@@ -22,6 +22,7 @@
 
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/ASTFwd.h"
+#include "clang/AST/Attr.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/TemplateBase.h"
 #include "clang/AST/Type.h"
@@ -498,12 +499,12 @@ class TypeSystemClang : public TypeSystem {
bool is_vector);
 
   // Enumerati

[Lldb-commits] [lldb] [lldb] Clear cached unwind plans when adding symbols (PR #125839)

2025-02-07 Thread Pavel Labath via lldb-commits

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

>From 82e0ee5bf53dd6b886327021f5b145c942b43ff6 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 5 Feb 2025 11:28:48 +0100
Subject: [PATCH 1/2] [lldb] Clear cached unwind plans when adding symbols

PR #86603 broke unwinding in for unwind info added via "target symbols
add". #86770 attempted to fix this, but the fix was only partial -- it
accepted new sources of unwind information, but didn't take into account
that the symbol file can alter what lldb percieves as function
boundaries.

A stripped file will not contain information about private
(non-exported) symbols, which will make the public symbols appear very
large. If lldb tries to unwind from such a function before symbols are
added, then the cached unwind plan will prevent new (correct) unwind
plans from being created.

target-symbols-add-unwind.test might have caught this, were it not for
the fact that the "image show-unwind" command does *not* use cached
unwind information (it recomputes it from scratch).

The changes in this patch come in three pieces:
- Clear cached unwind plans when adding symbols. Since the symbol
  boundaries can change, we cannot trust anything we've computed
  previously.
- Add a flag to "image show-unwind" to display the cached unwind
  information (mainly for the use in the test, but I think it's also
  generally useful).
- Rewrite the test to better and more reliably simulate the real-world
  scenario: I've swapped the running process for a core (minidump) file
  so it can run anywhere; used the caching version of the show-unwind
  command; and swapped C for assembly to better control the placement of
  symbols
---
 lldb/include/lldb/Symbol/UnwindTable.h|   5 +-
 lldb/source/Commands/CommandObjectTarget.cpp  |  22 +++-
 lldb/source/Commands/Options.td   |   2 +
 lldb/source/Symbol/UnwindTable.cpp|   3 +-
 .../Inputs/target-symbols-add-unwind.c|   1 -
 .../SymbolFile/target-symbols-add-unwind.test | 118 +++---
 6 files changed, 125 insertions(+), 26 deletions(-)
 delete mode 100644 
lldb/test/Shell/SymbolFile/Inputs/target-symbols-add-unwind.c

diff --git a/lldb/include/lldb/Symbol/UnwindTable.h 
b/lldb/include/lldb/Symbol/UnwindTable.h
index 29b7fa61b4849e0..3166fdec6ebaa77 100644
--- a/lldb/include/lldb/Symbol/UnwindTable.h
+++ b/lldb/include/lldb/Symbol/UnwindTable.h
@@ -38,8 +38,9 @@ class UnwindTable {
   ArmUnwindInfo *GetArmUnwindInfo();
   SymbolFile *GetSymbolFile();
 
-  lldb::FuncUnwindersSP GetFuncUnwindersContainingAddress(const Address &addr,
-  SymbolContext &sc);
+  lldb::FuncUnwindersSP
+  GetFuncUnwindersContainingAddress(const Address &addr,
+const SymbolContext &sc);
 
   bool GetAllowAssemblyEmulationUnwindPlans();
 
diff --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index d8265e41a7384eb..db142e8f0eaee77 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -3471,6 +3471,17 @@ class CommandObjectTargetModulesShowUnwind : public 
CommandObjectParsed {
 m_type = eLookupTypeFunctionOrSymbol;
 break;
 
+  case 'c':
+bool value, success;
+value = OptionArgParser::ToBoolean(option_arg, false, &success);
+if (success) {
+  m_cached = value;
+} else {
+  return Status::FromErrorStringWithFormatv(
+  "invalid boolean value '%s' passed for -G option", option_arg);
+}
+break;
+
   default:
 llvm_unreachable("Unimplemented option");
   }
@@ -3482,6 +3493,7 @@ class CommandObjectTargetModulesShowUnwind : public 
CommandObjectParsed {
   m_type = eLookupTypeInvalid;
   m_str.clear();
   m_addr = LLDB_INVALID_ADDRESS;
+  m_cached = false;
 }
 
 llvm::ArrayRef GetDefinitions() override {
@@ -3494,6 +3506,7 @@ class CommandObjectTargetModulesShowUnwind : public 
CommandObjectParsed {
  // parsing options
 std::string m_str; // Holds name lookup
 lldb::addr_t m_addr = LLDB_INVALID_ADDRESS; // Holds the address to lookup
+bool m_cached = false;
   };
 
   CommandObjectTargetModulesShowUnwind(CommandInterpreter &interpreter)
@@ -3583,9 +3596,12 @@ class CommandObjectTargetModulesShowUnwind : public 
CommandObjectParsed {
   if (abi)
 start_addr = abi->FixCodeAddress(start_addr);
 
-  FuncUnwindersSP func_unwinders_sp(
-  sc.module_sp->GetUnwindTable()
-  .GetUncachedFuncUnwindersContainingAddress(start_addr, sc));
+  UnwindTable &uw_table = sc.module_sp->GetUnwindTable();
+  FuncUnwindersSP func_unwinders_sp =
+  m_options.m_cached
+  ? uw_table.GetFuncUnwindersContainingAddress(start_addr, sc)
+  : uw_table.GetUncachedFuncU

[Lldb-commits] [clang] [lldb] Reland: [clang] fix P3310 overload resolution flag propagation (PR #125791)

2025-02-07 Thread Michael Buch via lldb-commits

Michael137 wrote:

Put up https://github.com/llvm/llvm-project/pull/126215
Should address the failure @hokein observed

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


[Lldb-commits] [lldb] [lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… (PR #125143)

2025-02-07 Thread David Spickett via lldb-commits

DavidSpickett wrote:

I will push something shortly for this.

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


[Lldb-commits] [lldb] 9d83790 - [lldb] Fix build error in ValueObject test

2025-02-07 Thread David Spickett via lldb-commits

Author: David Spickett
Date: 2025-02-07T10:03:23Z
New Revision: 9d83790d170cc0a06179514e2ab739f7ecafb78c

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

LOG: [lldb] Fix build error in ValueObject test

Fixes 0cbc4983adcdbbd85ccb38b2dfbfe5985367b1b2.

llvm-project/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp(221): 
error C2065: 'u_int8_t': undeclared identifier

Added: 


Modified: 
lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp

Removed: 




diff  --git a/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp 
b/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp
index 0ae3963f0c8320a..d311c05e5117867 100644
--- a/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp
+++ b/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp
@@ -218,7 +218,7 @@ class DynamicValueObjectLocalBufferTest : public 
::testing::Test {
 TEST_F(DynamicValueObjectLocalBufferTest, BufferTooSmall) {
   /// Test that a value object with a buffer to small to fit the
   /// "dynamic" type will return an invalid dynamic value object.
-  u_int8_t value = 1;
+  uint8_t value = 1;
   ByteOrder endian = endian::InlHostByteOrder();
   DataExtractor data_extractor{&value, sizeof(value), endian, 4};
   TestValueObjectWithLocalBuffer(data_extractor, false);



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


[Lldb-commits] [lldb] [lldb] Clear cached unwind plans when adding symbols (PR #125839)

2025-02-07 Thread Pavel Labath via lldb-commits


@@ -3471,6 +3471,17 @@ class CommandObjectTargetModulesShowUnwind : public 
CommandObjectParsed {
 m_type = eLookupTypeFunctionOrSymbol;
 break;
 
+  case 'c':
+bool value, success;
+value = OptionArgParser::ToBoolean(option_arg, false, &success);
+if (success) {
+  m_cached = value;
+} else {
+  return Status::FromErrorStringWithFormatv(
+  "invalid boolean value '%s' passed for -G option", option_arg);

labath wrote:

haha, you caught me.

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


[Lldb-commits] [clang] [lldb] [lldb][TypeSystemClang] Initialize ClassTemplateSpecializationDecl's StrictPackMatch field (PR #126215)

2025-02-07 Thread Michael Buch via lldb-commits

https://github.com/Michael137 created 
https://github.com/llvm/llvm-project/pull/126215

This addresses the MSAN failure reported
in https://github.com/llvm/llvm-project/pull/125791#issuecomment-2639183154:
```
==5633==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 in 
clang::ASTNodeImporter::CallOverloadedCreateFun::operator()
#1 in bool clang::ASTNodeImporter::GetImportedOrCreateSpecialDecl<...>
...
```

The ASTImporter reads `D->hasStrictPackMatch()` and forwards it to the 
constructor of the destination `ClassTemplateSpecializationDecl`. But if `D` is 
a decl that LLDB created from debug-info, it would've been created using 
`ClassTemplateSpecializationDecl::CreateDeserialized`, which doesn't initialize 
the `StrictPackMatch` field.

This patch just initializes the field to a fixed value of `false`, to preserve 
previous behaviour and avoid the use-of-uninitialized-value.

An alternative would be to always initialize it in the 
`ClassTemplateSpecializationDecl` constructor, but there were reservations 
about providing a default value for it because it might lead to 
hard-to-diagnose problems down the line.

>From b061996c0b00d9f219ebacaa2529d694d37b71a9 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Fri, 7 Feb 2025 09:43:36 +
Subject: [PATCH] [lldb][TypeSystemClang] Initialize
 ClassTemplateSpecializationDecl's StrictPackMatch field

This addresses the MSAN failure reported
in https://github.com/llvm/llvm-project/pull/125791#issuecomment-2639183154:
```
==5633==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 in 
clang::ASTNodeImporter::CallOverloadedCreateFun::operator()
#1 in bool clang::ASTNodeImporter::GetImportedOrCreateSpecialDecl<...>
...
```

The ASTImporter reads `D->hasStrictPackMatch()` and forwards it to the 
constructor of the destination `ClassTemplateSpecializationDecl`. But if `D` is 
a decl that LLDB created from debug-info, it would've been created using 
`ClassTemplateSpecializationDecl::CreateDeserialized`, which doesn't initialize 
the `StrictPackMatch` field.

This patch just initializes the field to a fixed value of `false`, to preserve 
previous behaviour and avoid the use-of-uninitialized-value.

An alternative would be to always initialize it in the 
`ClassTemplateSpecializationDecl` constructor, but there were reservations 
about providing a default value for it because it might lead to 
hard-to-diagnose problems down the line.
---
 clang/include/clang/AST/DeclTemplate.h   | 2 ++
 lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp | 6 ++
 2 files changed, 8 insertions(+)

diff --git a/clang/include/clang/AST/DeclTemplate.h 
b/clang/include/clang/AST/DeclTemplate.h
index a30ae798a99bc69..b82f75dd63fa508 100644
--- a/clang/include/clang/AST/DeclTemplate.h
+++ b/clang/include/clang/AST/DeclTemplate.h
@@ -1960,6 +1960,8 @@ class ClassTemplateSpecializationDecl : public 
CXXRecordDecl,
 
   bool hasStrictPackMatch() const { return StrictPackMatch; }
 
+  void setStrictPackMatch(bool Val) { StrictPackMatch = Val; }
+
   /// Get the point of instantiation (if any), or null if none.
   SourceLocation getPointOfInstantiation() const {
 return PointOfInstantiation;
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 1da8fbe0bcd6dda..ecb571b1161bbc6 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -1666,6 +1666,12 @@ TypeSystemClang::CreateClassTemplateSpecializationDecl(
   ast.getTypeDeclType(class_template_specialization_decl, nullptr);
   class_template_specialization_decl->setDeclName(
   class_template_decl->getDeclName());
+
+  // FIXME: set to fixed value for now so it's not uninitialized.
+  // One way to determine StrictPackMatch would be
+  // Sema::CheckTemplateTemplateArgument.
+  class_template_specialization_decl->setStrictPackMatch(false);
+
   SetOwningModule(class_template_specialization_decl, owning_module);
   decl_ctx->addDecl(class_template_specialization_decl);
 

___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread via lldb-commits

github-actions[bot] wrote:



Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this 
page.

If this is not working for you, it is probably because you do not have write 
permissions for the repository. In which case you can instead tag reviewers by 
name in a comment by using `@` followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a 
review by "ping"ing the PR by adding a comment “Ping”. The common courtesy 
"ping" rate is once a week. Please remember that you are asking for valuable 
time from other developers.

If you have further questions, they may be answered by the [LLVM GitHub User 
Guide](https://llvm.org/docs/GitHub.html).

You can also ask questions in a comment on this PR, on the [LLVM 
Discord](https://discord.com/invite/xS7Z362) or on the 
[forums](https://discourse.llvm.org/).

https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-backend-amdgpu

Author: None (chrisPyr)


Changes

#125983 

---

Patch is 216.27 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/126243.diff


128 Files Affected:

- (modified) bolt/lib/Core/BinaryContext.cpp (+4-3) 
- (modified) bolt/lib/Core/BinaryData.cpp (+1-1) 
- (modified) bolt/lib/Core/BinaryFunction.cpp (+6-9) 
- (modified) bolt/lib/Passes/Aligner.cpp (+12-17) 
- (modified) bolt/lib/Passes/ContinuityStats.cpp (+1-1) 
- (modified) bolt/lib/Passes/FrameOptimizer.cpp (+1-1) 
- (modified) bolt/lib/Passes/Instrumentation.cpp (+1-1) 
- (modified) bolt/lib/Passes/PLTCall.cpp (+10-16) 
- (modified) bolt/lib/Passes/RetpolineInsertion.cpp (+11-13) 
- (modified) bolt/lib/Passes/StokeInfo.cpp (+1-1) 
- (modified) bolt/lib/Passes/TailDuplication.cpp (+1-1) 
- (modified) bolt/lib/Profile/StaleProfileMatching.cpp (+12-12) 
- (modified) bolt/lib/Profile/YAMLProfileReader.cpp (+3-3) 
- (modified) bolt/lib/Rewrite/RewriteInstance.cpp (+13-12) 
- (modified) bolt/tools/bat-dump/bat-dump.cpp (+1-1) 
- (modified) bolt/tools/driver/llvm-bolt.cpp (+1-1) 
- (modified) bolt/tools/merge-fdata/merge-fdata.cpp (+1-1) 
- (modified) 
clang-tools-extra/clang-change-namespace/tool/ClangChangeNamespace.cpp (+18-17) 
- (modified) clang-tools-extra/clang-include-fixer/tool/ClangIncludeFixer.cpp 
(+16-16) 
- (modified) clang-tools-extra/clang-move/tool/ClangMove.cpp (+12-12) 
- (modified) clang-tools-extra/clang-reorder-fields/tool/ClangReorderFields.cpp 
(+2-1) 
- (modified) clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp (+3-3) 
- (modified) clang-tools-extra/clangd/index/remote/monitor/Monitor.cpp (+1-1) 
- (modified) clang-tools-extra/clangd/index/remote/server/Server.cpp (+14-12) 
- (modified) clang-tools-extra/clangd/tool/Check.cpp (+6-7) 
- (modified) clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp (+8-8) 
- (modified) clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp (+37-37) 
- (modified) clang/unittests/Tooling/ExecutionTest.cpp (+1-1) 
- (modified) clang/utils/TableGen/TableGen.cpp (+5-5) 
- (modified) flang/lib/Lower/OpenMP/Utils.cpp (+3-3) 
- (modified) flang/lib/Optimizer/Builder/IntrinsicCall.cpp (+1-1) 
- (modified) flang/lib/Optimizer/Passes/CommandLineOpts.cpp (+10-10) 
- (modified) lldb/tools/lldb-test/lldb-test.cpp (+13-12) 
- (modified) llvm/examples/Kaleidoscope/MCJIT/cached/toy-jit.cpp (+4-4) 
- (modified) llvm/examples/Kaleidoscope/MCJIT/cached/toy.cpp (+9-9) 
- (modified) llvm/examples/Kaleidoscope/MCJIT/complete/toy.cpp (+26-25) 
- (modified) llvm/examples/OrcV2Examples/LLJITDumpObjects/LLJITDumpObjects.cpp 
(+9-9) 
- (modified) 
llvm/examples/OrcV2Examples/LLJITWithThinLTOSummaries/LLJITWithThinLTOSummaries.cpp
 (+2-2) 
- (modified) llvm/lib/Analysis/AliasAnalysis.cpp (+2-1) 
- (modified) llvm/lib/Analysis/BranchProbabilityInfo.cpp (+1-1) 
- (modified) llvm/lib/Analysis/FunctionPropertiesAnalysis.cpp (+2-2) 
- (modified) llvm/lib/Analysis/IRSimilarityIdentifier.cpp (+1-1) 
- (modified) llvm/lib/Analysis/InlineSizeEstimatorAnalysis.cpp (+1-1) 
- (modified) llvm/lib/Analysis/MemoryProfileInfo.cpp (+1-1) 
- (modified) llvm/lib/CGData/CodeGenData.cpp (+2-2) 
- (modified) llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp (+1-1) 
- (modified) llvm/lib/CodeGen/MachinePipeliner.cpp (+1-1) 
- (modified) llvm/lib/CodeGen/MachineScheduler.cpp (+9-9) 
- (modified) llvm/lib/CodeGen/MachineStripDebug.cpp (+1-1) 
- (modified) llvm/lib/CodeGen/WindowScheduler.cpp (+6-6) 
- (modified) llvm/lib/ExecutionEngine/Orc/DebugUtils.cpp (+16-14) 
- (modified) llvm/lib/LTO/LTOCodeGenerator.cpp (+6-7) 
- (modified) llvm/lib/Target/AArch64/AArch64LowerHomogeneousPrologEpilog.cpp 
(+1-1) 
- (modified) llvm/lib/Target/AArch64/AArch64StackTaggingPreRA.cpp (+2-3) 
- (modified) llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp (+1-1) 
- (modified) llvm/lib/Target/AMDGPU/AMDGPULowerModuleLDSPass.cpp (+2-2) 
- (modified) llvm/lib/Target/AMDGPU/AMDGPUSwLowerLDS.cpp (+1-1) 
- (modified) llvm/lib/Target/ARM/ARMSelectionDAGInfo.cpp (+1-1) 
- (modified) llvm/lib/Target/ARM/MVELaneInterleavingPass.cpp (+1-1) 
- (modified) llvm/lib/Target/Hexagon/HexagonCopyToCombine.cpp (+5-6) 
- (modified) llvm/lib/Target/Hexagon/HexagonISelDAGToDAG.cpp (+11-14) 
- (modified) llvm/lib/Target/Hexagon/HexagonVectorCombine.cpp (+9-9) 
- (modified) llvm/lib/Target/Hexagon/MCTargetDesc/HexagonMCTargetDesc.cpp 
(+31-31) 
- (modified) llvm/lib/Target/WebAssembly/WebAssemblyMCInstLower.cpp (+1-1) 
- (modified) llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp (+18-17) 
- (modified) llvm/lib/Transforms/IPO/ElimAvailExtern.cpp (+1-1) 
- (modified) llvm/lib/Transforms/IPO/ExpandVariadics.cpp (+1-1) 
- (modified) llvm/lib/Transforms/IPO/MemProfContextDisambiguation.cpp (+1-1) 
- (modified) llvm/lib/Transforms/IPO/ModuleInliner.cpp (+1-1) 
- (modified) llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp (+18-17) 
- (modified) llvm/lib/Transforms/Instrumentation/Sanit

[Lldb-commits] [clang] [clang-tools-extra] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread via lldb-commits

llvmbot wrote:



@llvm/pr-subscribers-bolt

@llvm/pr-subscribers-clang

Author: None (chrisPyr)


Changes

#125983 

---

Patch is 216.27 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/126243.diff


128 Files Affected:

- (modified) bolt/lib/Core/BinaryContext.cpp (+4-3) 
- (modified) bolt/lib/Core/BinaryData.cpp (+1-1) 
- (modified) bolt/lib/Core/BinaryFunction.cpp (+6-9) 
- (modified) bolt/lib/Passes/Aligner.cpp (+12-17) 
- (modified) bolt/lib/Passes/ContinuityStats.cpp (+1-1) 
- (modified) bolt/lib/Passes/FrameOptimizer.cpp (+1-1) 
- (modified) bolt/lib/Passes/Instrumentation.cpp (+1-1) 
- (modified) bolt/lib/Passes/PLTCall.cpp (+10-16) 
- (modified) bolt/lib/Passes/RetpolineInsertion.cpp (+11-13) 
- (modified) bolt/lib/Passes/StokeInfo.cpp (+1-1) 
- (modified) bolt/lib/Passes/TailDuplication.cpp (+1-1) 
- (modified) bolt/lib/Profile/StaleProfileMatching.cpp (+12-12) 
- (modified) bolt/lib/Profile/YAMLProfileReader.cpp (+3-3) 
- (modified) bolt/lib/Rewrite/RewriteInstance.cpp (+13-12) 
- (modified) bolt/tools/bat-dump/bat-dump.cpp (+1-1) 
- (modified) bolt/tools/driver/llvm-bolt.cpp (+1-1) 
- (modified) bolt/tools/merge-fdata/merge-fdata.cpp (+1-1) 
- (modified) 
clang-tools-extra/clang-change-namespace/tool/ClangChangeNamespace.cpp (+18-17) 
- (modified) clang-tools-extra/clang-include-fixer/tool/ClangIncludeFixer.cpp 
(+16-16) 
- (modified) clang-tools-extra/clang-move/tool/ClangMove.cpp (+12-12) 
- (modified) clang-tools-extra/clang-reorder-fields/tool/ClangReorderFields.cpp 
(+2-1) 
- (modified) clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp (+3-3) 
- (modified) clang-tools-extra/clangd/index/remote/monitor/Monitor.cpp (+1-1) 
- (modified) clang-tools-extra/clangd/index/remote/server/Server.cpp (+14-12) 
- (modified) clang-tools-extra/clangd/tool/Check.cpp (+6-7) 
- (modified) clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp (+8-8) 
- (modified) clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp (+37-37) 
- (modified) clang/unittests/Tooling/ExecutionTest.cpp (+1-1) 
- (modified) clang/utils/TableGen/TableGen.cpp (+5-5) 
- (modified) flang/lib/Lower/OpenMP/Utils.cpp (+3-3) 
- (modified) flang/lib/Optimizer/Builder/IntrinsicCall.cpp (+1-1) 
- (modified) flang/lib/Optimizer/Passes/CommandLineOpts.cpp (+10-10) 
- (modified) lldb/tools/lldb-test/lldb-test.cpp (+13-12) 
- (modified) llvm/examples/Kaleidoscope/MCJIT/cached/toy-jit.cpp (+4-4) 
- (modified) llvm/examples/Kaleidoscope/MCJIT/cached/toy.cpp (+9-9) 
- (modified) llvm/examples/Kaleidoscope/MCJIT/complete/toy.cpp (+26-25) 
- (modified) llvm/examples/OrcV2Examples/LLJITDumpObjects/LLJITDumpObjects.cpp 
(+9-9) 
- (modified) 
llvm/examples/OrcV2Examples/LLJITWithThinLTOSummaries/LLJITWithThinLTOSummaries.cpp
 (+2-2) 
- (modified) llvm/lib/Analysis/AliasAnalysis.cpp (+2-1) 
- (modified) llvm/lib/Analysis/BranchProbabilityInfo.cpp (+1-1) 
- (modified) llvm/lib/Analysis/FunctionPropertiesAnalysis.cpp (+2-2) 
- (modified) llvm/lib/Analysis/IRSimilarityIdentifier.cpp (+1-1) 
- (modified) llvm/lib/Analysis/InlineSizeEstimatorAnalysis.cpp (+1-1) 
- (modified) llvm/lib/Analysis/MemoryProfileInfo.cpp (+1-1) 
- (modified) llvm/lib/CGData/CodeGenData.cpp (+2-2) 
- (modified) llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp (+1-1) 
- (modified) llvm/lib/CodeGen/MachinePipeliner.cpp (+1-1) 
- (modified) llvm/lib/CodeGen/MachineScheduler.cpp (+9-9) 
- (modified) llvm/lib/CodeGen/MachineStripDebug.cpp (+1-1) 
- (modified) llvm/lib/CodeGen/WindowScheduler.cpp (+6-6) 
- (modified) llvm/lib/ExecutionEngine/Orc/DebugUtils.cpp (+16-14) 
- (modified) llvm/lib/LTO/LTOCodeGenerator.cpp (+6-7) 
- (modified) llvm/lib/Target/AArch64/AArch64LowerHomogeneousPrologEpilog.cpp 
(+1-1) 
- (modified) llvm/lib/Target/AArch64/AArch64StackTaggingPreRA.cpp (+2-3) 
- (modified) llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp (+1-1) 
- (modified) llvm/lib/Target/AMDGPU/AMDGPULowerModuleLDSPass.cpp (+2-2) 
- (modified) llvm/lib/Target/AMDGPU/AMDGPUSwLowerLDS.cpp (+1-1) 
- (modified) llvm/lib/Target/ARM/ARMSelectionDAGInfo.cpp (+1-1) 
- (modified) llvm/lib/Target/ARM/MVELaneInterleavingPass.cpp (+1-1) 
- (modified) llvm/lib/Target/Hexagon/HexagonCopyToCombine.cpp (+5-6) 
- (modified) llvm/lib/Target/Hexagon/HexagonISelDAGToDAG.cpp (+11-14) 
- (modified) llvm/lib/Target/Hexagon/HexagonVectorCombine.cpp (+9-9) 
- (modified) llvm/lib/Target/Hexagon/MCTargetDesc/HexagonMCTargetDesc.cpp 
(+31-31) 
- (modified) llvm/lib/Target/WebAssembly/WebAssemblyMCInstLower.cpp (+1-1) 
- (modified) llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp (+18-17) 
- (modified) llvm/lib/Transforms/IPO/ElimAvailExtern.cpp (+1-1) 
- (modified) llvm/lib/Transforms/IPO/ExpandVariadics.cpp (+1-1) 
- (modified) llvm/lib/Transforms/IPO/MemProfContextDisambiguation.cpp (+1-1) 
- (modified) llvm/lib/Transforms/IPO/ModuleInliner.cpp (+1-1) 
- (modified) llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp (+18-17) 
- (modified) llvm/lib/Transforms/Inst

[Lldb-commits] [lldb] [lldb][telemetry] Implement LLDB Telemetry (part 1) (PR #119716)

2025-02-07 Thread Vy Nguyen via lldb-commits


@@ -0,0 +1,93 @@
+//===-- Telemetry.h --*- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_CORE_TELEMETRY_H
+#define LLDB_CORE_TELEMETRY_H
+
+#include "lldb/Core/StructuredDataImpl.h"
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Utility/StructuredData.h"
+#include "lldb/lldb-forward.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/JSON.h"
+#include "llvm/Telemetry/Telemetry.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace lldb_private {
+
+struct LldbEntryKind : public ::llvm::telemetry::EntryKind {
+  static const llvm::telemetry::KindType BaseInfo = 0b11000;
+};
+
+/// Defines a convenient type for timestamp of various events.
+/// This is used by the EventStats below.
+using SteadyTimePoint = std::chrono::time_point;
+
+/// Various time (and possibly memory) statistics of an event.
+struct EventStats {
+  // REQUIRED: Start time of an event
+  SteadyTimePoint start;

oontvoo wrote:

Sorry for the confusion. Should ahve added more comment on this.
The "REQUIRED" here doesn't mean it has to be set at construction time .It just 
means it should be set at some point before the TelemetryInfo struct is sent 
off.

In any case, I've removed the `EventStats` and moved the start/end time fields 
directly into the TelemetryInfo struct. 

https://github.com/llvm/llvm-project/pull/119716
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Rahul Joshi via lldb-commits

jurahul wrote:

I understand this is mostly mechanical changes, but wondering if review wise it 
will help if its split up into 4-5 PRs. For example, bolt, clang, flag, llvm, 
mlir etc.

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


[Lldb-commits] [lldb] [lldb][telemetry] Implement LLDB Telemetry (part 1) (PR #119716)

2025-02-07 Thread Vy Nguyen via lldb-commits

https://github.com/oontvoo updated 
https://github.com/llvm/llvm-project/pull/119716

>From b7216d7c3edd5974d84612586fbabdef19037387 Mon Sep 17 00:00:00 2001
From: Vy Nguyen 
Date: Thu, 26 Dec 2024 20:50:40 -0500
Subject: [PATCH 01/15] Implement LLDB Telemetry (Part 1)

This contains only the concrete implementation of the framework to be used but 
no usages yet.

This is a subset of PR/98528.

I plan to send a few follow-up patches:
part2 : includes changes in the plugin-manager to set up the plugin stuff (ie., 
how to create a default vs vendor impl)
part3 (all of the following can be done in parallel):
* part 3_a: define DebuggerTelemetryInfo and related methods to collect data 
about debugger startup/exit
* part 3_b: define TargetTelemetryInfo and related methods to collect data 
about debug target(s)
* part 3_c: define CommandTelemetryInfo and related methods to collect data 
about debug-commands
* part 3_d: define ClientTelemtryInfo and related methods to collect data about 
lldb-dap/any other client
---
 lldb/include/lldb/Core/Telemetry.h| 101 ++
 lldb/include/lldb/lldb-enumerations.h |   4 +-
 lldb/source/Core/CMakeLists.txt   |   2 +
 lldb/source/Core/Telemetry.cpp|  92 +++
 lldb/test/CMakeLists.txt  |   3 +
 5 files changed, 200 insertions(+), 2 deletions(-)
 create mode 100644 lldb/include/lldb/Core/Telemetry.h
 create mode 100644 lldb/source/Core/Telemetry.cpp

diff --git a/lldb/include/lldb/Core/Telemetry.h 
b/lldb/include/lldb/Core/Telemetry.h
new file mode 100644
index 000..882511efd804d23
--- /dev/null
+++ b/lldb/include/lldb/Core/Telemetry.h
@@ -0,0 +1,101 @@
+//===-- Telemetry.h --*- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_CORE_TELEMETRY_H
+#define LLDB_CORE_TELEMETRY_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/StructuredDataImpl.h"
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Utility/StructuredData.h"
+#include "lldb/lldb-forward.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/JSON.h"
+#include "llvm/Telemetry/Telemetry.h"
+
+namespace lldb_private {
+
+using llvm::telemetry::Destination;
+using llvm::telemetry::KindType;
+using llvm::telemetry::Serializer;
+using llvm::telemetry::TelemetryInfo;
+
+struct LldbEntryKind : public ::llvm::telemetry::EntryKind {
+  static const KindType BaseInfo = 0b11000;
+};
+
+/// Defines a convenient type for timestamp of various events.
+/// This is used by the EventStats below.
+using SteadyTimePoint = std::chrono::time_point;
+
+/// Various time (and possibly memory) statistics of an event.
+struct EventStats {
+  // REQUIRED: Start time of an event
+  SteadyTimePoint start;
+  // OPTIONAL: End time of an event - may be empty if not meaningful.
+  std::optional end;
+  // TBD: could add some memory stats here too?
+
+  EventStats() = default;
+  EventStats(SteadyTimePoint start) : start(start) {}
+  EventStats(SteadyTimePoint start, SteadyTimePoint end)
+  : start(start), end(end) {}
+};
+
+/// Describes the exit signal of an event.
+struct ExitDescription {
+  int exit_code;
+  std::string description;
+};
+
+struct LldbBaseTelemetryInfo : public TelemetryInfo {
+  EventStats stats;
+
+  std::optional exit_desc;
+
+  Debugger *debugger;
+
+  // For dyn_cast, isa, etc operations.
+  KindType getKind() const override { return LldbEntryKind::BaseInfo; }
+
+  static bool classof(const TelemetryInfo *t) {
+// Subclasses of this is also acceptable.
+return (t->getKind() & LldbEntryKind::BaseInfo) == LldbEntryKind::BaseInfo;
+  }
+
+  void serialize(Serializer &serializer) const override;
+};
+
+/// The base Telemetry manager instance in LLDB
+/// This class declares additional instrumentation points
+/// applicable to LLDB.
+class TelemetryManager : public llvm::telemetry::Manager {
+public:
+  TelemetryManager(std::unique_ptr config);
+
+  llvm::Error dispatch(TelemetryInfo *entry) override;
+
+  void addDestination(std::unique_ptr destination) override;
+
+private:
+  std::unique_ptr m_config;
+  const std::string m_session_uuid;
+  std::vector> m_destinations;
+};
+
+} // namespace lldb_private
+#endif // LLDB_CORE_TELEMETRY_H
diff --git a/lldb/include/lldb/lldb-enumerations.h 
b/lldb/include/lldb/lldb-enumerations.h
index 0094fcd596fdf70..f63e446b6042f62 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -257,8 +257,8 @@ enum StopReason {
 };
 
 /// Command Return Status Types.
-enum ReturnStatus {
-  eReturnStatusInvalid,
+enum ReturnStatus : int {
+  eReturnStatusInva

[Lldb-commits] [lldb] [lldb][telemetry] Implement LLDB Telemetry (part 1) (PR #119716)

2025-02-07 Thread Vy Nguyen via lldb-commits


@@ -0,0 +1,93 @@
+//===-- Telemetry.h --*- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_CORE_TELEMETRY_H
+#define LLDB_CORE_TELEMETRY_H
+
+#include "lldb/Core/StructuredDataImpl.h"
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Utility/StructuredData.h"
+#include "lldb/lldb-forward.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/JSON.h"
+#include "llvm/Telemetry/Telemetry.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace lldb_private {
+
+struct LldbEntryKind : public ::llvm::telemetry::EntryKind {
+  static const llvm::telemetry::KindType BaseInfo = 0b11000;
+};
+
+/// Defines a convenient type for timestamp of various events.
+/// This is used by the EventStats below.
+using SteadyTimePoint = std::chrono::time_point;
+
+/// Various time (and possibly memory) statistics of an event.
+struct EventStats {
+  // REQUIRED: Start time of an event
+  SteadyTimePoint start;
+  // OPTIONAL: End time of an event - may be empty if not meaningful.
+  std::optional end;
+  // TBD: could add some memory stats here too?
+
+  EventStats() = default;
+  EventStats(SteadyTimePoint start) : start(start) {}
+  EventStats(SteadyTimePoint start, SteadyTimePoint end)
+  : start(start), end(end) {}
+};
+
+/// Describes the exit signal of an event.
+struct ExitDescription {
+  int exit_code;
+  std::string description;
+};
+
+struct LldbBaseTelemetryInfo : public llvm::telemetry::TelemetryInfo {
+  EventStats stats;
+
+  std::optional exit_desc;

oontvoo wrote:

done - removed the ExistDescription

https://github.com/llvm/llvm-project/pull/119716
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Joseph Huber via lldb-commits

jhuber6 wrote:

> So I should do like open 5 branches and make a PR for each?
> 
> As for the cases mentioned, when I tried compile all projects (compile with 
> -DLLVM_ENABLE_PROJECTS=all), I did encounter such cases when compiling and 
> I've fixed them all. Now all projects can be successfully built, so I think 
> it should be fine?

Yes, one PR for each project please.

Also refer to the failing CI for what's broken, e.g.
```
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-96x6s-1/llvm-project/github-pull-requests/flang/lib/Lower/OpenMP/Utils.cpp:30:28:
 error: static declaration of 'treatIndexAsSection' follows non-static 
declaration
static llvm::cl::opt treatIndexAsSection(
   ^
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-96x6s-1/llvm-project/github-pull-requests/flang/lib/Lower/OpenMP/Utils.h:19:28:
 note: previous declaration is here
extern llvm::cl::opt treatIndexAsSection;
   ^
```

https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread via lldb-commits

chrisPyr wrote:

So I should do like open 5 branches and make a PR for each?

As for the cases mentioned, when I tried compile all projects (compile with 
-DLLVM_ENABLE_PROJECTS=all), I did encounter such cases when compiling and I've 
fixed them all. 
Now all projects can be successfully built, so I think it should be fine?

https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread via lldb-commits

chrisPyr wrote:

OK, I'll do it.
Except for checking it on CI, is there any other method I can test locally? 
E.g. what options should I add
I've tried compile with all project enabled, I thought by that way all changes 
were already being tested.
However, the CI failed, so it seems what I thought was wrong.

https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Matt Arsenault via lldb-commits

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


https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Joseph Huber via lldb-commits

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


[Lldb-commits] [lldb] [lldb][telemetry] Implement LLDB Telemetry (part 1) (PR #119716)

2025-02-07 Thread Vy Nguyen via lldb-commits


@@ -0,0 +1,100 @@
+//===-- Telemetry.h --*- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_CORE_TELEMETRY_H
+#define LLDB_CORE_TELEMETRY_H
+
+#include "lldb/Core/StructuredDataImpl.h"
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Utility/StructuredData.h"
+#include "lldb/lldb-forward.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/JSON.h"
+#include "llvm/Telemetry/Telemetry.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace lldb_private {
+
+using llvm::telemetry::Destination;

oontvoo wrote:

done.

https://github.com/llvm/llvm-project/pull/119716
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Joseph Huber via lldb-commits

https://github.com/jhuber6 commented:

This should definitely be split up. Also some options are referenced in 
multiple places, i.e.
```
// foo.h
extern cl::opt <...>

// foo.cpp
cl::opt <...>
use opt

//bar.cpp
use opt.
```

https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Rahul Joshi via lldb-commits

jurahul wrote:

Yeah, that’s why the description said most but not all. We should get link
failures if one of these is made static.

On Fri, Feb 7, 2025 at 7:17 AM Joseph Huber ***@***.***>
wrote:

> ***@***. commented on this pull request.
>
> This should definitely be split up. Also some options are referenced in
> multiple places, i.e.
>
> // foo.h
> extern cl::opt <...>
>
> // foo.cpp
> cl::opt <...>
> use opt
>
> //bar.cpp
> use opt.
>
> —
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>


https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Rahul Joshi via lldb-commits

jurahul wrote:

@arsenm did you intent to approve it without splitting? Is this trivial enough 
to not need splitting as long as CI checks pass?

https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Matt Arsenault via lldb-commits

arsenm wrote:

I don't care about splitting or not; either way 

https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread Rahul Joshi via lldb-commits

jurahul wrote:

You can check the CI logs for the exact command line it uses and replicate
it locally.

On Fri, Feb 7, 2025 at 7:46 AM chrisPyr ***@***.***> wrote:

> OK, I'll do it.
> Except for checking it on CI, is there any other method I can test
> locally? E.g. what options should I add
> I've tried compile with all project enabled, I thought by that way all
> changes were already being tested.
> However, the CI failed, so it seems what I thought was wrong.
>
> —
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>


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


[Lldb-commits] [lldb] [lldb][telemetry] Implement LLDB Telemetry (part 1) (PR #119716)

2025-02-07 Thread Vy Nguyen via lldb-commits


@@ -0,0 +1,93 @@
+//===-- Telemetry.h --*- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_CORE_TELEMETRY_H
+#define LLDB_CORE_TELEMETRY_H
+
+#include "lldb/Core/StructuredDataImpl.h"
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Utility/StructuredData.h"
+#include "lldb/lldb-forward.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/JSON.h"
+#include "llvm/Telemetry/Telemetry.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace lldb_private {
+
+struct LldbEntryKind : public ::llvm::telemetry::EntryKind {
+  static const llvm::telemetry::KindType BaseInfo = 0b11000;
+};
+
+/// Defines a convenient type for timestamp of various events.
+/// This is used by the EventStats below.
+using SteadyTimePoint = std::chrono::time_point;
+
+/// Various time (and possibly memory) statistics of an event.
+struct EventStats {
+  // REQUIRED: Start time of an event
+  SteadyTimePoint start;
+  // OPTIONAL: End time of an event - may be empty if not meaningful.
+  std::optional end;
+  // TBD: could add some memory stats here too?
+
+  EventStats() = default;
+  EventStats(SteadyTimePoint start) : start(start) {}
+  EventStats(SteadyTimePoint start, SteadyTimePoint end)
+  : start(start), end(end) {}
+};
+
+/// Describes the exit signal of an event.

oontvoo wrote:

To answer the orignal question, this is used to describe both the exit of LLDB 
and a process (or main executable).
I've removed the "signal" from the comment.

https://github.com/llvm/llvm-project/pull/119716
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread David Spickett via lldb-commits

DavidSpickett wrote:

> You can check the CI logs for the exact command line it uses and replicate it 
> locally.

Should be towards the start of the log, search for `cmake ` to find the command.

https://github.com/llvm/llvm-project/pull/126243
___
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] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread David Spickett via lldb-commits

DavidSpickett wrote:

> As for the cases mentioned, when I tried compile all projects (compile with 
> -DLLVM_ENABLE_PROJECTS=all), I did encounter such cases when compiling and 
> I've fixed them all.
> Now all projects can be successfully built, so I think it should be fine?

Just to explain why this only came up in CI, Flang is not part of `all` (see 
https://github.com/llvm/llvm-project/issues/112789).

According to:
https://github.com/llvm/llvm-project/blob/d0170424b7250bf5cda0e6253ec62112a6e1c92a/llvm/CMakeLists.txt#L127

Everything other than Flang will be enabled by `all`.

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