[Lldb-commits] [lldb] [lldb] Introduce an always-on system log category/channel (PR #108495)

[Pavel Labath via lldb-commits]

@@ -20,6 +20,8 @@
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/TargetSelect.h"
 
+#include "lldb/Version/Version.h"

labath wrote:

Group this with the other lldb includes?

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

[Lldb-commits] [lldb] [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (PR #106442)

[Pavel Labath via lldb-commits]

@@ -20,6 +23,53 @@
 
 namespace lldb_private {
 
+/// A compiler-independent representation of a Diagnostic. Expression
+/// evaluation failures often have more than one diagnostic that a UI
+/// layer might want to render differently, for example to colorize
+/// it.
+///
+/// Running example:
+///   (lldb) expr 1+foo
+///   error: :1:3: use of undeclared identifier 'foo'
+///   1+foo
+/// ^
+struct DiagnosticDetail {
+  struct SourceLocation {
+FileSpec file;
+unsigned line = 0;
+uint16_t column = 0;
+uint16_t length = 0;
+bool in_user_input = false;
+  };
+  /// Contains {{}, 1, 3, 3, true} in the example above.
+  std::optional source_location;
+  /// Contains eSeverityError in the example above.
+  lldb::Severity severity = lldb::eSeverityInfo;
+  /// Contains "use of undeclared identifier 'x'" in the example above.
+  std::string message;
+  /// Contains the fully rendered error message.
+  std::string rendered;
+};
+
+/// An llvm::Error used to communicate diagnostics in Status. Multiple
+/// diagnostics may be chained in an llvm::ErrorList.
+class ExpressionError
+: public llvm::ErrorInfo {
+  std::string m_message;
+  std::vector m_details;
+
+public:
+  static char ID;
+  using llvm::ErrorInfo::ErrorInfo;
+  ExpressionError(lldb::ExpressionResults result, std::string msg,
+  std::vector details = {});
+  std::string message() const override;
+  llvm::ArrayRef GetDetail() const { return m_details; }

labath wrote:

GetDetail***s*** ?

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

[Lldb-commits] [lldb] [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (PR #106442)

[Pavel Labath via lldb-commits]

@@ -268,7 +243,7 @@ ErrorType Status::GetType() const {
   result = eErrorTypeMachKernel;
 else if (error.isA())
   result = eErrorTypeWin32;
-else if (error.isA())
+else if (error.isA())

labath wrote:

I'm wondering if this would look nicer if we added a `GetLLDBErrorType` 
function to  our `ClonableError` class.

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

[Lldb-commits] [lldb] [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (PR #106442)

[Pavel Labath via lldb-commits]

@@ -224,6 +224,14 @@ const char *Status::AsCString(const char 
*default_error_str) const {
 if (!m_string.empty() && m_string[m_string.size() - 1] == '\n')
   m_string.pop_back();
 
+  // FIXME: Workaround for ErrorList[ExpressionError, ...].
+  if (m_error.isA()) {
+while (!m_string.empty() && m_string[0] == '\n')
+  m_string = std::string(m_string.data() + 1, m_string.size() - 1);
+if (!m_string.empty() && m_string[m_string.size() - 1] != '\n')
+  m_string += '\n';
+  }

labath wrote:

Yeah, I did not mean to imply that. Sorry for the confusion.

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

[Lldb-commits] [lldb] [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (PR #106442)

[Pavel Labath via lldb-commits]

@@ -130,6 +168,11 @@ class DiagnosticManager {
   m_diagnostics.back()->AppendMessage(str);
   }
 
+  /// Copies the diagnostics into an llvm::Error{List}.
+  /// The first diagnostic wraps \c result.

labath wrote:

I guess this is no longer true.

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

[Lldb-commits] [lldb] [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (PR #106442)

[Pavel Labath via lldb-commits]

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


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

[Lldb-commits] [lldb] [LLDB][ProcessELFCore] Add Description to ProcessELFCore/ELFThread stop reasons (PR #110065)

[David Spickett via lldb-commits]

DavidSpickett wrote:

So does this not need new testing or did you not add that yet?

I'm not clear on what fully decode means because at least for certain signals 
like a tag check fault we do have a description for live processes and core 
files. Perhaps that's because I added those as special cases I don't remember 
the specifics.

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

[Lldb-commits] [lldb] [LLDB][ProcessELFCore] Add Description to ProcessELFCore/ELFThread stop reasons (PR #110065)

[Pavel Labath via lldb-commits]

labath wrote:

Seems reasonable, but you'll need to use the signal constants from 
`UnixSignals` (looked up by string), as macros like `SIGBUS` might not exist 
(windows) or might not have the right value (macos). (NativeThreadLinux can get 
away with using them as it always runs on the host.)

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

[Lldb-commits] [lldb] [llvm] [lldb][DWARF] Replace lldb's DWARFDebugArangeSet with llvm's (PR #110058)

[Pavel Labath via lldb-commits]

@@ -73,6 +73,12 @@ class DWARFDebugArangeSet {
 return desc_iterator_range(ArangeDescriptors.begin(),
ArangeDescriptors.end());
   }
+
+  size_t getDescriptorsSize() const { return ArangeDescriptors.size(); }
+
+  const Descriptor &getDescriptiorRef(uint32_t I) const {

labath wrote:

I would actually say this shouldn't exist. These are very lldb-like functions, 
and as far as I can tell, the only place where you're actually using them is in 
tests -- where we have better options.

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

[Lldb-commits] [lldb] [llvm] [lldb][DWARF] Replace lldb's DWARFDebugArangeSet with llvm's (PR #110058)

[Pavel Labath via lldb-commits]

@@ -132,34 +134,33 @@ TEST_F(SymbolFileDWARFTests, 
ParseArangesWithMultipleTerminators) {
   // Set the big endian length correctly.
   const offset_t binary_data_size = sizeof(binary_data);
   binary_data[3] = (uint8_t)binary_data_size - 4;
-  DWARFDataExtractor data;
-  data.SetData(static_cast(binary_data), sizeof binary_data,
-   lldb::ByteOrder::eByteOrderBig);
+  llvm::DWARFDataExtractor data(llvm::ArrayRef(binary_data),
+/*isLittleEndian=*/false, /*AddrSize=*/4);
   DWARFDebugArangeSet set;
   offset_t off = 0;
   llvm::Error error = set.extract(data, &off);
   // Multiple terminators are not fatal as they do appear in binaries.
   EXPECT_FALSE(bool(error));
   // Parser should read all terminators to the end of the length specified.
   EXPECT_EQ(off, binary_data_size);
-  ASSERT_EQ(set.NumDescriptors(), 2U);
-  ASSERT_EQ(set.GetDescriptorRef(0).address, (dw_addr_t)0x1000);
-  ASSERT_EQ(set.GetDescriptorRef(0).length, (dw_addr_t)0x100);
-  ASSERT_EQ(set.GetDescriptorRef(1).address, (dw_addr_t)0x2000);
-  ASSERT_EQ(set.GetDescriptorRef(1).length, (dw_addr_t)0x10);
+  ASSERT_EQ(set.getDescriptorsSize(), 4U);

labath wrote:

This could be written in a number of ways that does not require these 
functions. My favourite is (requires adding an `operator==` to the Descriptor 
class):
```
ASSERT_THAT(set.descriptors(), testing::ElementsAre(Descriptor{0x1000, 0x100}, 
Descriptor{0x2000, 0x10}));
```

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

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

[Pavel Labath via lldb-commits]

labath wrote:

> I'm actually surprised that lldb-dap sees the new diagnostics because I 
> thought it would run the expression through a lower-level API like 
> SBFrame::EvaluateExpression(). But I guess it just provides a "terminal" 
> window that passes everything through HandleCommand. To support this better, 
> I'm thinking about adding a setting to opt into the inline diagnostics that 
> only `lldb` sets, so we don't get unexpected results like this.

It has both. lldb-dap does this weird heuristic console multiplexing, where it 
guesses whether something should be treated like an expression (I guess that's 
because other VSCode debuggers do that), which is executed through 
EvaluateExpression, or an lldb command, which is executed through 
HandleCommand. So it's not very likely that a user will be running a "command" 
to evaluate an expression, but I think it still illustrates my point that 
HandleCommand can be (and probably is) invoked in contexts where one cannot 
guarantee the alignment of the output.

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

[Lldb-commits] [lldb] [LLDB][ProcessELFCore] Add Description to ProcessELFCore/ELFThread stop reasons (PR #110065)

[David Spickett via lldb-commits]

DavidSpickett wrote:

> Perhaps that's because I added those as special cases I don't remember the 
> specifics.

I only added part of the description - 
https://github.com/llvm/llvm-project/commit/85bc498826d4dac4b64f7b02659f6ec52f11c223.
 Didn't add the fault address.

Happy to see improvements here!

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

[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)

[via lldb-commits]

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

[Lldb-commits] [lldb] [llvm] [lldb][DWARF] Replace lldb's DWARFDebugArangeSet with llvm's (PR #110058)

[Zequan Wu via lldb-commits]

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

>From 8e1c59729905fb89a8764ace3dfa0d04119d273e Mon Sep 17 00:00:00 2001
From: Zequan Wu 
Date: Wed, 25 Sep 2024 15:59:29 -0700
Subject: [PATCH 1/4] [lldb][DWARF] Replace lldb's DWARFDebugArangeSet with
 llvm's

---
 .../Plugins/SymbolFile/DWARF/CMakeLists.txt   |   1 -
 .../SymbolFile/DWARF/DWARFDebugArangeSet.cpp  | 176 --
 .../SymbolFile/DWARF/DWARFDebugArangeSet.h|  70 ---
 .../SymbolFile/DWARF/DWARFDebugAranges.cpp|  47 ++---
 .../SymbolFile/DWARF/SymbolFileDWARFTests.cpp |  56 +++---
 .../DebugInfo/DWARF/DWARFDebugArangeSet.h |   6 +
 .../DebugInfo/DWARF/DWARFDebugArangeSet.cpp   |  12 +-
 7 files changed, 55 insertions(+), 313 deletions(-)
 delete mode 100644 lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp
 delete mode 100644 lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.h

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/CMakeLists.txt 
b/lldb/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
index 0e4fd5b995d1ba..83c4f1a4cf892c 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
+++ b/lldb/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
@@ -18,7 +18,6 @@ add_lldb_library(lldbPluginSymbolFileDWARF PLUGIN
   DWARFContext.cpp
   DWARFDataExtractor.cpp
   DWARFDebugAranges.cpp
-  DWARFDebugArangeSet.cpp
   DWARFDebugInfo.cpp
   DWARFDebugInfoEntry.cpp
   DWARFDebugMacro.cpp
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp
deleted file mode 100644
index 8461b94abca630..00
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp
+++ /dev/null
@@ -1,176 +0,0 @@
-//===-- DWARFDebugArangeSet.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 "DWARFDebugArangeSet.h"
-#include "DWARFDataExtractor.h"
-#include "LogChannelDWARF.h"
-#include "llvm/Object/Error.h"
-#include 
-
-using namespace lldb_private;
-using namespace lldb_private::plugin::dwarf;
-
-DWARFDebugArangeSet::DWARFDebugArangeSet()
-: m_offset(DW_INVALID_OFFSET), m_next_offset(DW_INVALID_OFFSET) {}
-
-void DWARFDebugArangeSet::Clear() {
-  m_offset = DW_INVALID_OFFSET;
-  m_next_offset = DW_INVALID_OFFSET;
-  m_header.length = 0;
-  m_header.version = 0;
-  m_header.cu_offset = 0;
-  m_header.addr_size = 0;
-  m_header.seg_size = 0;
-  m_arange_descriptors.clear();
-}
-
-llvm::Error DWARFDebugArangeSet::extract(const DWARFDataExtractor &data,
- lldb::offset_t *offset_ptr) {
-  assert(data.ValidOffset(*offset_ptr));
-
-  m_arange_descriptors.clear();
-  m_offset = *offset_ptr;
-
-  // 7.20 Address Range Table
-  //
-  // Each set of entries in the table of address ranges contained in the
-  // .debug_aranges section begins with a header consisting of: a 4-byte
-  // length containing the length of the set of entries for this compilation
-  // unit, not including the length field itself; a 2-byte version identifier
-  // containing the value 2 for DWARF Version 2; a 4-byte offset into
-  // the.debug_infosection; a 1-byte unsigned integer containing the size in
-  // bytes of an address (or the offset portion of an address for segmented
-  // addressing) on the target system; and a 1-byte unsigned integer
-  // containing the size in bytes of a segment descriptor on the target
-  // system. This header is followed by a series of tuples. Each tuple
-  // consists of an address and a length, each in the size appropriate for an
-  // address on the target architecture.
-  m_header.length = data.GetDWARFInitialLength(offset_ptr);
-  // The length could be 4 bytes or 12 bytes, so use the current offset to
-  // determine the next offset correctly.
-  if (m_header.length > 0)
-m_next_offset = *offset_ptr + m_header.length;
-  else
-m_next_offset = DW_INVALID_OFFSET;
-  m_header.version = data.GetU16(offset_ptr);
-  m_header.cu_offset = data.GetDWARFOffset(offset_ptr);
-  m_header.addr_size = data.GetU8(offset_ptr);
-  m_header.seg_size = data.GetU8(offset_ptr);
-
-  // Try to avoid reading invalid arange sets by making sure:
-  // 1 - the version looks good
-  // 2 - the address byte size looks plausible
-  // 3 - the length seems to make sense
-  // 4 - size looks plausible
-  // 5 - the arange tuples do not contain a segment field
-  if (m_header.version < 2 || m_header.version > 5)
-return llvm::make_error(
-"Invalid arange header version");
-
-  if (m_header.addr_size != 4 && m_header.addr_size != 8)
-return llvm::make_error(
-"Invalid arange header address size");
-
-  if (m_header.length == 0)
-return llvm:

[Lldb-commits] [lldb] [llvm] [lldb][DWARF] Replace lldb's DWARFDebugArangeSet with llvm's (PR #110058)

[Zequan Wu via lldb-commits]

@@ -73,6 +73,12 @@ class DWARFDebugArangeSet {
 return desc_iterator_range(ArangeDescriptors.begin(),
ArangeDescriptors.end());
   }
+
+  size_t getDescriptorsSize() const { return ArangeDescriptors.size(); }
+
+  const Descriptor &getDescriptiorRef(uint32_t I) const {

ZequanWu wrote:

Removed these two functions.

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

[Lldb-commits] [lldb] [llvm] [lldb][DWARF] Replace lldb's DWARFDebugArangeSet with llvm's (PR #110058)

[Zequan Wu via lldb-commits]

@@ -132,34 +134,33 @@ TEST_F(SymbolFileDWARFTests, 
ParseArangesWithMultipleTerminators) {
   // Set the big endian length correctly.
   const offset_t binary_data_size = sizeof(binary_data);
   binary_data[3] = (uint8_t)binary_data_size - 4;
-  DWARFDataExtractor data;
-  data.SetData(static_cast(binary_data), sizeof binary_data,
-   lldb::ByteOrder::eByteOrderBig);
+  llvm::DWARFDataExtractor data(llvm::ArrayRef(binary_data),
+/*isLittleEndian=*/false, /*AddrSize=*/4);
   DWARFDebugArangeSet set;
   offset_t off = 0;
   llvm::Error error = set.extract(data, &off);
   // Multiple terminators are not fatal as they do appear in binaries.
   EXPECT_FALSE(bool(error));
   // Parser should read all terminators to the end of the length specified.
   EXPECT_EQ(off, binary_data_size);
-  ASSERT_EQ(set.NumDescriptors(), 2U);
-  ASSERT_EQ(set.GetDescriptorRef(0).address, (dw_addr_t)0x1000);
-  ASSERT_EQ(set.GetDescriptorRef(0).length, (dw_addr_t)0x100);
-  ASSERT_EQ(set.GetDescriptorRef(1).address, (dw_addr_t)0x2000);
-  ASSERT_EQ(set.GetDescriptorRef(1).length, (dw_addr_t)0x10);
+  ASSERT_EQ(set.getDescriptorsSize(), 4U);

ZequanWu wrote:

Switched to use `DWARFDebugAranges` in this test. I think adding `operator==` 
is the same as using `getDescriptiorRef` and `getDescriptorsSize` because 
`operator==` is only used in the lldb test.

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

[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)

[David Spickett via lldb-commits]

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

LGTM.

Maybe @labath would like to take a last look at it before it lands.

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

[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)

[via lldb-commits]

@@ -536,6 +536,33 @@ This command will run the thread in the current frame 
until it reaches line 100
 in this frame or stops if it leaves the current frame. This is a pretty close
 equivalent to GDB's ``until`` command.
 
+One other useful thing to note about the lldb stepping commands is that they
+are implemented as a stack of interruptible operations.  Until the operation -
+e.g. step to the next line - is completed, the operation will remain on the
+stack.  If it is interrupted, new stepping commands will result in their
+operations being pushed onto the stack, each of them retired as they are 
completed.
+
+Suppose, for instance, you ``step-over`` a source line, and hit a breakpoint
+in a function called by the code of the line you are stepping over.  Since the 
step-over
+operation remains on the stack, you can examine the state at
+the point of the breakpoint hit, step around in that frame, step in to other
+frames, hit other breakpoints, etc.  Then when you are done, a simple 
``continue``

jimingham wrote:

I thought about that, but if I did it the other way I'm telling you about 
stepping around without really motivating it are related to what I was just 
discussing. 

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

[Lldb-commits] [lldb] a4197e4 - Add docs describing how the thread plan stack affects stepping (#110167)

[via lldb-commits]

Author: jimingham
Date: 2024-09-27T09:36:52-07:00
New Revision: a4197e472823f51075c837f709da05a55ebc16d0

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

LOG: Add docs describing how the thread plan stack affects stepping (#110167)

This is a convenient little feature of lldb, but if you didn't know it
was there you'd likely never discover it.

Added: 


Modified: 
lldb/docs/use/tutorial.rst

Removed: 




diff  --git a/lldb/docs/use/tutorial.rst b/lldb/docs/use/tutorial.rst
index 00e7befdd087a4..76e8ac4aeab89c 100644
--- a/lldb/docs/use/tutorial.rst
+++ b/lldb/docs/use/tutorial.rst
@@ -536,6 +536,43 @@ This command will run the thread in the current frame 
until it reaches line 100
 in this frame or stops if it leaves the current frame. This is a pretty close
 equivalent to GDB's ``until`` command.
 
+One other useful thing to note about the lldb stepping commands is that they
+are implemented as a stack of interruptible operations.  Until the operation -
+e.g. step to the next line - is completed, it will remain on the
+stack.  If the step over is interrupted and control returned to you,
+any new stepping commands you issue won't replace the step-over, but instead
+their operations will be pushed onto the stack after the original step over.
+Then each of them will be retired as they are completed, finally returning to 
the
+original step over operation.
+
+Suppose, for instance, you ``step-over`` a source line with a function call.
+If there is a breakpoint in that function, hitting the breakpoint will 
interrupt
+the step over.  At that point, you will likely want to examine the state at
+the breakpoint, maybe stepping around in that frame, or stepping into other
+functions, running some expressions, etc.
+
+Because the original step-over has remained on the stack, when you've finished
+your examinations, a simple ``continue`` will resume the original ``step-over``
+operation, and you will arrive at the end of your starting source line in the
+original frame.
+
+This saves you from having to keep track of your original intention, and 
manually
+issuing the requisite number of ``step-out`` commands to get back to the frame
+you were stepping over.  The stack maintains that information for you.
+
+Hand-called functions using the ``expr`` command are also implemented by
+operations on this same stack.  So if you are calling some code with the 
``expr`` command,
+and hit a breakpoint during the evaluation of that code, you can examine
+the state where you stopped, and when you're satisfied,  issue a
+``continue`` to finish the expression evaluation operation and print the 
function
+result.
+
+You can examine the state of the operations stack using the ``thread plan 
list``
+command, and if, for instance, you decide you don't actually want that 
outermost
+next to continue running, you can remove it with the ``thread plan discard``
+command.  If you are interested in following this process in more detail, the
+``lldb step`` logging channel is useful source of information.
+
 A process, by default, will share the LLDB terminal with the inferior process.
 When in this mode, much like when debugging with GDB, when the process is
 running anything you type will go to the ``STDIN`` of the inferior process. To



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

[Lldb-commits] [lldb] [LLDB][ProcessELFCore] Add Description to ProcessELFCore/ELFThread stop reasons (PR #110065)

[Jacob Lalonde via lldb-commits]

Jlalond wrote:

> Seems reasonable, but you'll need to use the signal constants from 
> `UnixSignals` (looked up by string), as macros like `SIGBUS` might not exist 
> (windows) or might not have the right value (macos). (NativeThreadLinux can 
> get away with using them as it always runs on the host.)

You're referring to the properties in the ELFSignal object?

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

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Add breakpoint stop reasons to the minidump. (PR #108448)

[Jacob Lalonde via lldb-commits]

@@ -686,16 +692,10 @@ Status MinidumpFileBuilder::AddExceptions() {
   for (const ThreadSP &thread_sp : thread_list) {
 StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
 bool add_exception = false;
-if (stop_info_sp) {
-  switch (stop_info_sp->GetStopReason()) {
-  case eStopReasonSignal:
-  case eStopReasonException:
+if (stop_info_sp && 
thread_stop_reasons.count(stop_info_sp->GetStopReason()) > 0) {
 add_exception = true;
-break;
-  default:
-break;
-  }
 }
+

Jlalond wrote:

So I ended up just slapping the description in there and setting the flags with 
an LLDB flag, thoughts?

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

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Add breakpoint stop reasons to the minidump. (PR #108448)

[Jacob Lalonde via lldb-commits]

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

>From adcc5e8065d2a1b7edf877bd74de9cebd2f84cc9 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde 
Date: Thu, 12 Sep 2024 13:10:58 -0700
Subject: [PATCH 1/4] Create set for the stop reasons we collect, and add
 breakpoint to it.

---
 .../ObjectFile/Minidump/MinidumpFileBuilder.cpp | 13 +++--
 .../ObjectFile/Minidump/MinidumpFileBuilder.h   |  4 +++-
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp 
b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
index edc568a6b47e00..38e71e0e485d55 100644
--- a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
+++ b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
@@ -75,8 +75,7 @@ Status 
MinidumpFileBuilder::AddHeaderAndCalculateDirectories() {
 StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
 if (stop_info_sp) {
   const StopReason &stop_reason = stop_info_sp->GetStopReason();
-  if (stop_reason == StopReason::eStopReasonException ||
-  stop_reason == StopReason::eStopReasonSignal)
+  if (m_thread_stop_reasons.count(stop_reason) > 0)
 m_expected_directories++;
 }
   }
@@ -686,16 +685,10 @@ Status MinidumpFileBuilder::AddExceptions() {
   for (const ThreadSP &thread_sp : thread_list) {
 StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
 bool add_exception = false;
-if (stop_info_sp) {
-  switch (stop_info_sp->GetStopReason()) {
-  case eStopReasonSignal:
-  case eStopReasonException:
+if (stop_info_sp && 
m_thread_stop_reasons.count(stop_info_sp->GetStopReason()) > 0) {
 add_exception = true;
-break;
-  default:
-break;
-  }
 }
+
 if (add_exception) {
   constexpr size_t minidump_exception_size =
   sizeof(llvm::minidump::ExceptionStream);
diff --git a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h 
b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h
index 71001e26c00e91..569ba7fb07d871 100644
--- a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h
+++ b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h
@@ -168,7 +168,9 @@ class MinidumpFileBuilder {
   m_tid_to_reg_ctx;
   std::unordered_set m_saved_stack_ranges;
   lldb::FileUP m_core_file;
-  lldb_private::SaveCoreOptions m_save_core_options;
+  lldb_private::SaveCoreOptions m_save_core_options; 
+  const std::unordered_set m_thread_stop_reasons = 
{lldb::StopReason::eStopReasonException, lldb::StopReason::eStopReasonSignal,
+  lldb::StopReason::eStopReasonBreakpoint };
 };
 
 #endif // LLDB_SOURCE_PLUGINS_OBJECTFILE_MINIDUMP_MINIDUMPFILEBUILDER_H

>From 030b74c9e763c86d217da39487478e7cf2dff074 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde 
Date: Thu, 12 Sep 2024 13:30:04 -0700
Subject: [PATCH 2/4] Make const set with the stop reasons

---
 .../ObjectFile/Minidump/MinidumpFileBuilder.cpp   | 11 +--
 .../Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h |  4 +---
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp 
b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
index 38e71e0e485d55..0b69f1b8205610 100644
--- a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
+++ b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
@@ -54,6 +54,13 @@ using namespace lldb;
 using namespace lldb_private;
 using namespace llvm::minidump;
 
+// Set of all the stop reasons minidumps will collect.
+const std::unordered_set 
MinidumpFileBuilder::thread_stop_reasons {
+  lldb::StopReason::eStopReasonException,
+  lldb::StopReason::eStopReasonSignal,
+  lldb::StopReason::eStopReasonBreakpoint,
+};
+
 Status MinidumpFileBuilder::AddHeaderAndCalculateDirectories() {
   // First set the offset on the file, and on the bytes saved
   m_saved_data_size = HEADER_SIZE;
@@ -75,7 +82,7 @@ Status 
MinidumpFileBuilder::AddHeaderAndCalculateDirectories() {
 StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
 if (stop_info_sp) {
   const StopReason &stop_reason = stop_info_sp->GetStopReason();
-  if (m_thread_stop_reasons.count(stop_reason) > 0)
+  if (thread_stop_reasons.count(stop_reason) > 0)
 m_expected_directories++;
 }
   }
@@ -685,7 +692,7 @@ Status MinidumpFileBuilder::AddExceptions() {
   for (const ThreadSP &thread_sp : thread_list) {
 StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
 bool add_exception = false;
-if (stop_info_sp && 
m_thread_stop_reasons.count(stop_info_sp->GetStopReason()) > 0) {
+if (stop_info_sp && 
thread_stop_reasons.count(stop_info_sp->GetStopReason()) > 0) {
 add_exception = true;
 }
 
diff --git a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h 
b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h
index 56

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Add breakpoint stop reasons to the minidump. (PR #108448)

[Jacob Lalonde via lldb-commits]

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

>From adcc5e8065d2a1b7edf877bd74de9cebd2f84cc9 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde 
Date: Thu, 12 Sep 2024 13:10:58 -0700
Subject: [PATCH 1/5] Create set for the stop reasons we collect, and add
 breakpoint to it.

---
 .../ObjectFile/Minidump/MinidumpFileBuilder.cpp | 13 +++--
 .../ObjectFile/Minidump/MinidumpFileBuilder.h   |  4 +++-
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp 
b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
index edc568a6b47e00..38e71e0e485d55 100644
--- a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
+++ b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
@@ -75,8 +75,7 @@ Status 
MinidumpFileBuilder::AddHeaderAndCalculateDirectories() {
 StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
 if (stop_info_sp) {
   const StopReason &stop_reason = stop_info_sp->GetStopReason();
-  if (stop_reason == StopReason::eStopReasonException ||
-  stop_reason == StopReason::eStopReasonSignal)
+  if (m_thread_stop_reasons.count(stop_reason) > 0)
 m_expected_directories++;
 }
   }
@@ -686,16 +685,10 @@ Status MinidumpFileBuilder::AddExceptions() {
   for (const ThreadSP &thread_sp : thread_list) {
 StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
 bool add_exception = false;
-if (stop_info_sp) {
-  switch (stop_info_sp->GetStopReason()) {
-  case eStopReasonSignal:
-  case eStopReasonException:
+if (stop_info_sp && 
m_thread_stop_reasons.count(stop_info_sp->GetStopReason()) > 0) {
 add_exception = true;
-break;
-  default:
-break;
-  }
 }
+
 if (add_exception) {
   constexpr size_t minidump_exception_size =
   sizeof(llvm::minidump::ExceptionStream);
diff --git a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h 
b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h
index 71001e26c00e91..569ba7fb07d871 100644
--- a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h
+++ b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h
@@ -168,7 +168,9 @@ class MinidumpFileBuilder {
   m_tid_to_reg_ctx;
   std::unordered_set m_saved_stack_ranges;
   lldb::FileUP m_core_file;
-  lldb_private::SaveCoreOptions m_save_core_options;
+  lldb_private::SaveCoreOptions m_save_core_options; 
+  const std::unordered_set m_thread_stop_reasons = 
{lldb::StopReason::eStopReasonException, lldb::StopReason::eStopReasonSignal,
+  lldb::StopReason::eStopReasonBreakpoint };
 };
 
 #endif // LLDB_SOURCE_PLUGINS_OBJECTFILE_MINIDUMP_MINIDUMPFILEBUILDER_H

>From 030b74c9e763c86d217da39487478e7cf2dff074 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde 
Date: Thu, 12 Sep 2024 13:30:04 -0700
Subject: [PATCH 2/5] Make const set with the stop reasons

---
 .../ObjectFile/Minidump/MinidumpFileBuilder.cpp   | 11 +--
 .../Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h |  4 +---
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp 
b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
index 38e71e0e485d55..0b69f1b8205610 100644
--- a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
+++ b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
@@ -54,6 +54,13 @@ using namespace lldb;
 using namespace lldb_private;
 using namespace llvm::minidump;
 
+// Set of all the stop reasons minidumps will collect.
+const std::unordered_set 
MinidumpFileBuilder::thread_stop_reasons {
+  lldb::StopReason::eStopReasonException,
+  lldb::StopReason::eStopReasonSignal,
+  lldb::StopReason::eStopReasonBreakpoint,
+};
+
 Status MinidumpFileBuilder::AddHeaderAndCalculateDirectories() {
   // First set the offset on the file, and on the bytes saved
   m_saved_data_size = HEADER_SIZE;
@@ -75,7 +82,7 @@ Status 
MinidumpFileBuilder::AddHeaderAndCalculateDirectories() {
 StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
 if (stop_info_sp) {
   const StopReason &stop_reason = stop_info_sp->GetStopReason();
-  if (m_thread_stop_reasons.count(stop_reason) > 0)
+  if (thread_stop_reasons.count(stop_reason) > 0)
 m_expected_directories++;
 }
   }
@@ -685,7 +692,7 @@ Status MinidumpFileBuilder::AddExceptions() {
   for (const ThreadSP &thread_sp : thread_list) {
 StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
 bool add_exception = false;
-if (stop_info_sp && 
m_thread_stop_reasons.count(stop_info_sp->GetStopReason()) > 0) {
+if (stop_info_sp && 
thread_stop_reasons.count(stop_info_sp->GetStopReason()) > 0) {
 add_exception = true;
 }
 
diff --git a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h 
b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h
index 56

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

[Pavel Labath via lldb-commits]

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

The setting might be useful as well, though I think it would be even better if 
this was settable on a per-invocation basis (an argument to HandleCommand or 
something) -- the reason being that someone might still want to have this 
feature for commands which are input through the console (or from contexts 
where you can guarantee their placement), but not for commands which are 
executed e.g. from scripts. Here's one example:
```
(lldb) script lldb.debugger.HandleCommand('expression -- ""+2.5')
error: :1:3: invalid operands to binary expression ('const 
char[1]' and 'double')
1 | ""+2.5
  | ~~^~~~
```
You definitely won't point to the right place there. It's convoluted, I know, 
but it's not that unsimilar from I do when debugging lldb, where I sometimes 
run things like `self.dbg.HandleCommand` from the pdb prompt.

However this is workaroundable by changing the setting, so I don't want to hold 
this up further.

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

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

[Pavel Labath via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

[Pavel Labath via lldb-commits]

@@ -592,7 +592,18 @@ lldb::DWIMPrintVerbosity Debugger::GetDWIMPrintVerbosity() 
const {
   const uint32_t idx = ePropertyDWIMPrintVerbosity;
   return GetPropertyAtIndexAs(
   idx, static_cast(
-   g_debugger_properties[idx].default_uint_value));
+   g_debugger_properties[idx].default_uint_value != 0));

labath wrote:

Did you intend to change DWIM code?

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

[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)

[Felipe de Azevedo Piovezan via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

[via lldb-commits]

jimingham wrote:

This is a slightly orthogonal point, but I don't think we should confine this 
error visualization to just expressions.  If the user passes a non-boolean 
string to an option in a command, it would be helpful to point at the option 
for them, much as pointing to the part of the expression that doesn't parse is 
useful.  And if we're pointing at errors in expressions, it looks kind of odd 
that we don't do the same thing for other commands.

I'm not suggesting that that be part of this work, but when thinking about when 
this kind of thing would be appropriate I think would be unfortunate if we 
didn't allow the same feature at least for parsed commands.

Jim

> On Sep 27, 2024, at 2:00 AM, Pavel Labath ***@***.***> wrote:
> 
> 
> I'm actually surprised that lldb-dap sees the new diagnostics because I 
> thought it would run the expression through a lower-level API like 
> SBFrame::EvaluateExpression(). But I guess it just provides a "terminal" 
> window that passes everything through HandleCommand. To support this better, 
> I'm thinking about adding a setting to opt into the inline diagnostics that 
> only lldb sets, so we don't get unexpected results like this.
> 
> It has both. lldb-dap does this weird heuristic console multiplexing, where 
> it guesses whether something should be treated like an expression (I guess 
> that's because other VSCode debuggers do that), which is executed through 
> EvaluateExpression, or an lldb command, which is executed through 
> HandleCommand. So it's not very likely that a user will be running a 
> "command" to evaluate an expression, but I think it still illustrates my 
> point that HandleCommand can be (and probably is) invoked in contexts where 
> one cannot guarantee the alignment of the output.
> 
> —
> Reply to this email directly, view it on GitHub 
> , 
> or unsubscribe 
> .
> You are receiving this because you were mentioned.
> 



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

[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)

[Felipe de Azevedo Piovezan via lldb-commits]

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

[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)

[Felipe de Azevedo Piovezan via lldb-commits]

@@ -536,6 +536,33 @@ This command will run the thread in the current frame 
until it reaches line 100
 in this frame or stops if it leaves the current frame. This is a pretty close
 equivalent to GDB's ``until`` command.
 
+One other useful thing to note about the lldb stepping commands is that they
+are implemented as a stack of interruptible operations.  Until the operation -
+e.g. step to the next line - is completed, the operation will remain on the
+stack.  If it is interrupted, new stepping commands will result in their
+operations being pushed onto the stack, each of them retired as they are 
completed.
+
+Suppose, for instance, you ``step-over`` a source line, and hit a breakpoint
+in a function called by the code of the line you are stepping over.  Since the 
step-over
+operation remains on the stack, you can examine the state at
+the point of the breakpoint hit, step around in that frame, step in to other
+frames, hit other breakpoints, etc.  Then when you are done, a simple 
``continue``
+will resume the original ``step-over`` operation, only ending when the desired 
line is reached.
+This saves you from having to manually issue some number of ``step-out`` 
commands
+to get back to the frame you were stepping over.
+
+Hand-called functions using the ``expr`` command are also implemented by
+operations on this same stack.  So if you are calling some code with the 
``expr`` command,
+and hit a breakpoint during the evaluation of that code, you can examine
+the state where you stopped, step around at your convenience, and then issue a
+``continue`` which will finish the expression evaluation operation and print 
the function
+result.
+
+You can examine the state of the operations stack using the ``thread plan 
list``
+command, and if, for instance, you decide you don't actually want that 
outermost
+next to continue running, you can remove it with the ``thread plan discard``
+command.
+

felipepiovezan wrote:

Do you mean the `step` channel? There is a lot of detailed output there, I'm 
not sure we want the average `tutorial.rst` reader to be pointed that way...

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

[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)

[Felipe de Azevedo Piovezan via lldb-commits]

@@ -536,6 +536,33 @@ This command will run the thread in the current frame 
until it reaches line 100
 in this frame or stops if it leaves the current frame. This is a pretty close
 equivalent to GDB's ``until`` command.
 
+One other useful thing to note about the lldb stepping commands is that they
+are implemented as a stack of interruptible operations.  Until the operation -
+e.g. step to the next line - is completed, the operation will remain on the
+stack.  If it is interrupted, new stepping commands will result in their
+operations being pushed onto the stack, each of them retired as they are 
completed.
+
+Suppose, for instance, you ``step-over`` a source line, and hit a breakpoint
+in a function called by the code of the line you are stepping over.  Since the 
step-over
+operation remains on the stack, you can examine the state at
+the point of the breakpoint hit, step around in that frame, step in to other
+frames, hit other breakpoints, etc.  Then when you are done, a simple 
``continue``

felipepiovezan wrote:

Feel free to push on this, but I think the big gap between the cause (1) and 
effect (2) here can be detrimental to the point you are trying to make:
1) "Since the step-over operation remains on the stack..."  and 2) "when you 
are done, a simple ``continue`` will resume the original step-over...".

Maybe we could remove the "Since" clause (1) and fold it into 2? Something like:

You can examine [...]. When you are done, _because the step-over operation 
remains on the stack_, a simple ``continue``...

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

[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)

[Felipe de Azevedo Piovezan via lldb-commits]

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

[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)

[Felipe de Azevedo Piovezan via lldb-commits]

@@ -536,6 +536,33 @@ This command will run the thread in the current frame 
until it reaches line 100
 in this frame or stops if it leaves the current frame. This is a pretty close
 equivalent to GDB's ``until`` command.
 
+One other useful thing to note about the lldb stepping commands is that they
+are implemented as a stack of interruptible operations.  Until the operation -
+e.g. step to the next line - is completed, the operation will remain on the

felipepiovezan wrote:

At the risk of releasing the bike-shedding kraken, I personally dislike some 
pronouns in technical docs. It's very easy to accidentally create ambiguity 
with pronouns, though this suggestion is safe.

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

[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)

[Felipe de Azevedo Piovezan via lldb-commits]

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

LGTM! I learned something new reading this!

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

[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)

[Felipe de Azevedo Piovezan via lldb-commits]

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

[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)

[Felipe de Azevedo Piovezan via lldb-commits]

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

[Lldb-commits] [lldb] Improve type lookup using .debug_names parent chain (PR #108907)

[Pavel Labath via lldb-commits]

@@ -301,7 +301,8 @@ using Entry = llvm::DWARFDebugNames::Entry;
 /// If any parent does not have an `IDX_parent`, or the Entry data is 
corrupted,
 /// nullopt is returned.
 std::optional>
-getParentChain(Entry entry, uint32_t max_parents) {
+getParentChain(Entry entry,
+   uint32_t max_parents = std::numeric_limits::max()) {
   llvm::SmallVector parent_entries;

labath wrote:

The first one. Basically, if you try something like `clang++ -o - -c -g 
-gpubnames -fdebug-types-section -x c++ - <<<"struct A { struct B {}; }; A a; 
A::B b;"`, you'll see that the entry for `B` has no DW_IDX_parent attribute (I 
think it could have it, but we'd have to figure out what exactly it should 
refer to).

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

[Lldb-commits] [lldb] Improve namespace lookup review (PR #110062)

[Pavel Labath via lldb-commits]

labath wrote:

> This is a stack PR from #108907, so please review the new namespaces lookup 
> changes and ignore the changes in #108907. Let me know if there is a way to 
> only show the delta changes (not merged view).

That should be possible if you arrange the PR to only contain two commits, 
where the first one is the dependent PR, and the second one is the new changes.

I know that means you'll need to rebase (instead of merging) the PR when 
incorporating changes (which isn't exactly encouraged on github), but I think 
that's the lesser of two evils. When both of the PRs are touching the same set 
of files, it's very hard to separate the two in your head.

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

[Lldb-commits] [lldb] [LLDB][ProcessELFCore] Add Description to ProcessELFCore/ELFThread stop reasons (PR #110065)

[Jacob Lalonde via lldb-commits]

Jlalond wrote:

> So does this not need new testing or did you not add that yet?
> 
> I'm not clear on what fully decode means because at least for certain signals 
> like a tag check fault we do have a description for live processes and core 
> files. Perhaps that's because I added those as special cases I don't remember 
> the specifics.

I actually tried to yamlize one of my test crash dumps. The issue I encountered 
was the PT_NOTE sections wasn't being generated with content. Is there a way 
with obj2yaml to generate PT_NOTES with content?

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

[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)

[via lldb-commits]

@@ -536,6 +536,33 @@ This command will run the thread in the current frame 
until it reaches line 100
 in this frame or stops if it leaves the current frame. This is a pretty close
 equivalent to GDB's ``until`` command.
 
+One other useful thing to note about the lldb stepping commands is that they
+are implemented as a stack of interruptible operations.  Until the operation -
+e.g. step to the next line - is completed, the operation will remain on the
+stack.  If it is interrupted, new stepping commands will result in their
+operations being pushed onto the stack, each of them retired as they are 
completed.
+
+Suppose, for instance, you ``step-over`` a source line, and hit a breakpoint
+in a function called by the code of the line you are stepping over.  Since the 
step-over
+operation remains on the stack, you can examine the state at
+the point of the breakpoint hit, step around in that frame, step in to other
+frames, hit other breakpoints, etc.  Then when you are done, a simple 
``continue``
+will resume the original ``step-over`` operation, only ending when the desired 
line is reached.
+This saves you from having to manually issue some number of ``step-out`` 
commands
+to get back to the frame you were stepping over.
+
+Hand-called functions using the ``expr`` command are also implemented by
+operations on this same stack.  So if you are calling some code with the 
``expr`` command,
+and hit a breakpoint during the evaluation of that code, you can examine
+the state where you stopped, step around at your convenience, and then issue a
+``continue`` which will finish the expression evaluation operation and print 
the function
+result.
+
+You can examine the state of the operations stack using the ``thread plan 
list``
+command, and if, for instance, you decide you don't actually want that 
outermost
+next to continue running, you can remove it with the ``thread plan discard``
+command.
+

jimingham wrote:

It's a fire-hose for sure, but OTOH, it's the only way to watch the machinery 
happen.  It will be clear right away when you turn it on whether that info is 
for you or not...

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

[Lldb-commits] [lldb] [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (PR #106442)

[Adrian Prantl via lldb-commits]

https://github.com/adrian-prantl updated 
https://github.com/llvm/llvm-project/pull/106442

>From a2728d10df151c2fd552c988827d27155b9e7055 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 28 Aug 2024 10:04:33 -0700
Subject: [PATCH] [lldb] Store expression evaluator diagnostics in an
 llvm::Error (NFC)

This patch is a reworking of Pete Lawrence's (@PortalPete) proposal
for better expression evaluator error messages:
https://github.com/llvm/llvm-project/pull/80938

This patch is preparatory patch for improving the rendering of
expression evaluator diagnostics. Currently diagnostics are rendered
into a string and the command interpreter layer then textually parses
words like "error:" to (sometimes) color the output accordingly. In
order to enable user interfaces to do better with diagnostics, we need
to store them in a machine-readable fromat. This patch does this by
adding a new llvm::Error kind wrapping a DiagnosticDetail struct that
is used when the error type is eErrorTypeExpression. Multiple
diagnostics are modeled using llvm::ErrorList.

Right now the extra information is not used by the CommandInterpreter,
this will be added in a follow-up patch!
---
 .../lldb/Expression/DiagnosticManager.h   |  88 +++
 lldb/include/lldb/Utility/Status.h|  28 ++---
 lldb/source/Breakpoint/BreakpointLocation.cpp |  11 +-
 lldb/source/Expression/DiagnosticManager.cpp  | 103 +++---
 lldb/source/Expression/ExpressionParser.cpp   |   5 +-
 lldb/source/Expression/UserExpression.cpp |  49 +
 lldb/source/Expression/UtilityFunction.cpp|  18 +--
 .../ExpressionParser/Clang/ClangDiagnostic.h  |   5 +-
 .../Clang/ClangExpressionParser.cpp   |  69 
 .../Clang/ClangUserExpression.h   |   2 +
 .../Plugins/Platform/POSIX/PlatformPOSIX.cpp  |  12 +-
 .../Platform/Windows/PlatformWindows.cpp  |  12 +-
 lldb/source/Target/Target.cpp |   3 +-
 lldb/source/Utility/Status.cpp|  67 +---
 .../TestModulesCompileError.py|   2 +-
 .../Expression/DiagnosticManagerTest.cpp  |  22 +++-
 16 files changed, 321 insertions(+), 175 deletions(-)

diff --git a/lldb/include/lldb/Expression/DiagnosticManager.h 
b/lldb/include/lldb/Expression/DiagnosticManager.h
index d49b7c99b114fb..62c6bcefe54110 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -12,6 +12,9 @@
 #include "lldb/lldb-defines.h"
 #include "lldb/lldb-types.h"
 
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/Status.h"
+
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 
@@ -20,6 +23,53 @@
 
 namespace lldb_private {
 
+/// A compiler-independent representation of a Diagnostic. Expression
+/// evaluation failures often have more than one diagnostic that a UI
+/// layer might want to render differently, for example to colorize
+/// it.
+///
+/// Running example:
+///   (lldb) expr 1+foo
+///   error: :1:3: use of undeclared identifier 'foo'
+///   1+foo
+/// ^
+struct DiagnosticDetail {
+  struct SourceLocation {
+FileSpec file;
+unsigned line = 0;
+uint16_t column = 0;
+uint16_t length = 0;
+bool in_user_input = false;
+  };
+  /// Contains {{}, 1, 3, 3, true} in the example above.
+  std::optional source_location;
+  /// Contains eSeverityError in the example above.
+  lldb::Severity severity = lldb::eSeverityInfo;
+  /// Contains "use of undeclared identifier 'x'" in the example above.
+  std::string message;
+  /// Contains the fully rendered error message.
+  std::string rendered;
+};
+
+/// An llvm::Error used to communicate diagnostics in Status. Multiple
+/// diagnostics may be chained in an llvm::ErrorList.
+class ExpressionError
+: public llvm::ErrorInfo {
+  std::string m_message;
+  std::vector m_details;
+
+public:
+  static char ID;
+  using llvm::ErrorInfo::ErrorInfo;
+  ExpressionError(lldb::ExpressionResults result, std::string msg,
+  std::vector details = {});
+  std::string message() const override;
+  llvm::ArrayRef GetDetails() const { return m_details; }
+  std::error_code convertToErrorCode() const override;
+  void log(llvm::raw_ostream &OS) const override;
+  std::unique_ptr Clone() const override;
+};
+
 enum DiagnosticOrigin {
   eDiagnosticOriginUnknown = 0,
   eDiagnosticOriginLLDB,
@@ -49,37 +99,28 @@ class Diagnostic {
 }
   }
 
-  Diagnostic(llvm::StringRef message, lldb::Severity severity,
- DiagnosticOrigin origin, uint32_t compiler_id)
-  : m_message(message), m_severity(severity), m_origin(origin),
-m_compiler_id(compiler_id) {}
-
-  Diagnostic(const Diagnostic &rhs)
-  : m_message(rhs.m_message), m_severity(rhs.m_severity),
-m_origin(rhs.m_origin), m_compiler_id(rhs.m_compiler_id) {}
+  Diagnostic(DiagnosticOrigin origin, uint32_t compiler_id,
+ DiagnosticDetail detail)
+  : m_origin(origin), m_compiler_i

[Lldb-commits] [lldb] f6e771c - [lldb][Docs] Convert AArch64 Linux doc to Markdown

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2024-09-27T13:31:58+01:00
New Revision: f6e771cfeda5527b817c80e86d2352cf1f3e5e37

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

LOG: [lldb][Docs] Convert AArch64 Linux doc to Markdown

Executive decision from me given that I am the sole author
of the doc and there's nothing Markdown can't handle here.

Added: 
lldb/docs/use/aarch64-linux.md

Modified: 


Removed: 
lldb/docs/use/aarch64-linux.rst



diff  --git a/lldb/docs/use/aarch64-linux.rst b/lldb/docs/use/aarch64-linux.md
similarity index 61%
rename from lldb/docs/use/aarch64-linux.rst
rename to lldb/docs/use/aarch64-linux.md
index c790d9d369a480..803f56d16f981e 100644
--- a/lldb/docs/use/aarch64-linux.rst
+++ b/lldb/docs/use/aarch64-linux.md
@@ -1,5 +1,4 @@
-Using LLDB On AArch64 Linux
-===
+# Using LLDB On AArch64 Linux
 
 This page explains the details of debugging certain AArch64 extensions using
 LLDB. If something is not mentioned here, it likely works as you would expect.
@@ -8,23 +7,21 @@ This is not a replacement for ptrace and Linux Kernel 
documentation. This covers
 how LLDB has chosen to use those things and how that effects your experience as
 a user.
 
-Scalable Vector Extension (SVE)

+## Scalable Vector Extension (SVE)
 
-See `here 
`__
-to learn about the extension and `here 
`__
+See 
[here](https://developer.arm.com/Architectures/Scalable%20Vector%20Extensions)
+to learn about the extension and 
[here](https://kernel.org/doc/html/latest/arch/arm64/sve.html)
 for the Linux Kernel's handling of it.
 
 In LLDB you will be able to see the following new registers:
 
-* ``z0-z31`` vector registers, each one has size equal to the vector length.
-* ``p0-p15`` predicate registers, each one containing 1 bit per byte in the 
vector
+* `z0-z31` vector registers, each one has size equal to the vector length.
+* `p0-p15` predicate registers, each one containing 1 bit per byte in the 
vector
   length. Making each one vector length / 8 sized.
-* ``ffr`` the first fault register, same size as a predicate register.
-* ``vg``, the vector length in "granules". Each granule is 8 bytes.
-
-.. code-block::
+* `ffr` the first fault register, same size as a predicate register.
+* `vg`, the vector length in "granules". Each granule is 8 bytes.
 
+```
Scalable Vector Extension Registers:
  vg = 0x0002
  z0 = {0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 <...> }
@@ -32,19 +29,19 @@ In LLDB you will be able to see the following new registers:
  p0 = {0xff 0xff}
<...>
 ffr = {0xff 0xff}
+```
 
 The example above has a vector length of 16 bytes. Within LLDB you will always
-see "vg" as in the ``vg`` register, which is 2 in this case (8*2 = 16).
+see "vg" as in the `vg` register, which is 2 in this case (8*2 = 16).
 Elsewhere in kernel code or applications, you may see "vq" which is the vector
 length in quadwords (16 bytes). Where you see "vl", it is in bytes.
 
-While you can count the size of a P or Z register, it is intended that ``vg`` 
be
+While you can count the size of a P or Z register, it is intended that `vg` be
 used to find the current vector length.
 
-Changing the Vector Length
-..
+### Changing the Vector Length
 
-The ``vg`` register can be written during a debug session. Writing the current
+The `vg` register can be written during a debug session. Writing the current
 vector length changes nothing. If you increase the vector length, the registers
 will likely be reset to 0. If you decrease it, LLDB will truncate the Z
 registers but everything else will be reset to 0.
@@ -54,21 +51,20 @@ way the same as it was previously. Whether that is done 
from within the
 debuggee, or by LLDB. If you need to change the vector length, do so before a
 function's first use of SVE.
 
-Z Register Presentation
-...
+### Z Register Presentation
 
 LLDB makes no attempt to predict how SVE Z registers will be used. Since LLDB
 does not know what sort of elements future instructions will interpret the
 register as. It therefore does not change the visualisation of the register
 and always defaults to showing a vector of byte sized elements.
 
-If you know what format you are going to use, give a format option::
-
+If you know what format you are going to use, give a format option:
+```
   (lldb) register read z0 -f uint32_t[]
   z0 = {0x01010101 0x01010101 0x01010101 0x01010101}
+```
 
-FPSIMD and SVE Modes
-
+### FPSIMD and SVE Modes
 
 Prior to the debugee's first use of SVE, it is in

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

[Adrian Prantl via lldb-commits]

https://github.com/adrian-prantl updated 
https://github.com/llvm/llvm-project/pull/106470

>From 4f57669afd3d9e7475c0e44976eaa9b534883152 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 28 Aug 2024 16:19:21 -0700
Subject: [PATCH] [lldb] Inline expression evaluator error visualization
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This patch is a reworking of Pete Lawrence's (@PortalPete) proposal
for better expression evaluator error messages:
https://github.com/llvm/llvm-project/pull/80938

Before:

```
$ lldb -o "expr a+b"
(lldb) expr a+b
error: :1:1: use of undeclared identifier 'a'
a+b
^
error: :1:3: use of undeclared identifier 'b'
a+b
  ^
```

After:

```
(lldb) expr a+b
^ ^
│ ╰─ error: use of undeclared identifier 'b'
╰─ error: use of undeclared identifier 'a'
```

This eliminates the confusing `:1:3` source
location and avoids echoing the expression to the console again, which
results in a cleaner presentation that makes it easier to grasp what's
going on.
---
 lldb/include/lldb/API/SBDebugger.h|   2 +
 lldb/include/lldb/Core/Debugger.h |   4 +
 .../lldb/Expression/DiagnosticManager.h   |   1 +
 lldb/include/lldb/Interpreter/CommandObject.h |   8 +
 lldb/source/API/SBDebugger.cpp|   6 +
 .../Commands/CommandObjectExpression.cpp  | 154 --
 lldb/source/Core/CoreProperties.td|   4 +
 lldb/source/Core/Debugger.cpp |  13 +-
 lldb/source/Expression/DiagnosticManager.cpp  |   2 +-
 .../source/Interpreter/CommandInterpreter.cpp |   4 +-
 .../Clang/ClangExpressionParser.cpp   |  27 +--
 .../ctf/CommandObjectThreadTraceExportCTF.h   |   2 +-
 .../diagnostics/TestExprDiagnostics.py|  51 ++
 .../TestPersistentVariables.py|   4 +-
 .../TestStaticInitializers.py |   2 +-
 .../TestTemplateFunctions.py  |   3 +-
 .../test/API/lang/mixed/TestMixedLanguages.py |   2 +-
 lldb/test/Shell/Expr/TestObjCIDCast.test  |   2 +-
 .../test/Shell/Expr/TestObjCInCXXContext.test |   2 +-
 .../NativePDB/incomplete-tag-type.cpp |   4 +-
 lldb/tools/driver/Driver.cpp  |   1 +
 .../Expression/DiagnosticManagerTest.cpp  |  33 ++--
 lldb/unittests/Interpreter/CMakeLists.txt |   1 +
 .../TestCommandObjectExpression.cpp   |  34 
 24 files changed, 315 insertions(+), 51 deletions(-)
 create mode 100644 lldb/unittests/Interpreter/TestCommandObjectExpression.cpp

diff --git a/lldb/include/lldb/API/SBDebugger.h 
b/lldb/include/lldb/API/SBDebugger.h
index 84ea9c0f772e16..6afa1c932ab050 100644
--- a/lldb/include/lldb/API/SBDebugger.h
+++ b/lldb/include/lldb/API/SBDebugger.h
@@ -304,6 +304,8 @@ class LLDB_API SBDebugger {
 
   bool GetUseColor() const;
 
+  bool SetShowInlineDiagnostics(bool);
+
   bool SetUseSourceCache(bool use_source_cache);
 
   bool GetUseSourceCache() const;
diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index a72c2596cc2c5e..1d5f2fcc20626c 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -364,6 +364,10 @@ class Debugger : public 
std::enable_shared_from_this,
 
   const std::string &GetInstanceName() { return m_instance_name; }
 
+  bool GetShowInlineDiagnostics() const;
+
+  bool SetShowInlineDiagnostics(bool);
+
   bool LoadPlugin(const FileSpec &spec, Status &error);
 
   void RunIOHandlers();
diff --git a/lldb/include/lldb/Expression/DiagnosticManager.h 
b/lldb/include/lldb/Expression/DiagnosticManager.h
index 62c6bcefe54110..b9a6421577781e 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -39,6 +39,7 @@ struct DiagnosticDetail {
 unsigned line = 0;
 uint16_t column = 0;
 uint16_t length = 0;
+bool hidden = false;
 bool in_user_input = false;
   };
   /// Contains {{}, 1, 3, 3, true} in the example above.
diff --git a/lldb/include/lldb/Interpreter/CommandObject.h 
b/lldb/include/lldb/Interpreter/CommandObject.h
index 20c4769af90338..c5167e5e0ecb6a 100644
--- a/lldb/include/lldb/Interpreter/CommandObject.h
+++ b/lldb/include/lldb/Interpreter/CommandObject.h
@@ -340,6 +340,13 @@ class CommandObject : public 
std::enable_shared_from_this {
   return false;
   }
 
+  /// Set the command input as it appeared in the terminal. This
+  /// is used to have errors refer directly to the original command.
+  void SetOriginalCommandString(std::string s) { m_original_command = s; }
+
+  /// \param offset_in_command is on what column \c args_string
+  /// appears, if applicable. This enables diagnostics that refer back
+  /// to the user input.
   virtual void Execute(const char *args_string,
CommandReturnObject &result) = 0;
 
@@ -404,6 +411,7 @@ class CommandObject : public 
std::enable_shared_from_this {
   std::string m_cmd_help_short;
   st

[Lldb-commits] [lldb] 49372d1 - [lldb] Inline expression evaluator error visualization (#106470)

[via lldb-commits]

Author: Adrian Prantl
Date: 2024-09-27T16:32:35-07:00
New Revision: 49372d1cccf50f404d52d40ae4b663db5604eb2c

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

LOG: [lldb] Inline expression evaluator error visualization (#106470)

This patch is a reworking of Pete Lawrence's (@PortalPete) proposal
for better expression evaluator error messages:
https://github.com/llvm/llvm-project/pull/80938

Before:

```
$ lldb -o "expr a+b"
(lldb) expr a+b
error: :1:1: use of undeclared identifier 'a'
a+b
^
error: :1:3: use of undeclared identifier 'b'
a+b
  ^
```

After:

```
(lldb) expr a+b
^ ^
│ ╰─ error: use of undeclared identifier 'b'
╰─ error: use of undeclared identifier 'a'
```

This eliminates the confusing `:1:3` source
location and avoids echoing the expression to the console again, which
results in a cleaner presentation that makes it easier to grasp what's
going on. You can't see it here, bug the word "error" is now also in
color, if so desired.

Depends on https://github.com/llvm/llvm-project/pull/106442.

Added: 
lldb/unittests/Interpreter/TestCommandObjectExpression.cpp

Modified: 
lldb/include/lldb/API/SBDebugger.h
lldb/include/lldb/Core/Debugger.h
lldb/include/lldb/Expression/DiagnosticManager.h
lldb/include/lldb/Interpreter/CommandObject.h
lldb/source/API/SBDebugger.cpp
lldb/source/Commands/CommandObjectExpression.cpp
lldb/source/Core/CoreProperties.td
lldb/source/Core/Debugger.cpp
lldb/source/Expression/DiagnosticManager.cpp
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
lldb/source/Plugins/TraceExporter/ctf/CommandObjectThreadTraceExportCTF.h
lldb/test/API/commands/expression/diagnostics/TestExprDiagnostics.py

lldb/test/API/commands/expression/persistent_variables/TestPersistentVariables.py

lldb/test/API/commands/expression/static-initializers/TestStaticInitializers.py
lldb/test/API/lang/cpp/template-function/TestTemplateFunctions.py
lldb/test/API/lang/mixed/TestMixedLanguages.py
lldb/test/Shell/Expr/TestObjCIDCast.test
lldb/test/Shell/Expr/TestObjCInCXXContext.test
lldb/test/Shell/SymbolFile/NativePDB/incomplete-tag-type.cpp
lldb/tools/driver/Driver.cpp
lldb/unittests/Expression/DiagnosticManagerTest.cpp
lldb/unittests/Interpreter/CMakeLists.txt

Removed: 




diff  --git a/lldb/include/lldb/API/SBDebugger.h 
b/lldb/include/lldb/API/SBDebugger.h
index 84ea9c0f772e16..6afa1c932ab050 100644
--- a/lldb/include/lldb/API/SBDebugger.h
+++ b/lldb/include/lldb/API/SBDebugger.h
@@ -304,6 +304,8 @@ class LLDB_API SBDebugger {
 
   bool GetUseColor() const;
 
+  bool SetShowInlineDiagnostics(bool);
+
   bool SetUseSourceCache(bool use_source_cache);
 
   bool GetUseSourceCache() const;

diff  --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index a72c2596cc2c5e..1d5f2fcc20626c 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -364,6 +364,10 @@ class Debugger : public 
std::enable_shared_from_this,
 
   const std::string &GetInstanceName() { return m_instance_name; }
 
+  bool GetShowInlineDiagnostics() const;
+
+  bool SetShowInlineDiagnostics(bool);
+
   bool LoadPlugin(const FileSpec &spec, Status &error);
 
   void RunIOHandlers();

diff  --git a/lldb/include/lldb/Expression/DiagnosticManager.h 
b/lldb/include/lldb/Expression/DiagnosticManager.h
index 62c6bcefe54110..b9a6421577781e 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -39,6 +39,7 @@ struct DiagnosticDetail {
 unsigned line = 0;
 uint16_t column = 0;
 uint16_t length = 0;
+bool hidden = false;
 bool in_user_input = false;
   };
   /// Contains {{}, 1, 3, 3, true} in the example above.

diff  --git a/lldb/include/lldb/Interpreter/CommandObject.h 
b/lldb/include/lldb/Interpreter/CommandObject.h
index 20c4769af90338..c5167e5e0ecb6a 100644
--- a/lldb/include/lldb/Interpreter/CommandObject.h
+++ b/lldb/include/lldb/Interpreter/CommandObject.h
@@ -340,6 +340,13 @@ class CommandObject : public 
std::enable_shared_from_this {
   return false;
   }
 
+  /// Set the command input as it appeared in the terminal. This
+  /// is used to have errors refer directly to the original command.
+  void SetOriginalCommandString(std::string s) { m_original_command = s; }
+
+  /// \param offset_in_command is on what column \c args_string
+  /// appears, if applicable. This enables diagnostics that refer back
+  /// to the user input.
   virtual void Execute(const char *args_string,
CommandReturnObject &result) = 0;
 
@@ -404,6 +411,7 @@ class CommandObject : publi

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

[Adrian Prantl via lldb-commits]

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

[Lldb-commits] [lldb] 8536d48 - Add missing dependency to unit test

[Adrian Prantl via lldb-commits]

Author: Adrian Prantl
Date: 2024-09-27T16:51:24-07:00
New Revision: 8536d483d72119f9556a9d685c32d5fca0c3d9c1

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

LOG: Add missing dependency to unit test

Added: 


Modified: 
lldb/unittests/Interpreter/CMakeLists.txt

Removed: 




diff  --git a/lldb/unittests/Interpreter/CMakeLists.txt 
b/lldb/unittests/Interpreter/CMakeLists.txt
index 14a7d6c5610388..f7d639f50f5bf3 100644
--- a/lldb/unittests/Interpreter/CMakeLists.txt
+++ b/lldb/unittests/Interpreter/CMakeLists.txt
@@ -9,6 +9,7 @@ add_lldb_unittest(InterpreterTests
   TestRegexCommand.cpp
 
   LINK_LIBS
+  lldbCommands
   lldbCore
   lldbHost
   lldbTarget



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

[Lldb-commits] [lldb] 2ddcc4e - Revert "Add missing dependency to unit test"

[Adrian Prantl via lldb-commits]

Author: Adrian Prantl
Date: 2024-09-27T17:05:37-07:00
New Revision: 2ddcc4e6b212bf91459689c40049ddedf360a448

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

LOG: Revert "Add missing dependency to unit test"

This reverts commit 8536d483d72119f9556a9d685c32d5fca0c3d9c1.

Added: 


Modified: 
lldb/unittests/Interpreter/CMakeLists.txt

Removed: 




diff  --git a/lldb/unittests/Interpreter/CMakeLists.txt 
b/lldb/unittests/Interpreter/CMakeLists.txt
index f7d639f50f5bf3..14a7d6c5610388 100644
--- a/lldb/unittests/Interpreter/CMakeLists.txt
+++ b/lldb/unittests/Interpreter/CMakeLists.txt
@@ -9,7 +9,6 @@ add_lldb_unittest(InterpreterTests
   TestRegexCommand.cpp
 
   LINK_LIBS
-  lldbCommands
   lldbCore
   lldbHost
   lldbTarget



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

[Lldb-commits] [lldb] 41dca01 - Revert "[lldb] Inline expression evaluator error visualization (#106470)"

[Adrian Prantl via lldb-commits]

Author: Adrian Prantl
Date: 2024-09-27T17:05:37-07:00
New Revision: 41dca012e5d6a1f8dff640ec82245bb5152e9fb8

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

LOG: Revert "[lldb] Inline expression evaluator error visualization (#106470)"

This reverts commit 49372d1cccf50f404d52d40ae4b663db5604eb2c.

Added: 


Modified: 
lldb/include/lldb/API/SBDebugger.h
lldb/include/lldb/Core/Debugger.h
lldb/include/lldb/Expression/DiagnosticManager.h
lldb/include/lldb/Interpreter/CommandObject.h
lldb/source/API/SBDebugger.cpp
lldb/source/Commands/CommandObjectExpression.cpp
lldb/source/Core/CoreProperties.td
lldb/source/Core/Debugger.cpp
lldb/source/Expression/DiagnosticManager.cpp
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
lldb/source/Plugins/TraceExporter/ctf/CommandObjectThreadTraceExportCTF.h
lldb/test/API/commands/expression/diagnostics/TestExprDiagnostics.py

lldb/test/API/commands/expression/persistent_variables/TestPersistentVariables.py

lldb/test/API/commands/expression/static-initializers/TestStaticInitializers.py
lldb/test/API/lang/cpp/template-function/TestTemplateFunctions.py
lldb/test/API/lang/mixed/TestMixedLanguages.py
lldb/test/Shell/Expr/TestObjCIDCast.test
lldb/test/Shell/Expr/TestObjCInCXXContext.test
lldb/test/Shell/SymbolFile/NativePDB/incomplete-tag-type.cpp
lldb/tools/driver/Driver.cpp
lldb/unittests/Expression/DiagnosticManagerTest.cpp
lldb/unittests/Interpreter/CMakeLists.txt

Removed: 
lldb/unittests/Interpreter/TestCommandObjectExpression.cpp



diff  --git a/lldb/include/lldb/API/SBDebugger.h 
b/lldb/include/lldb/API/SBDebugger.h
index 6afa1c932ab050..84ea9c0f772e16 100644
--- a/lldb/include/lldb/API/SBDebugger.h
+++ b/lldb/include/lldb/API/SBDebugger.h
@@ -304,8 +304,6 @@ class LLDB_API SBDebugger {
 
   bool GetUseColor() const;
 
-  bool SetShowInlineDiagnostics(bool);
-
   bool SetUseSourceCache(bool use_source_cache);
 
   bool GetUseSourceCache() const;

diff  --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 1d5f2fcc20626c..a72c2596cc2c5e 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -364,10 +364,6 @@ class Debugger : public 
std::enable_shared_from_this,
 
   const std::string &GetInstanceName() { return m_instance_name; }
 
-  bool GetShowInlineDiagnostics() const;
-
-  bool SetShowInlineDiagnostics(bool);
-
   bool LoadPlugin(const FileSpec &spec, Status &error);
 
   void RunIOHandlers();

diff  --git a/lldb/include/lldb/Expression/DiagnosticManager.h 
b/lldb/include/lldb/Expression/DiagnosticManager.h
index b9a6421577781e..62c6bcefe54110 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -39,7 +39,6 @@ struct DiagnosticDetail {
 unsigned line = 0;
 uint16_t column = 0;
 uint16_t length = 0;
-bool hidden = false;
 bool in_user_input = false;
   };
   /// Contains {{}, 1, 3, 3, true} in the example above.

diff  --git a/lldb/include/lldb/Interpreter/CommandObject.h 
b/lldb/include/lldb/Interpreter/CommandObject.h
index c5167e5e0ecb6a..20c4769af90338 100644
--- a/lldb/include/lldb/Interpreter/CommandObject.h
+++ b/lldb/include/lldb/Interpreter/CommandObject.h
@@ -340,13 +340,6 @@ class CommandObject : public 
std::enable_shared_from_this {
   return false;
   }
 
-  /// Set the command input as it appeared in the terminal. This
-  /// is used to have errors refer directly to the original command.
-  void SetOriginalCommandString(std::string s) { m_original_command = s; }
-
-  /// \param offset_in_command is on what column \c args_string
-  /// appears, if applicable. This enables diagnostics that refer back
-  /// to the user input.
   virtual void Execute(const char *args_string,
CommandReturnObject &result) = 0;
 
@@ -411,7 +404,6 @@ class CommandObject : public 
std::enable_shared_from_this {
   std::string m_cmd_help_short;
   std::string m_cmd_help_long;
   std::string m_cmd_syntax;
-  std::string m_original_command;
   Flags m_flags;
   std::vector m_arguments;
   lldb::CommandOverrideCallback m_deprecated_command_override_callback;

diff  --git a/lldb/source/API/SBDebugger.cpp b/lldb/source/API/SBDebugger.cpp
index 47931f1c16f9a3..6b72994fc96afb 100644
--- a/lldb/source/API/SBDebugger.cpp
+++ b/lldb/source/API/SBDebugger.cpp
@@ -1483,12 +1483,6 @@ bool SBDebugger::GetUseColor() const {
   return (m_opaque_sp ? m_opaque_sp->GetUseColor() : false);
 }
 
-bool SBDebugger::SetShowInlineDiagnostics(bool value) {
-  LLDB_INSTRUMENT_VA(this, value);
-
-  return (m_opaque_sp ? m_opaque_sp->SetShowInlineD

[Lldb-commits] [lldb] [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (PR #106442)

[Adrian Prantl via lldb-commits]

https://github.com/adrian-prantl updated 
https://github.com/llvm/llvm-project/pull/106442

>From ab88865f07bcb711ed911ca16e8310f2e13220f6 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 28 Aug 2024 10:04:33 -0700
Subject: [PATCH] [lldb] Store expression evaluator diagnostics in an
 llvm::Error (NFC)

This patch is a reworking of Pete Lawrence's (@PortalPete) proposal
for better expression evaluator error messages:
https://github.com/llvm/llvm-project/pull/80938

This patch is preparatory patch for improving the rendering of
expression evaluator diagnostics. Currently diagnostics are rendered
into a string and the command interpreter layer then textually parses
words like "error:" to (sometimes) color the output accordingly. In
order to enable user interfaces to do better with diagnostics, we need
to store them in a machine-readable fromat. This patch does this by
adding a new llvm::Error kind wrapping a DiagnosticDetail struct that
is used when the error type is eErrorTypeExpression. Multiple
diagnostics are modeled using llvm::ErrorList.

Right now the extra information is not used by the CommandInterpreter,
this will be added in a follow-up patch!
---
 .../lldb/Expression/DiagnosticManager.h   |  88 +++
 lldb/include/lldb/Utility/Status.h|  28 ++---
 lldb/source/Breakpoint/BreakpointLocation.cpp |  11 +-
 lldb/source/Expression/DiagnosticManager.cpp  | 103 +++---
 lldb/source/Expression/ExpressionParser.cpp   |   5 +-
 lldb/source/Expression/UserExpression.cpp |  49 +
 lldb/source/Expression/UtilityFunction.cpp|  18 +--
 .../ExpressionParser/Clang/ClangDiagnostic.h  |   5 +-
 .../Clang/ClangExpressionParser.cpp   |  69 
 .../Clang/ClangUserExpression.h   |   2 +
 .../Plugins/Platform/POSIX/PlatformPOSIX.cpp  |  12 +-
 .../Platform/Windows/PlatformWindows.cpp  |  12 +-
 lldb/source/Target/Target.cpp |   3 +-
 lldb/source/Utility/Status.cpp|  64 ---
 .../TestModulesCompileError.py|   2 +-
 .../Expression/DiagnosticManagerTest.cpp  |  22 +++-
 16 files changed, 318 insertions(+), 175 deletions(-)

diff --git a/lldb/include/lldb/Expression/DiagnosticManager.h 
b/lldb/include/lldb/Expression/DiagnosticManager.h
index d49b7c99b114fb..62c6bcefe54110 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -12,6 +12,9 @@
 #include "lldb/lldb-defines.h"
 #include "lldb/lldb-types.h"
 
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/Status.h"
+
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 
@@ -20,6 +23,53 @@
 
 namespace lldb_private {
 
+/// A compiler-independent representation of a Diagnostic. Expression
+/// evaluation failures often have more than one diagnostic that a UI
+/// layer might want to render differently, for example to colorize
+/// it.
+///
+/// Running example:
+///   (lldb) expr 1+foo
+///   error: :1:3: use of undeclared identifier 'foo'
+///   1+foo
+/// ^
+struct DiagnosticDetail {
+  struct SourceLocation {
+FileSpec file;
+unsigned line = 0;
+uint16_t column = 0;
+uint16_t length = 0;
+bool in_user_input = false;
+  };
+  /// Contains {{}, 1, 3, 3, true} in the example above.
+  std::optional source_location;
+  /// Contains eSeverityError in the example above.
+  lldb::Severity severity = lldb::eSeverityInfo;
+  /// Contains "use of undeclared identifier 'x'" in the example above.
+  std::string message;
+  /// Contains the fully rendered error message.
+  std::string rendered;
+};
+
+/// An llvm::Error used to communicate diagnostics in Status. Multiple
+/// diagnostics may be chained in an llvm::ErrorList.
+class ExpressionError
+: public llvm::ErrorInfo {
+  std::string m_message;
+  std::vector m_details;
+
+public:
+  static char ID;
+  using llvm::ErrorInfo::ErrorInfo;
+  ExpressionError(lldb::ExpressionResults result, std::string msg,
+  std::vector details = {});
+  std::string message() const override;
+  llvm::ArrayRef GetDetails() const { return m_details; }
+  std::error_code convertToErrorCode() const override;
+  void log(llvm::raw_ostream &OS) const override;
+  std::unique_ptr Clone() const override;
+};
+
 enum DiagnosticOrigin {
   eDiagnosticOriginUnknown = 0,
   eDiagnosticOriginLLDB,
@@ -49,37 +99,28 @@ class Diagnostic {
 }
   }
 
-  Diagnostic(llvm::StringRef message, lldb::Severity severity,
- DiagnosticOrigin origin, uint32_t compiler_id)
-  : m_message(message), m_severity(severity), m_origin(origin),
-m_compiler_id(compiler_id) {}
-
-  Diagnostic(const Diagnostic &rhs)
-  : m_message(rhs.m_message), m_severity(rhs.m_severity),
-m_origin(rhs.m_origin), m_compiler_id(rhs.m_compiler_id) {}
+  Diagnostic(DiagnosticOrigin origin, uint32_t compiler_id,
+ DiagnosticDetail detail)
+  : m_origin(origin), m_compiler_id

[Lldb-commits] [lldb] 84fdfb9 - [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (#106442)

[via lldb-commits]

Author: Adrian Prantl
Date: 2024-09-27T16:09:52-07:00
New Revision: 84fdfb9ca63ee4304b486d7e85545ee4e1a46f5d

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

LOG: [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) 
(#106442)

…NFC]

This patch is the first patch in a series reworking of Pete Lawrence's
(@PortalPete) amazing proposal for better expression evaluator error
messages (https://github.com/llvm/llvm-project/pull/80938)

This patch is preparatory patch for improving the rendering of
expression evaluator diagnostics. Currently diagnostics are rendered
into a string and the command interpreter layer then textually parses
words like "error:" to (sometimes) color the output accordingly. In
order to enable user interfaces to do better with diagnostics, we need
to store them in a machine-readable fromat. This patch does this by
adding a new llvm::Error kind wrapping a DiagnosticDetail struct that
is used when the error type is eErrorTypeExpression. Multiple
diagnostics are modeled using llvm::ErrorList.

Right now the extra information is not used by the CommandInterpreter,
this will be added in a follow-up patch!

Added: 


Modified: 
lldb/include/lldb/Expression/DiagnosticManager.h
lldb/include/lldb/Utility/Status.h
lldb/source/Breakpoint/BreakpointLocation.cpp
lldb/source/Expression/DiagnosticManager.cpp
lldb/source/Expression/ExpressionParser.cpp
lldb/source/Expression/UserExpression.cpp
lldb/source/Expression/UtilityFunction.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
lldb/source/Plugins/Platform/Windows/PlatformWindows.cpp
lldb/source/Target/Target.cpp
lldb/source/Utility/Status.cpp
lldb/test/API/lang/objc/modules-compile-error/TestModulesCompileError.py
lldb/unittests/Expression/DiagnosticManagerTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Expression/DiagnosticManager.h 
b/lldb/include/lldb/Expression/DiagnosticManager.h
index d49b7c99b114fb..62c6bcefe54110 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -12,6 +12,9 @@
 #include "lldb/lldb-defines.h"
 #include "lldb/lldb-types.h"
 
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/Status.h"
+
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 
@@ -20,6 +23,53 @@
 
 namespace lldb_private {
 
+/// A compiler-independent representation of a Diagnostic. Expression
+/// evaluation failures often have more than one diagnostic that a UI
+/// layer might want to render 
diff erently, for example to colorize
+/// it.
+///
+/// Running example:
+///   (lldb) expr 1+foo
+///   error: :1:3: use of undeclared identifier 'foo'
+///   1+foo
+/// ^
+struct DiagnosticDetail {
+  struct SourceLocation {
+FileSpec file;
+unsigned line = 0;
+uint16_t column = 0;
+uint16_t length = 0;
+bool in_user_input = false;
+  };
+  /// Contains {{}, 1, 3, 3, true} in the example above.
+  std::optional source_location;
+  /// Contains eSeverityError in the example above.
+  lldb::Severity severity = lldb::eSeverityInfo;
+  /// Contains "use of undeclared identifier 'x'" in the example above.
+  std::string message;
+  /// Contains the fully rendered error message.
+  std::string rendered;
+};
+
+/// An llvm::Error used to communicate diagnostics in Status. Multiple
+/// diagnostics may be chained in an llvm::ErrorList.
+class ExpressionError
+: public llvm::ErrorInfo {
+  std::string m_message;
+  std::vector m_details;
+
+public:
+  static char ID;
+  using llvm::ErrorInfo::ErrorInfo;
+  ExpressionError(lldb::ExpressionResults result, std::string msg,
+  std::vector details = {});
+  std::string message() const override;
+  llvm::ArrayRef GetDetails() const { return m_details; }
+  std::error_code convertToErrorCode() const override;
+  void log(llvm::raw_ostream &OS) const override;
+  std::unique_ptr Clone() const override;
+};
+
 enum DiagnosticOrigin {
   eDiagnosticOriginUnknown = 0,
   eDiagnosticOriginLLDB,
@@ -49,37 +99,28 @@ class Diagnostic {
 }
   }
 
-  Diagnostic(llvm::StringRef message, lldb::Severity severity,
- DiagnosticOrigin origin, uint32_t compiler_id)
-  : m_message(message), m_severity(severity), m_origin(origin),
-m_compiler_id(compiler_id) {}
-
-  Diagnostic(const Diagnostic &rhs)
-  : m_message(rhs.m_message), m_severity(rhs.m_severity),
-m_origin(rhs.m_origin), m_compiler_id(rhs.m_compiler_id) {}
+  Diagnostic(DiagnosticOrigin origin, uint32_t compi

[Lldb-commits] [lldb] [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (PR #106442)

[Adrian Prantl via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

[LLVM Continuous Integration via lldb-commits]

llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder `lldb-x86_64-debian` 
running on `lldb-x86_64-debian` while building `lldb` at step 6 "test".

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


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

```
Step 6 (test) failure: build (failure)
...
17.416 [12/28/221] Linking CXX executable 
tools/lldb/unittests/ObjectFile/ELF/ObjectFileELFTests
17.456 [12/27/222] Building CXX object 
tools/lldb/unittests/Expression/CMakeFiles/ExpressionTests.dir/DWARFExpressionTest.cpp.o
17.461 [11/27/223] Building CXX object 
tools/lldb/unittests/SymbolFile/NativePDB/CMakeFiles/SymbolFileNativePDBTests.dir/UdtRecordCompleterTests.cpp.o
17.502 [10/27/224] Building CXX object 
tools/lldb/unittests/Process/gdb-remote/CMakeFiles/ProcessGdbRemoteTests.dir/GDBRemoteCommunicationClientTest.cpp.o
17.525 [9/27/225] Linking CXX executable 
tools/lldb/unittests/Language/CPlusPlus/LanguageCPlusPlusTests
17.533 [9/26/226] Linking CXX executable 
tools/lldb/unittests/Process/elf-core/ProcessElfCoreTests
17.550 [9/25/227] Building CXX object 
tools/lldb/unittests/Utility/CMakeFiles/UtilityTests.dir/ScalarTest.cpp.o
17.566 [8/25/228] Building CXX object 
tools/lldb/unittests/Instruction/CMakeFiles/EmulatorTests.dir/RISCV/TestRISCVEmulator.cpp.o
17.666 [7/25/229] Linking CXX executable 
tools/lldb/unittests/Callback/LLDBCallbackTests
17.743 [7/24/230] Linking CXX executable 
tools/lldb/unittests/Interpreter/InterpreterTests
FAILED: tools/lldb/unittests/Interpreter/InterpreterTests 
: && /usr/bin/clang++ -fPIC -fno-semantic-interposition 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color 
-ffunction-sections -fdata-sections -Wno-deprecated-declarations 
-Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register 
-Wno-vla-extension -O3 -DNDEBUG -fuse-ld=gold-Wl,--gc-sections 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestCommandPaths.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestCommandObjectExpression.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestCompletion.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestOptionArgParser.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestOptions.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestOptionValue.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestOptionValueFileColonLine.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestRegexCommand.cpp.o
 -o tools/lldb/unittests/Interpreter/InterpreterTests  lib/libLLVMSupport.a  
lib/libllvm_gtest_main.a  lib/libllvm_gtest.a  lib/liblldbCore.a  
lib/liblldbHost.a  lib/liblldbTarget.a  lib/liblldbSymbol.a  
lib/liblldbUtility.a  lib/liblldbUtilityHelpers.a  lib/liblldbInterpreter.a  
lib/liblldbPluginPlatformMacOSX.a  lib/libLLVMTestingSupport.a  
lib/libLLVMObjectYAML.a  lib/liblldbPluginDynamicLoaderDarwinKernel.a  
lib/liblldbPluginObjectFileMachO.a  
lib/liblldbPluginObjectContainerMachOFileset.a  
lib/liblldbPluginPlatformPOSIX.a  lib/liblldbPluginPlatformGDB.a  
lib/liblldbPluginProcessGDBRemote.a  lib/liblldbCore.a  lib/liblldbTarget.a  
lib/liblldbSymbol.a  lib/liblldbInterpreter.a  lib/liblldbBreakpoint.a  
lib/liblldbDataFormatters.a  lib/liblldbExpression.a  
lib/liblldbPluginCPlusPlusLanguage.a  lib/liblldbPluginObjCLanguage.a  
lib/liblldbPluginProcessUtility.a  lib/liblldbCommands.a  
lib/liblldbPluginClangCommon.a  lib/liblldbPluginCPPRuntime.a  
lib/liblldbPluginTypeSystemClang.a  lib/liblldbPluginAppleObjCRuntime.a  
lib/liblldbPluginExpressionParserClang.a  lib/liblldbPluginSymbolFileDWARF.a  
lib/liblldbPluginSymbolFilePDB.a  lib/liblldbPluginObjCRuntime.a  
lib/liblldbPluginSymbolFileNativePDB.a  lib/liblldbPluginObjectFilePDB.a  
lib/liblldbCore.a  lib/liblldbTarget.a  lib/liblldbSymbol.a  
lib/liblldbInterpreter.a  lib/liblldbBreakpoint.a  lib/liblldbDataFormatters.a  
lib/liblldbExpression.a  lib/liblldbPluginCPlusPlusLanguage.a  
lib/liblldbPluginObjCLanguage.a  lib/liblldbPluginProcessUtility.a  
lib/liblldbCommands.a  lib/liblldbPluginClangCommon.a  
lib/liblldbPluginCPPRuntime.a  lib/liblldbPluginTypeSystemClang.a  
lib/liblldbPluginAppleObjCRuntime.a  lib/liblldbPluginExpressionParserClang.a  
lib/liblldbPluginSymbolFileDWARF.a  lib/liblldbPluginSymbolFilePDB.a  
lib/liblldbPluginObjCRuntime.a  lib/liblldbPluginSymbolFileNativePDB.a  
lib/liblldbPluginObjectFilePDB.a  lib/liblldbCore.a  lib/liblldbTa

[Lldb-commits] [lldb] d33fa70 - [lldb] Inline expression evaluator error visualization (#106470)

[Adrian Prantl via lldb-commits]

Author: Adrian Prantl
Date: 2024-09-27T18:09:52-07:00
New Revision: d33fa70dddcb29d5fd85188e119f034e585f

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

LOG: [lldb] Inline expression evaluator error visualization (#106470)

This patch is a reworking of Pete Lawrence's (@PortalPete) proposal
for better expression evaluator error messages:
https://github.com/llvm/llvm-project/pull/80938

Before:

```
$ lldb -o "expr a+b"
(lldb) expr a+b
error: :1:1: use of undeclared identifier 'a'
a+b
^
error: :1:3: use of undeclared identifier 'b'
a+b
  ^
```

After:

```
(lldb) expr a+b
^ ^
│ ╰─ error: use of undeclared identifier 'b'
╰─ error: use of undeclared identifier 'a'
```

This eliminates the confusing `:1:3` source
location and avoids echoing the expression to the console again, which
results in a cleaner presentation that makes it easier to grasp what's
going on. You can't see it here, bug the word "error" is now also in
color, if so desired.

Depends on https://github.com/llvm/llvm-project/pull/106442.

Added: 
lldb/source/Commands/DiagnosticRendering.h
lldb/unittests/Interpreter/TestCommandObjectExpression.cpp

Modified: 
lldb/include/lldb/API/SBDebugger.h
lldb/include/lldb/Core/Debugger.h
lldb/include/lldb/Expression/DiagnosticManager.h
lldb/include/lldb/Interpreter/CommandObject.h
lldb/source/API/SBDebugger.cpp
lldb/source/Commands/CommandObjectExpression.cpp
lldb/source/Core/CoreProperties.td
lldb/source/Core/Debugger.cpp
lldb/source/Expression/DiagnosticManager.cpp
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
lldb/source/Plugins/TraceExporter/ctf/CommandObjectThreadTraceExportCTF.h
lldb/test/API/commands/expression/diagnostics/TestExprDiagnostics.py

lldb/test/API/commands/expression/persistent_variables/TestPersistentVariables.py

lldb/test/API/commands/expression/static-initializers/TestStaticInitializers.py
lldb/test/API/lang/cpp/template-function/TestTemplateFunctions.py
lldb/test/API/lang/mixed/TestMixedLanguages.py
lldb/test/Shell/Expr/TestObjCIDCast.test
lldb/test/Shell/Expr/TestObjCInCXXContext.test
lldb/test/Shell/SymbolFile/NativePDB/incomplete-tag-type.cpp
lldb/tools/driver/Driver.cpp
lldb/unittests/Expression/DiagnosticManagerTest.cpp
lldb/unittests/Interpreter/CMakeLists.txt

Removed: 




diff  --git a/lldb/include/lldb/API/SBDebugger.h 
b/lldb/include/lldb/API/SBDebugger.h
index 84ea9c0f772e16..6afa1c932ab050 100644
--- a/lldb/include/lldb/API/SBDebugger.h
+++ b/lldb/include/lldb/API/SBDebugger.h
@@ -304,6 +304,8 @@ class LLDB_API SBDebugger {
 
   bool GetUseColor() const;
 
+  bool SetShowInlineDiagnostics(bool);
+
   bool SetUseSourceCache(bool use_source_cache);
 
   bool GetUseSourceCache() const;

diff  --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index a72c2596cc2c5e..1d5f2fcc20626c 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -364,6 +364,10 @@ class Debugger : public 
std::enable_shared_from_this,
 
   const std::string &GetInstanceName() { return m_instance_name; }
 
+  bool GetShowInlineDiagnostics() const;
+
+  bool SetShowInlineDiagnostics(bool);
+
   bool LoadPlugin(const FileSpec &spec, Status &error);
 
   void RunIOHandlers();

diff  --git a/lldb/include/lldb/Expression/DiagnosticManager.h 
b/lldb/include/lldb/Expression/DiagnosticManager.h
index 62c6bcefe54110..b9a6421577781e 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -39,6 +39,7 @@ struct DiagnosticDetail {
 unsigned line = 0;
 uint16_t column = 0;
 uint16_t length = 0;
+bool hidden = false;
 bool in_user_input = false;
   };
   /// Contains {{}, 1, 3, 3, true} in the example above.

diff  --git a/lldb/include/lldb/Interpreter/CommandObject.h 
b/lldb/include/lldb/Interpreter/CommandObject.h
index 20c4769af90338..c5167e5e0ecb6a 100644
--- a/lldb/include/lldb/Interpreter/CommandObject.h
+++ b/lldb/include/lldb/Interpreter/CommandObject.h
@@ -340,6 +340,13 @@ class CommandObject : public 
std::enable_shared_from_this {
   return false;
   }
 
+  /// Set the command input as it appeared in the terminal. This
+  /// is used to have errors refer directly to the original command.
+  void SetOriginalCommandString(std::string s) { m_original_command = s; }
+
+  /// \param offset_in_command is on what column \c args_string
+  /// appears, if applicable. This enables diagnostics that refer back
+  /// to the user input.
   virtual void Execute(const char *args_string,
CommandReturnObject &result) = 0;
 

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

[Adrian Prantl via lldb-commits]

@@ -1887,7 +1887,8 @@ bool CommandInterpreter::HandleCommand(const char 
*command_line,
CommandReturnObject &result,
bool force_repeat_command) {
   std::string command_string(command_line);
-  std::string original_command_string(command_line);
+  std::string original_command_string(command_string);
+  std::string real_original_command_string(command_string);

adrian-prantl wrote:

This is just me being funny. I thought that if there is a std::string 
implementation that does CoW, then this would be more efficient, since the 
string data could be shared.

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

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

[Adrian Prantl via lldb-commits]

https://github.com/adrian-prantl updated 
https://github.com/llvm/llvm-project/pull/106470

>From a2728d10df151c2fd552c988827d27155b9e7055 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 28 Aug 2024 10:04:33 -0700
Subject: [PATCH 1/2] [lldb] Store expression evaluator diagnostics in an
 llvm::Error (NFC)

This patch is a reworking of Pete Lawrence's (@PortalPete) proposal
for better expression evaluator error messages:
https://github.com/llvm/llvm-project/pull/80938

This patch is preparatory patch for improving the rendering of
expression evaluator diagnostics. Currently diagnostics are rendered
into a string and the command interpreter layer then textually parses
words like "error:" to (sometimes) color the output accordingly. In
order to enable user interfaces to do better with diagnostics, we need
to store them in a machine-readable fromat. This patch does this by
adding a new llvm::Error kind wrapping a DiagnosticDetail struct that
is used when the error type is eErrorTypeExpression. Multiple
diagnostics are modeled using llvm::ErrorList.

Right now the extra information is not used by the CommandInterpreter,
this will be added in a follow-up patch!
---
 .../lldb/Expression/DiagnosticManager.h   |  88 +++
 lldb/include/lldb/Utility/Status.h|  28 ++---
 lldb/source/Breakpoint/BreakpointLocation.cpp |  11 +-
 lldb/source/Expression/DiagnosticManager.cpp  | 103 +++---
 lldb/source/Expression/ExpressionParser.cpp   |   5 +-
 lldb/source/Expression/UserExpression.cpp |  49 +
 lldb/source/Expression/UtilityFunction.cpp|  18 +--
 .../ExpressionParser/Clang/ClangDiagnostic.h  |   5 +-
 .../Clang/ClangExpressionParser.cpp   |  69 
 .../Clang/ClangUserExpression.h   |   2 +
 .../Plugins/Platform/POSIX/PlatformPOSIX.cpp  |  12 +-
 .../Platform/Windows/PlatformWindows.cpp  |  12 +-
 lldb/source/Target/Target.cpp |   3 +-
 lldb/source/Utility/Status.cpp|  67 +---
 .../TestModulesCompileError.py|   2 +-
 .../Expression/DiagnosticManagerTest.cpp  |  22 +++-
 16 files changed, 321 insertions(+), 175 deletions(-)

diff --git a/lldb/include/lldb/Expression/DiagnosticManager.h 
b/lldb/include/lldb/Expression/DiagnosticManager.h
index d49b7c99b114fb..62c6bcefe54110 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -12,6 +12,9 @@
 #include "lldb/lldb-defines.h"
 #include "lldb/lldb-types.h"
 
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/Status.h"
+
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 
@@ -20,6 +23,53 @@
 
 namespace lldb_private {
 
+/// A compiler-independent representation of a Diagnostic. Expression
+/// evaluation failures often have more than one diagnostic that a UI
+/// layer might want to render differently, for example to colorize
+/// it.
+///
+/// Running example:
+///   (lldb) expr 1+foo
+///   error: :1:3: use of undeclared identifier 'foo'
+///   1+foo
+/// ^
+struct DiagnosticDetail {
+  struct SourceLocation {
+FileSpec file;
+unsigned line = 0;
+uint16_t column = 0;
+uint16_t length = 0;
+bool in_user_input = false;
+  };
+  /// Contains {{}, 1, 3, 3, true} in the example above.
+  std::optional source_location;
+  /// Contains eSeverityError in the example above.
+  lldb::Severity severity = lldb::eSeverityInfo;
+  /// Contains "use of undeclared identifier 'x'" in the example above.
+  std::string message;
+  /// Contains the fully rendered error message.
+  std::string rendered;
+};
+
+/// An llvm::Error used to communicate diagnostics in Status. Multiple
+/// diagnostics may be chained in an llvm::ErrorList.
+class ExpressionError
+: public llvm::ErrorInfo {
+  std::string m_message;
+  std::vector m_details;
+
+public:
+  static char ID;
+  using llvm::ErrorInfo::ErrorInfo;
+  ExpressionError(lldb::ExpressionResults result, std::string msg,
+  std::vector details = {});
+  std::string message() const override;
+  llvm::ArrayRef GetDetails() const { return m_details; }
+  std::error_code convertToErrorCode() const override;
+  void log(llvm::raw_ostream &OS) const override;
+  std::unique_ptr Clone() const override;
+};
+
 enum DiagnosticOrigin {
   eDiagnosticOriginUnknown = 0,
   eDiagnosticOriginLLDB,
@@ -49,37 +99,28 @@ class Diagnostic {
 }
   }
 
-  Diagnostic(llvm::StringRef message, lldb::Severity severity,
- DiagnosticOrigin origin, uint32_t compiler_id)
-  : m_message(message), m_severity(severity), m_origin(origin),
-m_compiler_id(compiler_id) {}
-
-  Diagnostic(const Diagnostic &rhs)
-  : m_message(rhs.m_message), m_severity(rhs.m_severity),
-m_origin(rhs.m_origin), m_compiler_id(rhs.m_compiler_id) {}
+  Diagnostic(DiagnosticOrigin origin, uint32_t compiler_id,
+ DiagnosticDetail detail)
+  : m_origin(origin), m_compil

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

[LLVM Continuous Integration via lldb-commits]

llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder `lldb-arm-ubuntu` running 
on `linaro-lldb-arm-ubuntu` while building `lldb` at step 6 "test".

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


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

```
Step 6 (test) failure: build (failure)

```



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

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

[LLVM Continuous Integration via lldb-commits]

llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder `lldb-aarch64-ubuntu` 
running on `linaro-lldb-aarch64-ubuntu` while building `lldb` at step 6 "test".

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


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

```
Step 6 (test) failure: build (failure)
...
19.523 [149/7/105] Linking CXX executable 
tools/lldb/unittests/Language/ObjC/LanguageObjCTests
19.722 [149/6/106] Linking CXX executable 
tools/lldb/unittests/ObjectFile/PECOFF/ObjectFilePECOFFTests
19.810 [149/5/107] Linking CXX executable 
tools/lldb/unittests/Language/CLanguages/LanguageCLanguagesTests
19.836 [149/4/108] Linking CXX executable 
tools/lldb/unittests/ObjectFile/ELF/ObjectFileELFTests
19.862 [149/3/109] Linking CXX executable 
tools/lldb/unittests/Language/CPlusPlus/LanguageCPlusPlusTests
19.871 [149/2/110] Linking CXX executable 
tools/lldb/unittests/Language/Highlighting/HighlighterTests
20.227 [149/1/111] Building CXX object 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestCommandPaths.cpp.o
20.251 [147/2/112] Building CXX object 
tools/lldb/unittests/Platform/CMakeFiles/LLDBPlatformTests.dir/PlatformDarwinTest.cpp.o
20.277 [146/2/113] Building CXX object 
tools/lldb/unittests/Platform/CMakeFiles/LLDBPlatformTests.dir/PlatformMacOSXTest.cpp.o
20.818 [145/2/114] Linking CXX executable 
tools/lldb/unittests/Interpreter/InterpreterTests
FAILED: tools/lldb/unittests/Interpreter/InterpreterTests 
: && /usr/local/bin/c++ -fPIC -fno-semantic-interposition 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color 
-ffunction-sections -fdata-sections -Wno-deprecated-declarations 
-Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register 
-Wno-vla-extension -O3 -DNDEBUG -fuse-ld=lld -Wl,--color-diagnostics
-Wl,--gc-sections 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestCommandPaths.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestCommandObjectExpression.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestCompletion.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestOptionArgParser.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestOptions.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestOptionValue.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestOptionValueFileColonLine.cpp.o
 
tools/lldb/unittests/Interpreter/CMakeFiles/InterpreterTests.dir/TestRegexCommand.cpp.o
 -o tools/lldb/unittests/Interpreter/InterpreterTests  lib/libLLVMSupport.a  
lib/libllvm_gtest_main.a  lib/libllvm_gtest.a  lib/liblldbCore.a  
lib/liblldbHost.a  lib/liblldbTarget.a  lib/liblldbSymbol.a  
lib/liblldbUtility.a  lib/liblldbUtilityHelpers.a  lib/liblldbInterpreter.a  
lib/liblldbPluginPlatformMacOSX.a  lib/libLLVMTestingSupport.a  
lib/libLLVMObjectYAML.a  lib/liblldbPluginDynamicLoaderDarwinKernel.a  
lib/liblldbPluginObjectFileMachO.a  
lib/liblldbPluginObjectContainerMachOFileset.a  
lib/liblldbPluginPlatformPOSIX.a  lib/liblldbPluginPlatformGDB.a  
lib/liblldbPluginProcessGDBRemote.a  lib/liblldbCore.a  lib/liblldbTarget.a  
lib/liblldbSymbol.a  lib/liblldbInterpreter.a  lib/liblldbBreakpoint.a  
lib/liblldbDataFormatters.a  lib/liblldbExpression.a  
lib/liblldbPluginCPlusPlusLanguage.a  lib/liblldbPluginObjCLanguage.a  
lib/liblldbPluginProcessUtility.a  lib/liblldbCommands.a  
lib/liblldbPluginClangCommon.a  lib/liblldbPluginCPPRuntime.a  
lib/liblldbPluginTypeSystemClang.a  lib/liblldbPluginAppleObjCRuntime.a  
lib/liblldbPluginExpressionParserClang.a  lib/liblldbPluginSymbolFileDWARF.a  
lib/liblldbPluginSymbolFilePDB.a  lib/liblldbPluginObjCRuntime.a  
lib/liblldbPluginSymbolFileNativePDB.a  lib/liblldbPluginObjectFilePDB.a  
lib/liblldbCore.a  lib/liblldbTarget.a  lib/liblldbSymbol.a  
lib/liblldbInterpreter.a  lib/liblldbBreakpoint.a  lib/liblldbDataFormatters.a  
lib/liblldbExpression.a  lib/liblldbPluginCPlusPlusLanguage.a  
lib/liblldbPluginObjCLanguage.a  lib/liblldbPluginProcessUtility.a  
lib/liblldbCommands.a  lib/liblldbPluginClangCommon.a  
lib/liblldbPluginCPPRuntime.a  lib/liblldbPluginTypeSystemClang.a  
lib/liblldbPluginAppleObjCRuntime.a  lib/liblldbPluginExpressionParserClang.a  
lib/liblldbPluginSymbolFileDWARF.a  lib/liblldbPluginSymbolFilePDB.a  
lib/liblldbPluginObjCRuntime.a  lib/liblldbPluginSymbolFileNativePDB.a  
lib/liblldbPluginObjectFilePDB.a  lib/liblldbCore.a  lib/liblldbTarget.a  
lib/liblldbSymbol.a  lib/liblld