[Lldb-commits] [lldb] Remove redundant symbol lookups in IRExecutionUnit::FindInSymbols (PR #102835)

2024-08-26 Thread Michael Buch via lldb-commits

Michael137 wrote:

> I'm not sure I understand because this will break the logic that is currently 
> in place. Many nuances in post-processing wouldn't be possible to implement 
> with a simple short-circuit. If a symbol is found in the hinted module, it 
> might be internal. `IRExecutionUnit::FindInSymbols` processes the results by 
> preferring external symbols over internal ones. If I short-circuit the search 
> after the first match in the hinted module `IRExecutionUnit::FindInSymbols` 
> just wouldn't see potentially more preferable results. On the other hand 
> `SymbolContext::FindBestGlobalDataSymbol` prefers symbols of any type from 
> the hinted module over the other symbols. But it still prefers external 
> symbols over internal ones. So the priority order looks like this: `hint 
> external > hint internal > other external > other internal`. Moreover, 
> `SymbolContext::FindBestGlobalDataSymbol` verifies that there are no multiple 
> matches found, but it's tricky as well. It checks if there's a result in the 
> module - it does verification only matches from the module, otherwise it 
> verifies all the results. Perhaps I can't explain all the nuances quite 
> accurately, you should look at the post-processing code itself in these 
> functions. But the most important thing is that we don't have a full 
> understanding of when we can stop inside 
> FindFunction/FindSymbolsWithNameAndType.

 Sorry, just getting back to this. Got lost in my review queue.

Ok thanks for pointing this out. I didn't realize `Resolve` was tracking the 
internal load address and only succeeding when it found an external symbol. 
That's quite a subtle API. I would agree with Greg's expectation of how symbol 
resolution should work when evaluating expressions. Starting with the most 
local match, search outward until we find something appropriate to call.

What happens if we stop preferring the external symbols over internal ones in 
`IRExecutionUnit::FindInSymbols`? What tests break?

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


[Lldb-commits] [clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)

2024-08-26 Thread Tobias Hieta via lldb-commits

tru wrote:

This was suggested in https://github.com/llvm/llvm-project/pull/91856 and the 
suggestion there was that we need to split it up per sub-project which is 
something @e-kwsm has been doing: 
https://github.com/llvm/llvm-project/pulls/e-kwsm so I don't think this one is 
needed.

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


[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread Santhosh Kumar Ellendula via lldb-commits


@@ -4082,6 +4084,260 @@ void request__testGetTargetBreakpoints(const 
llvm::json::Object &request) {
   g_dap.SendJSON(llvm::json::Value(std::move(response)));
 }
 
+// "SetInstructionBreakpointsRequest" : {
+//   "allOf" : [
+// {"$ref" : "#/definitions/Request"}, {
+//   "type" : "object",
+//   "description" :
+//   "Replaces all existing instruction breakpoints. Typically, "
+//   "instruction breakpoints would be set from a disassembly window. "
+//   "\nTo clear all instruction breakpoints, specify an empty "
+//   "array.\nWhen an instruction breakpoint is hit, a `stopped` event 
"
+//   "(with reason `instruction breakpoint`) is generated.\nClients "
+//   "should only call this request if the corresponding capability "
+//   "`supportsInstructionBreakpoints` is true.",
+//   "properties" : {
+// "command" : {"type" : "string", "enum" :
+// ["setInstructionBreakpoints"]}, "arguments" :
+// {"$ref" : "#/definitions/SetInstructionBreakpointsArguments"}
+//   },
+//   "required" : [ "command", "arguments" ]
+// }
+//   ]
+// },
+//  "SetInstructionBreakpointsArguments"
+// : {
+//   "type" : "object",
+//   "description" : "Arguments for `setInstructionBreakpoints` request",
+//   "properties" : {
+// "breakpoints" : {
+//   "type" : "array",
+//   "items" : {"$ref" : "#/definitions/InstructionBreakpoint"},
+//   "description" : "The instruction references of the breakpoints"
+// }
+//   },
+//   "required" : ["breakpoints"]
+// },
+//   "SetInstructionBreakpointsResponse"
+// : {
+//   "allOf" : [
+// {"$ref" : "#/definitions/Response"}, {
+//   "type" : "object",
+//   "description" : "Response to `setInstructionBreakpoints` request",
+//   "properties" : {
+// "body" : {
+//   "type" : "object",
+//   "properties" : {
+// "breakpoints" : {
+//   "type" : "array",
+//   "items" : {"$ref" : "#/definitions/Breakpoint"},
+//   "description" :
+//   "Information about the breakpoints. The array elements
+//   " "correspond to the elements of the `breakpoints`
+//   array."
+// }
+//   },
+//   "required" : ["breakpoints"]
+// }
+//   },
+//   "required" : ["body"]
+// }
+//   ]
+// },
+// "InstructionBreakpoint" : {
+//   "type" : "object",
+//   "description" : "Properties of a breakpoint passed to the "
+//   "`setInstructionBreakpoints` request",
+//   "properties" : {
+// "instructionReference" : {
+//   "type" : "string",
+//   "description" :
+//   "The instruction reference of the breakpoint.\nThis should be a "
+//   "memory or instruction pointer reference from an
+//   `EvaluateResponse`, "
+//   "`Variable`, `StackFrame`, `GotoTarget`, or `Breakpoint`."
+// },
+// "offset" : {
+//   "type" : "integer",
+//   "description" : "The offset from the instruction reference in "
+//   "bytes.\nThis can be negative."
+// },
+// "condition" : {
+//   "type" : "string",
+//   "description" : "An expression for conditional breakpoints.\nIt is 
only
+//   "
+//   "honored by a debug adapter if the corresponding "
+//   "capability `supportsConditionalBreakpoints` is true."
+// },
+// "hitCondition" : {
+//   "type" : "string",
+//   "description" : "An expression that controls how many hits of the "
+//   "breakpoint are ignored.\nThe debug adapter is 
expected
+//   " "to interpret the expression as needed.\nThe
+//   attribute " "is only honored by a debug adapter if the
+//   corresponding " "capability
+//   `supportsHitConditionalBreakpoints` is true."
+// },
+// "mode" : {
+//   "type" : "string",
+//   "description" : "The mode of this breakpoint. If defined, this must be
+//   "
+//   "one of the `breakpointModes` the debug adapter "
+//   "advertised in its `Capabilities`."
+// }
+//   },
+//   "required" : ["instructionReference"]
+// },
+// "Breakpoint"
+// : {
+//   "type" : "object",
+//   "description" :
+//   "Information about a breakpoint created in `setBreakpoints`, "
+//   "`setFunctionBreakpoints`, `setInstructionBreakpoints`, or "
+//   "`setDataBreakpoints` requests.",
+//   "properties" : {
+// "id" : {
+//   "type" : "integer",
+//   "description" :
+//   "The ident

[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread Santhosh Kumar Ellendula via lldb-commits


@@ -766,6 +766,102 @@ llvm::json::Value CreateStackFrame(lldb::SBFrame &frame) {
   return llvm::json::Value(std::move(object));
 }
 
+// Response to `setInstructionBreakpoints` request.
+// "Breakpoint": {
+//   "type": "object",
+//   "description": "Response to `setInstructionBreakpoints` request.",
+//   "properties": {
+// "id": {
+//   "type": "number",
+//   "description": "The identifier for the breakpoint. It is needed if
+//   breakpoint events are used to update or remove breakpoints."
+// },
+// "verified": {
+//   "type": "boolean",
+//   "description": "If true, the breakpoint could be set (but not
+//   necessarily at the desired location."
+// },
+// "message": {
+//   "type": "string",
+//   "description": "A message about the state of the breakpoint.
+//   This is shown to the user and can be used to explain why a breakpoint
+//   could not be verified."
+// },
+// "source": {
+//   "type": "Source",
+//   "description": "The source where the breakpoint is located."
+// },
+// "line": {
+//   "type": "number",
+//   "description": "The start line of the actual range covered by the
+//   breakpoint."
+// },
+// "column": {
+//   "type": "number",
+//   "description": "The start column of the actual range covered by the
+//   breakpoint."
+// },
+// "endLine": {
+//   "type": "number",
+//   "description": "The end line of the actual range covered by the
+//   breakpoint."
+// },
+// "endColumn": {
+//   "type": "number",
+//   "description": "The end column of the actual range covered by the
+//   breakpoint. If no end line is given, then the end column is assumed to
+//   be in the start line."
+// },
+// "instructionReference": {
+//   "type": "string",
+//   "description": "A memory reference to where the breakpoint is set."
+// },
+// "offset": {
+//   "type": "number",
+//   "description": "The offset from the instruction reference.
+//   This can be negative."
+// },
+//   },
+//   "required": [ "id", "verified", "line"]
+// }
+llvm::json::Value CreateInstructionBreakpoint(lldb::SBBreakpoint &bp) {

santhoshe447 wrote:

Thanks,
I have not removed "CreateInstructionBreakpoint" function due to readability 
purpose, but just called the "CreateJsonObject" function from 
"CreateInstructionBreakpoint".

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


[Lldb-commits] [lldb] [lldb] Add frame recognizers for libc++ `std::invoke` (PR #105695)

2024-08-26 Thread Adrian Vogelsgesang via lldb-commits


@@ -53,10 +54,32 @@ class LibCXXFrameRecognizer : public StackFrameRecognizer {
 
 public:
   LibCXXFrameRecognizer()
-  : m_hidden_function_regex(
-R"(^std::__1::(__function.*::operator\(\)|__invoke))"
-R"((\[.*\])?)"// ABI tag.
-R"(( const)?$)"), // const.
+  : m_hidden_regex{
+// internal implementation details of std::function
+//std::__1::__function::__alloc_func, void ()>::operator()[abi:ne20]
+//std::__1::__function::__func, void ()>::operator()
+//std::__1::__function::__value_func::operator()[abi:ne20]() const
+RegularExpression{""
+  R"(^std::__[0-9]*::)" // Namespace.
+  R"(__function::.*::operator\(\))"
+  R"((\[.*\])?)"// ABI tag.
+  R"(( const)?$)"}, // const.
+// internal implementation details of std::invoke
+//   std::__1::__invoke[abi:ne20]
+RegularExpression{
+  R"(^std::__[0-9]*::)" // Namespace.
+  R"(__invoke)"

vogelsgesang wrote:

right. I posted this comment before I saw your fix on `main`. By now, the 
commit contains `^std::__[^:]*::*

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


[Lldb-commits] [lldb] [lldb] Add frame recognizers for libc++ `std::invoke` (PR #105695)

2024-08-26 Thread Adrian Vogelsgesang via lldb-commits


@@ -196,8 +197,8 @@ 
AbortWithPayloadFrameRecognizer::RecognizeFrame(lldb::StackFrameSP frame_sp) {
   abort_dict_sp->AddStringItem(reason_key, reason_string);
   abort_dict_sp->AddIntegerItem(flags_key, flags_val);
 
-  // This will overwrite the abort_with_payload information in the dictionary  
-  // already.  But we can only crash on abort_with_payload once, so that 
+  // This will overwrite the abort_with_payload information in the dictionary
+  // already.  But we can only crash on abort_with_payload once, so that

vogelsgesang wrote:

My editor auto-formats the whole file on save. This tends to be rather useful 
in other projects, but apparently not in LLVM

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


[Lldb-commits] [lldb] [lldb] Add frame recognizers for libc++ `std::invoke` (PR #105695)

2024-08-26 Thread Adrian Vogelsgesang via lldb-commits

https://github.com/vogelsgesang updated 
https://github.com/llvm/llvm-project/pull/105695

>From e90463e8967c2019e220b063ed4ce73cd0172bf3 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Thu, 22 Aug 2024 10:50:13 +
Subject: [PATCH 1/5] [lldb-dap] Add frame recognizers for libc++ `std::invoke`

With this commit, we also hide the implementation details of
`std::invoke`. To do so, the `LibCXXFrameRecognizer` got a couple more
regular expressions.

The regular expression passed into the `AddRecognizer` became
problematic, as it was evaluated on the demangled name. Those names also
included result types for C++ symbols. For `std::__invoke` the return
type is a huge `decltype(...)`, making the regular expresison really
hard to write.

Instead, I added support for `AddRecognizer` to match on the demangled
names without result type and argument types.

By hiding the implementation details of `invoke`, also the back traces
for `std::function` become even nicer, because `std::function` is using
`__invoke` internally.
---
 .../lldb/Target/StackFrameRecognizer.h|  8 +++-
 lldb/source/Commands/Options.td   |  2 +-
 .../CPlusPlus/CPPLanguageRuntime.cpp  | 48 ++-
 lldb/source/Target/StackFrameRecognizer.cpp   | 41 ++--
 .../TestStdFunctionRecognizer.py  | 21 +++-
 .../lang/cpp/std-invoke-recognizer/Makefile   |  5 ++
 .../TestStdInvokeRecognizer.py| 31 
 .../lang/cpp/std-invoke-recognizer/main.cpp   | 40 
 8 files changed, 175 insertions(+), 21 deletions(-)
 create mode 100644 lldb/test/API/lang/cpp/std-invoke-recognizer/Makefile
 create mode 100644 
lldb/test/API/lang/cpp/std-invoke-recognizer/TestStdInvokeRecognizer.py
 create mode 100644 lldb/test/API/lang/cpp/std-invoke-recognizer/main.cpp

diff --git a/lldb/include/lldb/Target/StackFrameRecognizer.h 
b/lldb/include/lldb/Target/StackFrameRecognizer.h
index 2f5c5caa6a4561..fe25dbbde745d1 100644
--- a/lldb/include/lldb/Target/StackFrameRecognizer.h
+++ b/lldb/include/lldb/Target/StackFrameRecognizer.h
@@ -107,12 +107,14 @@ class StackFrameRecognizerManager {
 public:
   void AddRecognizer(lldb::StackFrameRecognizerSP recognizer,
  ConstString module, llvm::ArrayRef symbols,
- bool first_instruction_only = true);
+ bool first_instruction_only = true,
+ Mangled::NamePreference mangling_preference = 
Mangled::ePreferDemangled);
 
   void AddRecognizer(lldb::StackFrameRecognizerSP recognizer,
  lldb::RegularExpressionSP module,
  lldb::RegularExpressionSP symbol,
- bool first_instruction_only = true);
+ bool first_instruction_only = true,
+ Mangled::NamePreference mangling_preference = 
Mangled::ePreferDemangled);
 
   void ForEach(std::function<
void(uint32_t recognizer_id, std::string recognizer_name,
@@ -143,10 +145,12 @@ class StackFrameRecognizerManager {
 std::vector symbols;
 lldb::RegularExpressionSP symbol_regexp;
 bool first_instruction_only;
+Mangled::NamePreference mangling_preference;
   };
 
   std::deque m_recognizers;
   uint16_t m_generation = 0;
+  std::unordered_set m_used_manglings;
 };
 
 /// \class ValueObjectRecognizerSynthesizedValue
diff --git a/lldb/source/Commands/Options.td b/lldb/source/Commands/Options.td
index 9c4dbed6939ba9..df906e9d7c808f 100644
--- a/lldb/source/Commands/Options.td
+++ b/lldb/source/Commands/Options.td
@@ -1049,7 +1049,7 @@ let Command = "thread backtrace" in {
   def thread_backtrace_extended : Option<"extended", "e">, Group<1>,
   Arg<"Boolean">, Desc<"Show the extended backtrace, if available">;
   def thread_backtrace_unfiltered : Option<"unfiltered", "u">, Group<1>,
-  Desc<"Filter out frames according to installed frame recognizers">;
+  Desc<"Do not filter out frames according to installed frame recognizers">;
 }
 
 let Command = "thread step scope" in {
diff --git 
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp 
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
index 1e4a2cbb1133f7..6d446a099efc78 100644
--- a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
+++ b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include 
+#include 
 
 #include 
 
@@ -44,7 +45,7 @@ char CPPLanguageRuntime::ID = 0;
 /// A frame recognizer that is installed to hide libc++ implementation
 /// details from the backtrace.
 class LibCXXFrameRecognizer : public StackFrameRecognizer {
-  RegularExpression m_hidden_function_regex;
+  std::array m_hidden_regex;
   RecognizedStackFrameSP m_hidden_frame;
 
   struct LibCXXHiddenFrame : public RecognizedStackFrame {
@@ -53,10 +54,32 @@ class LibCXXFrameRecognizer : public Sta

[Lldb-commits] [clang] [lldb] Use CLANG_RESOURCE_DIR more consistently (PR #103388)

2024-08-26 Thread Tulio Magno Quites Machado Filho via lldb-commits

tuliom wrote:

> Is there an out-of-tree scenario where CLANG_RESOURCE_DIR needs to be 
> replaced with something else at runtime, i.e. a real use-case for the 
> optional CustomResourceDir optional argument I removed?

@kimgr I have also looked for this and I haven't found an use-case where this 
would be appropriate. In fact, I think it's wrong to not take 
`CLANG_RESOURCE_DIR` as part of the output from 
`driver::Driver::GetResourcesPath()` because that would generate wrong results 
for builds that do set `CLANG_RESOURCE_DIR`, e.g. Fedora's builds.

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


[Lldb-commits] [clang] [lldb] Use CLANG_RESOURCE_DIR more consistently (PR #103388)

2024-08-26 Thread Tulio Magno Quites Machado Filho via lldb-commits

tuliom wrote:

> Do we need anything more to make progress with this PR?

@kimgr Do you have committer permission? Would you like some help to get this 
merged?

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


[Lldb-commits] [lldb] [lldb][dotest] Add an arg to add DLL search paths. (PR #104514)

2024-08-26 Thread Pavel Labath via lldb-commits

labath wrote:

I think that having fewer knobs that one needs to remember to set to correct 
values is better. Sometimes that's unavoidable, but I wanted to make sure this 
is one of those cases. Embedding this information into the swig bindings sounds 
like a good idea.

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


[Lldb-commits] [lldb] [lldb][NFC] Moved the SharedSocket class to Socket.* (PR #104787)

2024-08-26 Thread Pavel Labath via lldb-commits

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


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


[Lldb-commits] [lldb] Add logs for SymbolFileDWARF::FindTypes (PR #106030)

2024-08-26 Thread Dmitrii Galimzianov via lldb-commits

https://github.com/DmT021 updated 
https://github.com/llvm/llvm-project/pull/106030

>From 9cc21bfd87a7836e9264ed6ef958ac5246c5ed53 Mon Sep 17 00:00:00 2001
From: Dmitrii Galimzianov 
Date: Mon, 26 Aug 2024 15:52:17 +0200
Subject: [PATCH] Add logs for SymbolFileDWARF::FindTypes

---
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  | 32 ---
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 7e0cf36d0de1b8..8684e9f3f7e375 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -2737,10 +2737,19 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
   if (results.AlreadySearched(this))
 return;
 
+  auto type_basename = query.GetTypeBasename();
+
+  Log *log = GetLog(DWARFLog::Lookups);
+  if (log) {
+GetObjectFile()->GetModule()->LogMessage(
+log, "SymbolFileDWARF::FindTypes(type_basename=\"{0}\")",
+type_basename);
+  }
+
   std::lock_guard guard(GetModuleMutex());
 
   bool have_index_match = false;
-  m_index->GetTypes(query.GetTypeBasename(), [&](DWARFDIE die) {
+  m_index->GetTypes(type_basename, [&](DWARFDIE die) {
 // Check the language, but only if we have a language filter.
 if (query.HasLanguage()) {
   if (!query.LanguageMatches(GetLanguageFamily(*die.GetCU(
@@ -2779,7 +2788,19 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
 return !results.Done(query); // Keep iterating if we aren't done.
   });
 
-  if (results.Done(query))
+  auto CheckIsDoneAndLog = [&results, &query, log, type_basename, this] {
+if (results.Done(query)) {
+  if (log) {
+GetObjectFile()->GetModule()->LogMessage(
+log, "SymbolFileDWARF::FindTypes(type_basename=\"{0}\") => {1}",
+type_basename, results.GetTypeMap().GetSize());
+  }
+  return true;
+}
+return false;
+  };
+
+  if (CheckIsDoneAndLog())
 return;
 
   // With -gsimple-template-names, a templated type's DW_AT_name will not
@@ -2834,7 +2855,7 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
 }
 return !results.Done(query); // Keep iterating if we aren't done.
   });
-  if (results.Done(query))
+  if (CheckIsDoneAndLog())
 return;
 }
   }
@@ -2847,8 +2868,11 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
   for (const auto &pair : m_external_type_modules) {
 if (ModuleSP external_module_sp = pair.second) {
   external_module_sp->FindTypes(query, results);
-  if (results.Done(query))
+  if (results.Done(query)) {
+// don't use CheckIsDoneAndLog because the results are already logged
+// in the nested FindTypes call
 return;
+  }
 }
   }
 }

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


[Lldb-commits] [lldb] Add logs for SymbolFileDWARF::FindTypes (PR #106030)

2024-08-26 Thread Dmitrii Galimzianov via lldb-commits

DmT021 wrote:

@Michael137 Ok, added another message after the search 

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


[Lldb-commits] [lldb] 06ccd32 - [lldb][NFC] Moved the SharedSocket class to Socket.* (#104787)

2024-08-26 Thread via lldb-commits

Author: Dmitry Vasilyev
Date: 2024-08-26T18:26:46+04:00
New Revision: 06ccd32bb7b26b84448036c18e7191d9e56adc82

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

LOG: [lldb][NFC] Moved the SharedSocket class to Socket.* (#104787)

This is the prerequisite for #104238.

Added: 


Modified: 
lldb/include/lldb/Host/Socket.h
lldb/source/Host/common/Socket.cpp
lldb/tools/lldb-server/lldb-platform.cpp

Removed: 




diff  --git a/lldb/include/lldb/Host/Socket.h b/lldb/include/lldb/Host/Socket.h
index 573c881f727d8f..304a91bdf6741b 100644
--- a/lldb/include/lldb/Host/Socket.h
+++ b/lldb/include/lldb/Host/Socket.h
@@ -19,6 +19,7 @@
 #include "lldb/Utility/Status.h"
 
 #ifdef _WIN32
+#include "lldb/Host/Pipe.h"
 #include "lldb/Host/windows/windows.h"
 #include 
 #include 
@@ -32,12 +33,35 @@ namespace lldb_private {
 
 #if defined(_WIN32)
 typedef SOCKET NativeSocket;
+typedef lldb::pipe_t shared_fd_t;
 #else
 typedef int NativeSocket;
+typedef NativeSocket shared_fd_t;
 #endif
+class Socket;
 class TCPSocket;
 class UDPSocket;
 
+class SharedSocket {
+public:
+  static const shared_fd_t kInvalidFD;
+
+  SharedSocket(const Socket *socket, Status &error);
+
+  shared_fd_t GetSendableFD() { return m_fd; }
+
+  Status CompleteSending(lldb::pid_t child_pid);
+
+  static Status GetNativeSocket(shared_fd_t fd, NativeSocket &socket);
+
+private:
+#ifdef _WIN32
+  Pipe m_socket_pipe;
+  NativeSocket m_socket;
+#endif
+  shared_fd_t m_fd;
+};
+
 class Socket : public IOObject {
 public:
   enum SocketProtocol {

diff  --git a/lldb/source/Host/common/Socket.cpp 
b/lldb/source/Host/common/Socket.cpp
index 7364a12280cfdd..aabd562b0557c6 100644
--- a/lldb/source/Host/common/Socket.cpp
+++ b/lldb/source/Host/common/Socket.cpp
@@ -56,10 +56,12 @@ using namespace lldb_private;
 typedef const char *set_socket_option_arg_type;
 typedef char *get_socket_option_arg_type;
 const NativeSocket Socket::kInvalidSocketValue = INVALID_SOCKET;
+const shared_fd_t SharedSocket::kInvalidFD = LLDB_INVALID_PIPE;
 #else  // #if defined(_WIN32)
 typedef const void *set_socket_option_arg_type;
 typedef void *get_socket_option_arg_type;
 const NativeSocket Socket::kInvalidSocketValue = -1;
+const shared_fd_t SharedSocket::kInvalidFD = Socket::kInvalidSocketValue;
 #endif // #if defined(_WIN32)
 
 static bool IsInterrupted() {
@@ -70,6 +72,80 @@ static bool IsInterrupted() {
 #endif
 }
 
+SharedSocket::SharedSocket(const Socket *socket, Status &error) {
+#ifdef _WIN32
+  m_socket = socket->GetNativeSocket();
+  m_fd = kInvalidFD;
+
+  // Create a pipe to transfer WSAPROTOCOL_INFO to the child process.
+  error = m_socket_pipe.CreateNew(true);
+  if (error.Fail())
+return;
+
+  m_fd = m_socket_pipe.GetReadPipe();
+#else
+  m_fd = socket->GetNativeSocket();
+  error = Status();
+#endif
+}
+
+Status SharedSocket::CompleteSending(lldb::pid_t child_pid) {
+#ifdef _WIN32
+  // Transfer WSAPROTOCOL_INFO to the child process.
+  m_socket_pipe.CloseReadFileDescriptor();
+
+  WSAPROTOCOL_INFO protocol_info;
+  if (::WSADuplicateSocket(m_socket, child_pid, &protocol_info) ==
+  SOCKET_ERROR) {
+int last_error = ::WSAGetLastError();
+return Status("WSADuplicateSocket() failed, error: %d", last_error);
+  }
+
+  size_t num_bytes;
+  Status error =
+  m_socket_pipe.WriteWithTimeout(&protocol_info, sizeof(protocol_info),
+ std::chrono::seconds(10), num_bytes);
+  if (error.Fail())
+return error;
+  if (num_bytes != sizeof(protocol_info))
+return Status("WriteWithTimeout(WSAPROTOCOL_INFO) failed: %d bytes",
+  num_bytes);
+#endif
+  return Status();
+}
+
+Status SharedSocket::GetNativeSocket(shared_fd_t fd, NativeSocket &socket) {
+#ifdef _WIN32
+  socket = Socket::kInvalidSocketValue;
+  // Read WSAPROTOCOL_INFO from the parent process and create NativeSocket.
+  WSAPROTOCOL_INFO protocol_info;
+  {
+Pipe socket_pipe(fd, LLDB_INVALID_PIPE);
+size_t num_bytes;
+Status error =
+socket_pipe.ReadWithTimeout(&protocol_info, sizeof(protocol_info),
+std::chrono::seconds(10), num_bytes);
+if (error.Fail())
+  return error;
+if (num_bytes != sizeof(protocol_info)) {
+  return Status(
+  "socket_pipe.ReadWithTimeout(WSAPROTOCOL_INFO) failed: % d bytes",
+  num_bytes);
+}
+  }
+  socket = ::WSASocket(FROM_PROTOCOL_INFO, FROM_PROTOCOL_INFO,
+   FROM_PROTOCOL_INFO, &protocol_info, 0, 0);
+  if (socket == INVALID_SOCKET) {
+return Status("WSASocket(FROM_PROTOCOL_INFO) failed: error %d",
+  ::WSAGetLastError());
+  }
+  return Status();
+#else
+  socket = fd;
+  return Status();
+#endif
+}
+
 struct SocketScheme {
   const char *m_scheme;

[Lldb-commits] [lldb] [lldb][NFC] Moved the SharedSocket class to Socket.* (PR #104787)

2024-08-26 Thread Dmitry Vasilyev via lldb-commits

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


[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread Santhosh Kumar Ellendula via lldb-commits

santhoshe447 wrote:

Hi Everyone,
Thanks for everyone's valuable feedback. Pls let me know if all are ok with the 
changes.

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


[Lldb-commits] [lldb] [lldb] Fix windows debug build after 9d07f43 (PR #104896)

2024-08-26 Thread Pavel Labath via lldb-commits

labath wrote:

Thanks.

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


[Lldb-commits] [lldb] [lldb] IRMemoryMap zero address mapping fix (PR #99045)

2024-08-26 Thread via lldb-commits

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


[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

2024-08-26 Thread Pavel Labath via lldb-commits


@@ -96,16 +98,120 @@ def getArchSpec(self, architecture):
 """
 return ["ARCH=" + architecture] if architecture else []
 
-def getCCSpec(self, compiler):
+def getToolchainSpec(self, compiler):
 """
-Helper function to return the key-value string to specify the compiler
+Helper function to return the key-value strings to specify the 
toolchain
 used for the make system.
 """
 cc = compiler if compiler else None
 if not cc and configuration.compiler:
 cc = configuration.compiler
+
 if cc:
-return ['CC="%s"' % cc]
+exe_ext = ""
+if lldbplatformutil.getHostPlatform() == "windows":
+exe_ext = ".exe"
+
+cc = cc.strip()
+cc_path = pathlib.Path(cc)
+cc = cc_path.as_posix()

labath wrote:

What's up with the posix thing? Could we stick to native paths?

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


[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

2024-08-26 Thread Pavel Labath via lldb-commits


@@ -96,16 +98,107 @@ def getArchSpec(self, architecture):
 """
 return ["ARCH=" + architecture] if architecture else []
 
-def getCCSpec(self, compiler):
+def getToolchainSpec(self, compiler):
 """
-Helper function to return the key-value string to specify the compiler
+Helper function to return the key-value strings to specify the 
toolchain
 used for the make system.
 """
 cc = compiler if compiler else None
 if not cc and configuration.compiler:
 cc = configuration.compiler
+
 if cc:
-return ['CC="%s"' % cc]
+exe_ext = ""
+if lldbplatformutil.getHostPlatform() == "windows":
+exe_ext = ".exe"
+
+cc = cc.strip()
+cc_path = pathlib.Path(cc)
+cc = cc_path.as_posix()
+
+# We can get CC compiler string in the following formats:
+#  [] - such as 'xrun clang', 'xrun 
/usr/bin/clang' & etc
+#
+# Where  could contain the following parts:
+#   [.]   - sucn as 
'clang', 'clang.exe' ('clamg-cl.exe'?)

labath wrote:

```suggestion
#   [.]   - sucn as 
'clang', 'clang.exe' ('clang-cl.exe'?)
```

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


[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

2024-08-26 Thread Pavel Labath via lldb-commits


@@ -213,7 +229,7 @@ endif
 LIMIT_DEBUG_INFO_FLAGS =
 NO_LIMIT_DEBUG_INFO_FLAGS =
 MODULE_DEBUG_INFO_FLAGS =
-ifneq (,$(findstring clang,$(CC)))
+ifeq ($(CCC), clang)

labath wrote:

What does CCC stand for?

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


[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

2024-08-26 Thread Pavel Labath via lldb-commits


@@ -96,16 +98,120 @@ def getArchSpec(self, architecture):
 """
 return ["ARCH=" + architecture] if architecture else []
 
-def getCCSpec(self, compiler):
+def getToolchainSpec(self, compiler):
 """
-Helper function to return the key-value string to specify the compiler
+Helper function to return the key-value strings to specify the 
toolchain
 used for the make system.
 """
 cc = compiler if compiler else None
 if not cc and configuration.compiler:
 cc = configuration.compiler
+
 if cc:
-return ['CC="%s"' % cc]
+exe_ext = ""
+if lldbplatformutil.getHostPlatform() == "windows":
+exe_ext = ".exe"
+
+cc = cc.strip()
+cc_path = pathlib.Path(cc)
+cc = cc_path.as_posix()
+
+# We can get CC compiler string in the following formats:
+#  [] - such as 'xrun clang', 'xrun 
/usr/bin/clang' & etc
+#
+# Where  could contain the following parts:
+#   [.]   - sucn as 
'clang', 'clang.exe' ('clamg-cl.exe'?)
+#   -[.]   - such as 
'armv7-linux-gnueabi-gcc'
+#   /[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+#   /-[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+
+cc_ext = cc_path.suffix
+# Compiler name without extension
+cc_name = cc_path.stem.split(" ")[-1]
+
+# A kind of compiler (canonical name): clang, gcc, cc & etc.
+cc_type = cc_name
+# A triple prefix of compiler name: gcc
+cc_prefix = ""
+if not "clang-cl" in cc_name and not "llvm-gcc" in cc_name:
+cc_name_parts = cc_name.split("-")
+cc_type = cc_name_parts[-1]
+if len(cc_name_parts) > 1:
+cc_prefix = "-".join(cc_name_parts[:-1]) + "-"
+
+# A kind of C++ compiler.
+cxx_types = {
+"icc": "icpc",
+"llvm-gcc": "llvm-g++",
+"gcc": "g++",
+"cc": "c++",
+"clang": "clang++",
+}
+cxx_type = cxx_types.get(cc_type, cc_type)
+
+cc_dir = cc_path.parent
+
+def getLlvmUtil(util_name):
+llvm_tools_dir = os.getenv("LLVM_TOOLS_DIR", cc_dir.as_posix())
+return llvm_tools_dir + "/" + util_name + exe_ext
+
+def getToolchainUtil(util_name):
+return (cc_dir / (cc_prefix + util_name + cc_ext)).as_posix()
+
+cxx = getToolchainUtil(cxx_type)
+
+util_names = {
+"OBJCOPY": "objcopy",
+"STRIP": "objcopy",
+"ARCHIVER": "ar",
+"DWP": "dwp",
+}
+utils = []
+
+# Note: LLVM_AR is currently required by API TestBSDArchives.py 
tests.
+# Assembly a full path to llvm-ar for given LLVM_TOOLS_DIR;
+# otherwise assume we have llvm-ar at the same place where is CC 
specified.
+if not os.getenv("LLVM_AR"):
+llvm_ar = getLlvmUtil("llvm-ar")
+utils.extend(['LLVM_AR="%s"' % llvm_ar])
+
+if not lldbplatformutil.platformIsDarwin():
+if os.getenv("USE_LLVM_TOOLS"):

labath wrote:

I don't see any reference to this var in the llvm tree. Who sets this? (and why)

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


[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

2024-08-26 Thread Pavel Labath via lldb-commits


@@ -96,16 +98,120 @@ def getArchSpec(self, architecture):
 """
 return ["ARCH=" + architecture] if architecture else []
 
-def getCCSpec(self, compiler):
+def getToolchainSpec(self, compiler):
 """
-Helper function to return the key-value string to specify the compiler
+Helper function to return the key-value strings to specify the 
toolchain
 used for the make system.
 """
 cc = compiler if compiler else None
 if not cc and configuration.compiler:
 cc = configuration.compiler
+
 if cc:
-return ['CC="%s"' % cc]
+exe_ext = ""
+if lldbplatformutil.getHostPlatform() == "windows":
+exe_ext = ".exe"
+
+cc = cc.strip()
+cc_path = pathlib.Path(cc)
+cc = cc_path.as_posix()
+
+# We can get CC compiler string in the following formats:
+#  [] - such as 'xrun clang', 'xrun 
/usr/bin/clang' & etc
+#
+# Where  could contain the following parts:
+#   [.]   - sucn as 
'clang', 'clang.exe' ('clamg-cl.exe'?)
+#   -[.]   - such as 
'armv7-linux-gnueabi-gcc'
+#   /[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+#   /-[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+
+cc_ext = cc_path.suffix
+# Compiler name without extension
+cc_name = cc_path.stem.split(" ")[-1]
+
+# A kind of compiler (canonical name): clang, gcc, cc & etc.
+cc_type = cc_name
+# A triple prefix of compiler name: gcc
+cc_prefix = ""
+if not "clang-cl" in cc_name and not "llvm-gcc" in cc_name:
+cc_name_parts = cc_name.split("-")
+cc_type = cc_name_parts[-1]
+if len(cc_name_parts) > 1:
+cc_prefix = "-".join(cc_name_parts[:-1]) + "-"
+
+# A kind of C++ compiler.
+cxx_types = {
+"icc": "icpc",
+"llvm-gcc": "llvm-g++",
+"gcc": "g++",
+"cc": "c++",
+"clang": "clang++",
+}
+cxx_type = cxx_types.get(cc_type, cc_type)
+
+cc_dir = cc_path.parent
+
+def getLlvmUtil(util_name):
+llvm_tools_dir = os.getenv("LLVM_TOOLS_DIR", cc_dir.as_posix())
+return llvm_tools_dir + "/" + util_name + exe_ext
+
+def getToolchainUtil(util_name):
+return (cc_dir / (cc_prefix + util_name + cc_ext)).as_posix()
+
+cxx = getToolchainUtil(cxx_type)
+
+util_names = {
+"OBJCOPY": "objcopy",
+"STRIP": "objcopy",
+"ARCHIVER": "ar",
+"DWP": "dwp",
+}
+utils = []
+
+# Note: LLVM_AR is currently required by API TestBSDArchives.py 
tests.
+# Assembly a full path to llvm-ar for given LLVM_TOOLS_DIR;
+# otherwise assume we have llvm-ar at the same place where is CC 
specified.
+if not os.getenv("LLVM_AR"):
+llvm_ar = getLlvmUtil("llvm-ar")
+utils.extend(['LLVM_AR="%s"' % llvm_ar])
+
+if not lldbplatformutil.platformIsDarwin():
+if os.getenv("USE_LLVM_TOOLS"):
+# Use the llvm project tool instead of the system defaults.
+for var, name in util_names.items():
+utils.append('%s="%s"' % (var, getLlvmUtil("llvm-" + 
name)))
+utils.extend(['AR="%s"' % llvm_ar])
+elif cc_type in ["clang", "cc", "gcc"]:
+util_paths = {}
+# Assembly a toolchain side tool cmd based on passed CC.
+for var, name in util_names.items():
+# Do not override explicity specified tool from the 
cmd line.
+if not os.getenv(var):
+util_paths[var] = getToolchainUtil(name)
+else:
+util_paths[var] = os.getenv(var)
+utils.extend(['AR="%s"' % util_paths["ARCHIVER"]])
+
+# Look for llvm-dwp or gnu dwp
+if not lldbutil.which(util_paths["DWP"]):
+util_paths["DWP"] = getToolchainUtil("llvm-dwp")
+if not lldbutil.which(util_paths["DWP"]):
+util_paths["DWP"] = lldbutil.which("llvm-dwp")
+if not util_paths["DWP"]:
+util_paths["DWP"] = lldbutil.which("dwp")
+if not util_paths["DWP"]:
+del util_paths["DWP"]
+
+for var, path in util_paths.items():
+   

[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

2024-08-26 Thread Pavel Labath via lldb-commits


@@ -96,16 +98,120 @@ def getArchSpec(self, architecture):
 """
 return ["ARCH=" + architecture] if architecture else []
 
-def getCCSpec(self, compiler):
+def getToolchainSpec(self, compiler):
 """
-Helper function to return the key-value string to specify the compiler
+Helper function to return the key-value strings to specify the 
toolchain
 used for the make system.
 """
 cc = compiler if compiler else None
 if not cc and configuration.compiler:
 cc = configuration.compiler
+
 if cc:
-return ['CC="%s"' % cc]
+exe_ext = ""
+if lldbplatformutil.getHostPlatform() == "windows":
+exe_ext = ".exe"
+
+cc = cc.strip()
+cc_path = pathlib.Path(cc)
+cc = cc_path.as_posix()
+
+# We can get CC compiler string in the following formats:
+#  [] - such as 'xrun clang', 'xrun 
/usr/bin/clang' & etc
+#
+# Where  could contain the following parts:
+#   [.]   - sucn as 
'clang', 'clang.exe' ('clamg-cl.exe'?)
+#   -[.]   - such as 
'armv7-linux-gnueabi-gcc'
+#   /[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+#   /-[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+
+cc_ext = cc_path.suffix
+# Compiler name without extension
+cc_name = cc_path.stem.split(" ")[-1]
+
+# A kind of compiler (canonical name): clang, gcc, cc & etc.
+cc_type = cc_name
+# A triple prefix of compiler name: gcc
+cc_prefix = ""
+if not "clang-cl" in cc_name and not "llvm-gcc" in cc_name:
+cc_name_parts = cc_name.split("-")
+cc_type = cc_name_parts[-1]
+if len(cc_name_parts) > 1:
+cc_prefix = "-".join(cc_name_parts[:-1]) + "-"
+
+# A kind of C++ compiler.
+cxx_types = {
+"icc": "icpc",
+"llvm-gcc": "llvm-g++",
+"gcc": "g++",
+"cc": "c++",
+"clang": "clang++",
+}
+cxx_type = cxx_types.get(cc_type, cc_type)
+
+cc_dir = cc_path.parent
+
+def getLlvmUtil(util_name):
+llvm_tools_dir = os.getenv("LLVM_TOOLS_DIR", cc_dir.as_posix())
+return llvm_tools_dir + "/" + util_name + exe_ext

labath wrote:

```suggestion
return os.path.join(llvm_tools_dir, util_name + exe_ext)
```

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


[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

2024-08-26 Thread Pavel Labath via lldb-commits


@@ -102,15 +102,33 @@ endif
 # If you change the defaults of CC, be sure to also change it in the file
 # test/builders/builder_base.py, which provides a Python way to return the
 # value of the make variable CC -- getCompiler().
-#
-# See also these functions:
-#   o cxx_compiler
-#   o cxx_linker
 #--
 ifeq "$(CC)" ""
 $(error "C compiler is not specified. Please run tests through lldb-dotest or 
lit")
 endif
 
+# Remove all " and ' characters from the path. Also remove surrounding space 
chars.
+cstrip = $(strip $(subst ",,$(subst ',,$(1
+override CC := $(call cstrip,$(CC))
+override CCC := $(call cstrip,$(CCC))
+override CXX := $(call cstrip,$(CXX))
+# Always override the linker. Assign already normalized CC.
+override LD := $(call cstrip,$(CC))
+# A kind of linker. It always gets retrieved from CC.
+override LDC := $(call cstrip,$(CCC))
+override OBJCOPY := $(call cstrip,$(OBJCOPY))
+override STRIP := $(call cstrip,$(STRIP))
+override ARCHIVER := $(call cstrip,$(ARCHIVER))
+override AR := $(call cstrip,$(AR))
+override DWP := $(call cstrip,$(DWP))
+override LLVM_AR := $(call cstrip,$(LLVM_AR))

labath wrote:

Is this really necessary? Could we get rid of it by *not* passing the extra 
quotes in the python cmd?

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


[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

2024-08-26 Thread Dmitry Vasilyev via lldb-commits

https://github.com/slydiman updated 
https://github.com/llvm/llvm-project/pull/104238

>From 1d4949f447ab4e2855dd17bcfa250cb2749aab68 Mon Sep 17 00:00:00 2001
From: Dmitry Vassiliev 
Date: Mon, 26 Aug 2024 19:35:55 +0400
Subject: [PATCH] [lldb] Removed gdbserver ports map from lldb-server

Listen to gdbserver-port, accept the connection and run lldb-server gdbserver 
--fd on all platforms.
Refactored Acceptor to listen on 2 ports in the main thread.

Parameters --min-gdbserver-port and --max-gdbserver-port are deprecated now.

This is the part 2 of #101283.

Fixes #97537, fixes #101475.
---
 lldb/docs/man/lldb-server.rst |  11 +-
 lldb/docs/resources/qemu-testing.rst  |  19 +-
 lldb/include/lldb/Host/common/TCPSocket.h |   3 +
 lldb/source/Host/common/TCPSocket.cpp | 105 ---
 .../posix/ConnectionFileDescriptorPosix.cpp   |  22 +-
 .../gdb-remote/GDBRemoteCommunication.cpp |  43 +--
 .../gdb-remote/GDBRemoteCommunication.h   |   8 +-
 .../GDBRemoteCommunicationServerPlatform.cpp  | 287 ++
 .../GDBRemoteCommunicationServerPlatform.h|  82 +
 .../Process/gdb-remote/ProcessGDBRemote.cpp   |   2 +-
 .../TestPlatformLaunchGDBServer.py|  12 +-
 .../Shell/lldb-server/TestGdbserverPort.test  |   4 -
 lldb/tools/lldb-server/Acceptor.cpp   | 131 +---
 lldb/tools/lldb-server/Acceptor.h |  34 ++-
 lldb/tools/lldb-server/lldb-gdbserver.cpp |  23 +-
 lldb/tools/lldb-server/lldb-platform.cpp  | 203 +++--
 .../Process/gdb-remote/CMakeLists.txt |   1 -
 .../Process/gdb-remote/PortMapTest.cpp| 115 ---
 .../tools/lldb-server/tests/LLGSTest.cpp  |   4 -
 .../tools/lldb-server/tests/TestClient.cpp|   4 -
 .../tools/lldb-server/tests/TestClient.h  |   4 +
 21 files changed, 481 insertions(+), 636 deletions(-)
 delete mode 100644 lldb/test/Shell/lldb-server/TestGdbserverPort.test
 delete mode 100644 lldb/unittests/Process/gdb-remote/PortMapTest.cpp

diff --git a/lldb/docs/man/lldb-server.rst b/lldb/docs/man/lldb-server.rst
index a67c00b305f6d2..31f5360df5e23e 100644
--- a/lldb/docs/man/lldb-server.rst
+++ b/lldb/docs/man/lldb-server.rst
@@ -147,15 +147,8 @@ GDB-SERVER CONNECTIONS
 
 .. option:: --gdbserver-port 
 
- Define a port to be used for gdb-server connections. Can be specified multiple
- times to allow multiple ports. Has no effect if --min-gdbserver-port
- and --max-gdbserver-port are specified.
-
-.. option:: --min-gdbserver-port 
-.. option:: --max-gdbserver-port 
-
- Specify the range of ports that can be used for gdb-server connections. Both
- options need to be specified simultaneously. Overrides --gdbserver-port.
+ Define a port to be used for gdb-server connections. This port is used for
+ multiple connections.
 
 .. option:: --port-offset 
 
diff --git a/lldb/docs/resources/qemu-testing.rst 
b/lldb/docs/resources/qemu-testing.rst
index 51a30b11717a87..e102f84a1d31f4 100644
--- a/lldb/docs/resources/qemu-testing.rst
+++ b/lldb/docs/resources/qemu-testing.rst
@@ -149,7 +149,6 @@ to the host (refer to QEMU's manuals for the specific 
options).
 * At least one to connect to the intial ``lldb-server``.
 * One more if you want to use ``lldb-server`` in ``platform mode``, and have it
   start a ``gdbserver`` instance for you.
-* A bunch more if you want to run tests against the ``lldb-server`` platform.
 
 If you are doing either of the latter 2 you should also restrict what ports
 ``lldb-server tries`` to use, otherwise it will randomly pick one that is 
almost
@@ -157,22 +156,14 @@ certainly not forwarded. An example of this is shown 
below.
 
 ::
 
-  $ lldb-server plaform --server --listen 0.0.0.0:54321 \
---min-gdbserver-port 49140 --max-gdbserver-port 49150
+  $ lldb-server plaform --server --listen 0.0.0.0:54321 --gdbserver-port 49140
 
 The result of this is that:
 
 * ``lldb-server`` platform mode listens externally on port ``54321``.
 
-* When it is asked to start a new gdbserver mode instance, it will use a port
-  in the range ``49140`` to ``49150``.
+* When it is asked to start a new gdbserver mode instance, it will use the port
+  ``49140``.
 
-Your VM configuration should have ports ``54321``, and ``49140`` to ``49150``
-forwarded for this to work.
-
-.. note::
-  These options are used to create a "port map" within ``lldb-server``.
-  Unfortunately this map is not cleaned up on Windows on connection close,
-  and across a few uses you may run out of valid ports. To work around this,
-  restart the platform every so often, especially after running a set of tests.
-  This is tracked here: https://github.com/llvm/llvm-project/issues/90923
+Your VM configuration should have ports ``54321`` and ``49140`` forwarded for
+this to work.
diff --git a/lldb/include/lldb/Host/common/TCPSocket.h 
b/lldb/include/lldb/Host/common/TCPSocket.h
index b782c9e6096c44..b45fdae00c6b43 100644
--- a/lldb/include/lldb/Host/common/TCPSocket.h
+++ b/lldb/include/lldb/Host/co

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

2024-08-26 Thread Dmitry Vasilyev via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

2024-08-26 Thread Dmitry Vasilyev via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

2024-08-26 Thread Dmitry Vasilyev via lldb-commits

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


[Lldb-commits] [clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)

2024-08-26 Thread Louis Dionne via lldb-commits

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


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


[Lldb-commits] [clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)

2024-08-26 Thread Louis Dionne via lldb-commits


@@ -284,7 +284,7 @@ def sync_csv(rows: List[Tuple], from_github: 
List[PaperInfo]) -> List[Tuple]:
 results.append(gh.for_printing())
 continue
 elif paper.status != gh.status:
-print(f"We found a CSV row and a Github issue with different 
statuses:\nrow: {row}\Github issue: {gh}")
+print(rf"We found a CSV row and a Github issue with different 
statuses:\nrow: {row}\Github issue: {gh}")

ldionne wrote:

This is not a regex -- this change looks wrong.

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


[Lldb-commits] [clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)

2024-08-26 Thread via lldb-commits

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
darker --check --diff -r 
1193f7d6487d2d94009f8d8d27da3907136482b9...e9ffeeaf7a0bf70c58a04315e451ba4553765586
 .github/workflows/version-check.py clang/docs/tools/dump_ast_matchers.py 
clang/test/Analysis/check-analyzer-fixit.py 
compiler-rt/lib/asan/scripts/asan_symbolize.py 
cross-project-tests/debuginfo-tests/dexter/dex/command/ParseCommand.py 
cross-project-tests/lit.cfg.py libcxx/utils/synchronize_csv_status_files.py 
lld/test/MachO/tools/validate-unwind-info.py lld/utils/benchmark.py 
lldb/examples/python/crashlog.py lldb/examples/python/delta.py 
lldb/examples/python/gdbremote.py lldb/examples/python/jump.py 
lldb/examples/python/performance.py lldb/examples/python/symbolication.py 
lldb/packages/Python/lldbsuite/test/lldbpexpect.py 
lldb/packages/Python/lldbsuite/test/test_runner/process_control.py 
lldb/test/API/commands/command/backticks/TestBackticksInAlias.py 
lldb/test/API/commands/expression/memory-allocation/TestMemoryAllocSettings.py 
lldb/test/API/commands/expression/test/TestExprs.py 
lldb/test/API/commands/gui/expand-threads-tree/TestGuiExpandThreadsTree.py 
lldb/test/API/commands/help/TestHelp.py 
lldb/test/API/commands/process/launch-with-shellexpand/TestLaunchWithShellExpand.py
 lldb/test/API/commands/register/register/TestRegistersUnavailable.py 
lldb/test/API/commands/register/register/register_command/TestRegisters.py 
lldb/test/API/commands/settings/TestSettings.py 
lldb/test/API/commands/target/basic/TestTargetCommand.py 
lldb/test/API/commands/target/dump-separate-debug-info/dwo/TestDumpDwo.py 
lldb/test/API/commands/target/dump-separate-debug-info/oso/TestDumpOso.py 
lldb/test/API/commands/trace/TestTraceDumpInfo.py 
lldb/test/API/commands/trace/TestTraceTSC.py 
lldb/test/API/driver/quit_speed/TestQuitWithProcess.py 
lldb/test/API/functionalities/breakpoint/breakpoint_by_line_and_column/TestBreakpointByLineAndColumn.py
 
lldb/test/API/functionalities/breakpoint/breakpoint_locations/TestBreakpointLocations.py
 
lldb/test/API/functionalities/data-formatter/data-formatter-advanced/TestDataFormatterAdv.py
 
lldb/test/API/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
 
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py
 
lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py
 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unordered/TestDataFormatterGenericUnordered.py
 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py
 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
 
lldb/test/API/functionalities/data-formatter/type_summary_list_arg/TestTypeSummaryListArg.py
 lldb/test/API/functionalities/gdb_remote_client/TestXMLRegisterFlags.py 
lldb/test/API/functionalities/memory-region/TestMemoryRegion.py 
lldb/test/API/functionalities/target_var/TestTargetVar.py 
lldb/test/API/iohandler/completion/TestIOHandlerCompletion.py 
lldb/test/API/lang/c/enum_types/TestEnumTypes.py 
lldb/test/API/lang/c/function_types/TestFunctionTypes.py 
lldb/test/API/lang/c/register_variables/TestRegisterVariables.py 
lldb/test/API/lang/c/set_values/TestSetValues.py 
lldb/test/API/lang/c/strings/TestCStrings.py 
lldb/test/API/lang/c/tls_globals/TestTlsGlobals.py 
lldb/test/API/lang/cpp/char1632_t/TestChar1632T.py 
lldb/test/API/lang/cpp/class_static/TestStaticVariables.py 
lldb/test/API/lang/cpp/class_types/TestClassTypes.py 
lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py 
lldb/test/API/lang/cpp/namespace/TestNamespace.py 
lldb/test/API/lang/cpp/signed_types/TestSignedTypes.py 
lldb/test/API/lang/cpp/unsigned_types/TestUnsignedTypes.py 
lldb/test/API/lang/mixed/TestMixedLanguages.py 
lldb/test/API/lang/objc/foundation/TestObjCMethods.py 
lldb/test/API/lang/objc/foundation/TestObjCMethodsNSArray.py 
lldb/test/API/lang/objc/foundation/TestObjCMethodsNSError.py 
lldb/test/API/lang/objc/foundation/TestObjCMethodsString.py 
lldb/test/API/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py 
lldb/test/API/lang/objcxx/objc-builtin-types/TestObjCBuiltinTypes.py 
lldb/test/API/linux/aarch64/mte_core_file/TestAArch64LinuxMTEMemoryTagCoreFile.py
 
lldb/test/API/linux/aarch64/mte_tag_access/TestAArch64LinuxMTEMemoryTagAccess.py
 
lldb/test/API/linux/aarch64/mte_tag_faults/TestAArch64LinuxMTEMemoryTagFaults.py
 
lldb/test/API/linux/aarch64/tagged_memory_region/TestAArch64LinuxTaggedMemoryRegion.py
 lldb/test/API/macosx/add-dsym/TestAddDsymDownload.py 
lldb/test/API/macosx/lc-note/firmware-corefile/TestFirmwareCorefiles.py 
lldb/test/API/macosx/lc-note/kern-ver-str/TestKernVerStrLCNOTE.py 
lldb/test/API/macosx/lc-note/multiple-binary-corefile/TestMultipleBinaryCorefile.py
 lldb/

[Lldb-commits] [lldb] [lldb] Add frame recognizers for libc++ `std::invoke` (PR #105695)

2024-08-26 Thread Adrian Prantl via lldb-commits

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

Thanks!

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


[Lldb-commits] [clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)

2024-08-26 Thread Paul Zander via lldb-commits


@@ -284,7 +284,7 @@ def sync_csv(rows: List[Tuple], from_github: 
List[PaperInfo]) -> List[Tuple]:
 results.append(gh.for_printing())
 continue
 elif paper.status != gh.status:
-print(f"We found a CSV row and a Github issue with different 
statuses:\nrow: {row}\Github issue: {gh}")
+print(rf"We found a CSV row and a Github issue with different 
statuses:\nrow: {row}\Github issue: {gh}")

negril wrote:

See https://docs.python.org/3/reference/lexical_analysis.html#escape-sequences. 
The `\n` and `\G` are interpreted as an escape sequence. Hence necessitates the 
change.  

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


[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread Walter Erquinigo via lldb-commits

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


[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread Walter Erquinigo via lldb-commits

https://github.com/walter-erquinigo approved this pull request.

This LGTM. I'd just want a rename from `instructionReference` to 
`addressReference` or `instructionAddressReference` for clarity.

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


[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread Walter Erquinigo via lldb-commits


@@ -0,0 +1,36 @@
+//===-- InstructionBreakpoint.h --*- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_TOOLS_LLDB_DAP_INSTRUCTIONBREAKPOINT_H
+#define LLDB_TOOLS_LLDB_DAP_INSTRUCTIONBREAKPOINT_H
+
+#include "Breakpoint.h"
+#include "llvm/ADT/StringRef.h"
+
+namespace lldb_dap {
+
+// Instruction Breakpoint
+struct InstructionBreakpoint : public Breakpoint {
+
+  lldb::addr_t instructionReference;

walter-erquinigo wrote:

What about renaming this `addressReference`? 

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


[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread Walter Erquinigo via lldb-commits


@@ -4082,6 +4084,254 @@ void request__testGetTargetBreakpoints(const 
llvm::json::Object &request) {
   g_dap.SendJSON(llvm::json::Value(std::move(response)));
 }
 
+// "SetInstructionBreakpointsRequest" : {
+//   "allOf" : [
+// {"$ref" : "#/definitions/Request"}, {
+//   "type" : "object",
+//   "description" :
+//   "Replaces all existing instruction breakpoints. Typically, "
+//   "instruction breakpoints would be set from a disassembly window. "
+//   "\nTo clear all instruction breakpoints, specify an empty "
+//   "array.\nWhen an instruction breakpoint is hit, a `stopped` event 
"
+//   "(with reason `instruction breakpoint`) is generated.\nClients "
+//   "should only call this request if the corresponding capability "
+//   "`supportsInstructionBreakpoints` is true.",
+//   "properties" : {
+// "command" : {"type" : "string", "enum" :
+// ["setInstructionBreakpoints"]}, "arguments" :
+// {"$ref" : "#/definitions/SetInstructionBreakpointsArguments"}
+//   },
+//   "required" : [ "command", "arguments" ]
+// }
+//   ]
+// },
+//  "SetInstructionBreakpointsArguments"
+// : {
+//   "type" : "object",
+//   "description" : "Arguments for `setInstructionBreakpoints` request",
+//   "properties" : {
+// "breakpoints" : {
+//   "type" : "array",
+//   "items" : {"$ref" : "#/definitions/InstructionBreakpoint"},
+//   "description" : "The instruction references of the breakpoints"
+// }
+//   },
+//   "required" : ["breakpoints"]
+// },
+//   "SetInstructionBreakpointsResponse"
+// : {
+//   "allOf" : [
+// {"$ref" : "#/definitions/Response"}, {
+//   "type" : "object",
+//   "description" : "Response to `setInstructionBreakpoints` request",
+//   "properties" : {
+// "body" : {
+//   "type" : "object",
+//   "properties" : {
+// "breakpoints" : {
+//   "type" : "array",
+//   "items" : {"$ref" : "#/definitions/Breakpoint"},
+//   "description" :
+//   "Information about the breakpoints. The array elements
+//   " "correspond to the elements of the `breakpoints`
+//   array."
+// }
+//   },
+//   "required" : ["breakpoints"]
+// }
+//   },
+//   "required" : ["body"]
+// }
+//   ]
+// },
+// "InstructionBreakpoint" : {
+//   "type" : "object",
+//   "description" : "Properties of a breakpoint passed to the "
+//   "`setInstructionBreakpoints` request",
+//   "properties" : {
+// "instructionReference" : {
+//   "type" : "string",
+//   "description" :
+//   "The instruction reference of the breakpoint.\nThis should be a "
+//   "memory or instruction pointer reference from an
+//   `EvaluateResponse`, "
+//   "`Variable`, `StackFrame`, `GotoTarget`, or `Breakpoint`."
+// },
+// "offset" : {
+//   "type" : "integer",
+//   "description" : "The offset from the instruction reference in "
+//   "bytes.\nThis can be negative."
+// },
+// "condition" : {
+//   "type" : "string",
+//   "description" : "An expression for conditional breakpoints.\nIt is 
only
+//   "
+//   "honored by a debug adapter if the corresponding "
+//   "capability `supportsConditionalBreakpoints` is true."
+// },
+// "hitCondition" : {
+//   "type" : "string",
+//   "description" : "An expression that controls how many hits of the "
+//   "breakpoint are ignored.\nThe debug adapter is 
expected
+//   " "to interpret the expression as needed.\nThe
+//   attribute " "is only honored by a debug adapter if the
+//   corresponding " "capability
+//   `supportsHitConditionalBreakpoints` is true."
+// },
+// "mode" : {
+//   "type" : "string",
+//   "description" : "The mode of this breakpoint. If defined, this must be
+//   "
+//   "one of the `breakpointModes` the debug adapter "
+//   "advertised in its `Capabilities`."
+// }
+//   },
+//   "required" : ["instructionReference"]
+// },
+// "Breakpoint"
+// : {
+//   "type" : "object",
+//   "description" :
+//   "Information about a breakpoint created in `setBreakpoints`, "
+//   "`setFunctionBreakpoints`, `setInstructionBreakpoints`, or "
+//   "`setDataBreakpoints` requests.",
+//   "properties" : {
+// "id" : {
+//   "type" : "integer",
+//   "description" :
+//   "The ident

[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread Walter Erquinigo via lldb-commits


@@ -893,7 +957,13 @@ llvm::json::Value CreateThreadStopped(lldb::SBThread 
&thread,
   body.try_emplace("reason", "exception");
   EmplaceSafeString(body, "description", exc_bp->label);
 } else {
-  body.try_emplace("reason", "breakpoint");
+  InstructionBreakpoint *inst_bp =
+  g_dap.GetInstructionBPFromStopReason(thread);
+  if (inst_bp) {
+body.try_emplace("reason", "instruction breakpoint");

walter-erquinigo wrote:

nice!

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


[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread Walter Erquinigo via lldb-commits


@@ -996,4 +996,33 @@ void DAP::SetThreadFormat(llvm::StringRef format) {
   }
 }
 
+InstructionBreakpoint *
+DAP::GetInstructionBreakpoint(const lldb::break_id_t bp_id) {
+

walter-erquinigo wrote:

remove this line

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


[Lldb-commits] [clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)

2024-08-26 Thread Paul Zander via lldb-commits

negril wrote:

> This was suggested in #91856 and the suggestion there was that we need to 
> split it up per sub-project which is something @e-kwsm has been doing: 
> https://github.com/llvm/llvm-project/pulls/e-kwsm so I don't think this one 
> is needed.

That PR is 3 months old? What are the odds or the timeline of it getting merged?

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


[Lldb-commits] [lldb] [lldb-dap] Improve `stackTrace` and `exceptionInfo` DAP request handlers (PR #105905)

2024-08-26 Thread Walter Erquinigo via lldb-commits

https://github.com/walter-erquinigo approved this pull request.

This LGTM, and thank you for your diligence with writing tests.

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


[Lldb-commits] [clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)

2024-08-26 Thread Aiden Grossman via lldb-commits

boomanaiden154 wrote:

> That PR is 3 months old? What are the odds or the timeline of it getting 
> merged?

Probably whenever the author gets back to reviewers. There might be a couple 
rounds of review before things get pushed through, but patches for two 
subprojects have landed already.

The author doesn't seem particularly responsive though. If you want to pick it 
up, creating per-project PRs like done in the original PR linked, that would 
probably be best.

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


[Lldb-commits] [lldb] [lldb-dap] Improve `stackTrace` and `exceptionInfo` DAP request handlers (PR #105905)

2024-08-26 Thread John Harrison via lldb-commits

ashgti wrote:

@jeffreytan81 I moved the expensive call into the `exceptionInfo` request, this 
is only going to be triggered if a thread has the stop event = 'exception', so 
it shouldn't be triggered while stepping. This does remove the option you added 
in the prior commit, since I think this isolated the expensive call to a place 
where the additional information it provides justifies the call and is only 
called in specific circumstances.

LMKWYT

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


[Lldb-commits] [clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)

2024-08-26 Thread Paul Zander via lldb-commits

negril wrote:

> > That PR is 3 months old? What are the odds or the timeline of it getting 
> > merged?
> 
> Probably whenever the author gets back to reviewers. There might be a couple 
> rounds of review before things get pushed through, but patches for two 
> subprojects have landed already.
> 
> The author doesn't seem particularly responsive though. If you want to pick 
> it up, creating per-project PRs like done in the original PR linked, that 
> would probably be best.

Sounds good.

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


[Lldb-commits] [clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)

2024-08-26 Thread Sam James via lldb-commits


@@ -284,7 +284,7 @@ def sync_csv(rows: List[Tuple], from_github: 
List[PaperInfo]) -> List[Tuple]:
 results.append(gh.for_printing())
 continue
 elif paper.status != gh.status:
-print(f"We found a CSV row and a Github issue with different 
statuses:\nrow: {row}\Github issue: {gh}")
+print(rf"We found a CSV row and a Github issue with different 
statuses:\nrow: {row}\Github issue: {gh}")

thesamesam wrote:

I believe @negril is right.

Note that https://docs.python.org/3/whatsnew/3.12.html#other-language-changes 
doesn't say it's exclusive to regex:
> A backslash-character pair that is not a valid escape sequence now generates 
> a 
> [SyntaxWarning](https://docs.python.org/3/library/exceptions.html#SyntaxWarning),
>  instead of 
> [DeprecationWarning](https://docs.python.org/3/library/exceptions.html#DeprecationWarning).
>  For example, re.compile("\d+\.\d+") now emits a 
> [SyntaxWarning](https://docs.python.org/3/library/exceptions.html#SyntaxWarning)
>  ("\d" is an invalid escape sequence, use raw strings for regular expression: 
> re.compile(r"\d+\.\d+")). In a future Python version, 
> [SyntaxError](https://docs.python.org/3/library/exceptions.html#SyntaxError) 
> will eventually be raised, instead of 
> [SyntaxWarning](https://docs.python.org/3/library/exceptions.html#SyntaxWarning).
>  (Contributed by Victor Stinner in 
> [gh-98401](https://github.com/python/cpython/issues/98401).)

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


[Lldb-commits] [lldb] [lldb] Add 'FindInMemory()' overload for PostMortemProcess. (PR #102536)

2024-08-26 Thread Miro Bucko via lldb-commits

mbucko wrote:

> Let me know if you guys don't want this patch in. I will closed it and apply 
> it to our local branch. @jasonmolenda @labath

@labath just a friendly ping

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


[Lldb-commits] [clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)

2024-08-26 Thread Sam James via lldb-commits

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


[Lldb-commits] [lldb] bbf2781 - [lldb] Reformat comment (NFC)

2024-08-26 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2024-08-26T10:05:30-07:00
New Revision: bbf2781bc49aee4d7ee8ec40dcf7316db360c454

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

LOG: [lldb] Reformat comment (NFC)

Added: 


Modified: 
lldb/include/lldb/Utility/Status.h

Removed: 




diff  --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index fa5768141fa45d..a80ebe89e562dd 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -181,11 +181,12 @@ class Status {
   bool Success() const;
 
 protected:
-  /// Member variables
-  ValueType m_code = 0; ///< Status code as an integer value.
-  lldb::ErrorType m_type =
-  lldb::eErrorTypeInvalid;  ///< The type of the above error code.
-  mutable std::string m_string; ///< A string representation of the error code.
+  /// Status code as an integer value.
+  ValueType m_code = 0;
+  /// The type of the above error code.
+  lldb::ErrorType m_type = lldb::eErrorTypeInvalid;
+  /// A string representation of the error code.
+  mutable std::string m_string;
 private:
   explicit Status(const llvm::formatv_object_base &payload) {
 SetErrorToGenericError();



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


[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

2024-08-26 Thread Vladislav Dzhidzhoev via lldb-commits

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

>From e40ca68a934d0595ebc6c07010a4f6a814fa026f Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev 
Date: Sat, 27 Jul 2024 02:39:32 +0200
Subject: [PATCH 1/3] [lldb][test] Improve toolchain detection in
 Makefile.rules

This fix is based on a problem with cxx_compiler and cxx_linker macros
on Windows.
There was an issue with compiler detection in paths containing "icc". In
such case, Makefile.rules thought it was provided with icc compiler.

To solve that, utilities detection has been rewritten in Python.
The last element of compiler's path is separated, taking into account
platform path delimiter, and compiler type is extracted, with regard
of possible cross-toolchain prefix.  Paths for additional tools,
like OBJCOPY, are initialized with tools built with LLVM if USE_LLVM_TOOLS
is on, to achieve better portability for Windows.
Quotes from paths are removed in Makefile.rules, that may be added when
arguments are passed from Python to make.
---
 .../Python/lldbsuite/test/builders/builder.py | 114 +-
 .../Python/lldbsuite/test/make/Makefile.rules | 103 +---
 .../breakpoint/breakpoint_ids/Makefile|   2 +-
 .../breakpoint/breakpoint_locations/Makefile  |   2 +-
 .../consecutive_breakpoints/Makefile  |   2 +-
 .../functionalities/breakpoint/cpp/Makefile   |   2 +-
 .../dummy_target_breakpoints/Makefile |   2 +-
 .../require_hw_breakpoints/Makefile   |   2 +-
 .../breakpoint/step_over_breakpoint/Makefile  |   2 +-
 .../thread_plan_user_breakpoint/Makefile  |   2 +-
 .../ObjCDataFormatterTestCase.py  |   4 +-
 .../TestNSDictionarySynthetic.py  |   4 +-
 .../nssetsynth/TestNSSetSynthetic.py  |   4 +-
 .../poarray/TestPrintObjectArray.py   |   4 +-
 .../functionalities/inline-stepping/Makefile  |   2 +-
 .../postmortem/minidump-new/makefile.txt  |   1 +
 .../lang/objc/orderedset/TestOrderedSet.py|   4 +-
 .../TestObjCSingleEntryDictionary.py  |   4 +-
 lldb/test/API/macosx/macCatalyst/Makefile |   1 +
 .../macCatalystAppMacOSFramework/Makefile |   1 +
 .../macosx/simulator/TestSimulatorPlatform.py |   4 +-
 .../API/python_api/frame/inlines/Makefile |   2 +-
 .../lldb-server/TestAppleSimulatorOSType.py   |   4 +-
 23 files changed, 168 insertions(+), 104 deletions(-)

diff --git a/lldb/packages/Python/lldbsuite/test/builders/builder.py 
b/lldb/packages/Python/lldbsuite/test/builders/builder.py
index 4ea9a86c1d5fc9..ca91684ca065d6 100644
--- a/lldb/packages/Python/lldbsuite/test/builders/builder.py
+++ b/lldb/packages/Python/lldbsuite/test/builders/builder.py
@@ -1,10 +1,12 @@
 import os
+import pathlib
 import platform
 import subprocess
 import sys
 import itertools
 
 import lldbsuite.test.lldbtest as lldbtest
+import lldbsuite.test.lldbplatformutil as lldbplatformutil
 import lldbsuite.test.lldbutil as lldbutil
 from lldbsuite.test import configuration
 from lldbsuite.test_event import build_exception
@@ -96,16 +98,120 @@ def getArchSpec(self, architecture):
 """
 return ["ARCH=" + architecture] if architecture else []
 
-def getCCSpec(self, compiler):
+def getToolchainSpec(self, compiler):
 """
-Helper function to return the key-value string to specify the compiler
+Helper function to return the key-value strings to specify the 
toolchain
 used for the make system.
 """
 cc = compiler if compiler else None
 if not cc and configuration.compiler:
 cc = configuration.compiler
+
 if cc:
-return ['CC="%s"' % cc]
+exe_ext = ""
+if lldbplatformutil.getHostPlatform() == "windows":
+exe_ext = ".exe"
+
+cc = cc.strip()
+cc_path = pathlib.Path(cc)
+cc = cc_path.as_posix()
+
+# We can get CC compiler string in the following formats:
+#  [] - such as 'xrun clang', 'xrun 
/usr/bin/clang' & etc
+#
+# Where  could contain the following parts:
+#   [.]   - sucn as 
'clang', 'clang.exe' ('clamg-cl.exe'?)
+#   -[.]   - such as 
'armv7-linux-gnueabi-gcc'
+#   /[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+#   /-[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+
+cc_ext = cc_path.suffix
+# Compiler name without extension
+cc_name = cc_path.stem.split(" ")[-1]
+
+# A kind of compiler (canonical name): clang, gcc, cc & etc.
+cc_type = cc_name
+# A triple prefix of compiler name: gcc
+cc_prefix = ""
+if not "clang-cl" in cc_name and not "llvm-gcc" in cc_name:
+cc_name_parts = cc_name.split("-")
+cc_type = cc_name_parts[-1

[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)

2024-08-26 Thread via lldb-commits

jimingham wrote:

This is compiling the "get me extended backtrace info function".  That's a 
ClangFunction, so we should only compile it once and then reuse it for the rest 
of the session.  Is it possible we aren't reusing this?  After all, this is a 
compile of a function that's pretty careful not to have a lot of external type 
references, so it is odd it's taking that long to compile!

Jim


> On Aug 23, 2024, at 7:09 PM, jeffreytan81 ***@***.***> wrote:
> 
> 
> And just for fun, here is an extreme one with 18 seconds of sampling time, 
> 99.6% time is from this hot path. Note: they are all from linux machines 
> because we only enable perf sampling by default for linux platform so we have 
> no Mac data.
> 
> # time of first sample : 2646936.334980
> # time of last sample : 2646954.518041
> # sample duration :  18183.061 ms
> 
> 99.63% 0.00%  lldb-dap lldb-dap  [.] main
> |
> ---main
>lldb_dap::DAP::Loop()
>lldb_dap::DAP::HandleObject(llvm::json::Object const&)
>(anonymous namespace)::request_stackTrace(llvm::json::Object 
> const&)
>|
> --99.60%--lldb::SBThread::GetCurrentExceptionBacktrace()
>   lldb_private::Thread::GetCurrentExceptionBacktrace()
>   lldb_private::Thread::GetCurrentException()
>   
> lldb_private::ItaniumABILanguageRuntime::GetExceptionObjectForThread(std::shared_ptr)
>   |
>
> --99.60%--lldb_private::FunctionCaller::ExecuteFunction(lldb_private::ExecutionContext&,
>  unsigned long*, lldb_private::EvaluateExpressionOptions const&, 
> lldb_private::DiagnosticManager&, lldb_private::Value&)
>  |
>  
> |--44.33%--lldb_private::ClangFunctionCaller::CompileFunction(std::shared_ptr,
>  lldb_private::DiagnosticManager&)
>  |  |
>  |  
> |--39.56%--lldb_private::ClangExpressionParser::ParseInternal(lldb_private::DiagnosticManager&,
>  clang::CodeCompleteConsumer*, unsigned int, unsigned int)
>  |  |  |
>  |  |  
> |--21.86%--clang::ParseAST(clang::Sema&, bool, bool)
>  |  |  |  |
>  |  |  |  
> |--17.47%--clang::Parser::ParseFirstTopLevelDecl(clang::OpaquePtr&,
>  clang::Sema::ModuleImportState&)
>  |  |  |  |   
>clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, 
> clang::Sema::ModuleImportState&)
>  |  |  |  |   
>clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, 
> clang::ParsedAttributes&, clang::ParsingDeclSpec*)
>  |  |  |  |   
>
> clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, 
> clang::ParsedAttributes&, clang::ParsingDeclSpec*, clang::AccessSpecifier)
>  |  |  |  |   
>clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&, 
> clang::ParsedAttributes&, clang::ParsingDeclSpec&,
> ...
> —
> Reply to this email directly, view it on GitHub 
> , 
> or unsubscribe 
> .
> You are receiving this because your review was requested.
> 



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


[Lldb-commits] [clang] [lldb] Use CLANG_RESOURCE_DIR more consistently (PR #103388)

2024-08-26 Thread Kim Gräsman via lldb-commits

kimgr wrote:

> > Is there an out-of-tree scenario where CLANG_RESOURCE_DIR needs to be 
> > replaced with something else at runtime, i.e. a real use-case for the 
> > optional CustomResourceDir optional argument I removed?
> 
> @kimgr I have also looked for this and I haven't found an use-case where this 
> would be appropriate. In fact, I think it's wrong to not take 
> `CLANG_RESOURCE_DIR` as part of the output from 
> `driver::Driver::GetResourcesPath()` because that would generate wrong 
> results for builds that do set `CLANG_RESOURCE_DIR`, e.g. Fedora's builds.

@tuliom I think it might be possible that a standalone tool would want to use 
its own executable path and a hardcoded relative `CustomResourceDir`, but then 
maybe it would be better to just build the relevant path without calling 
`GetResourcesPath`.

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


[Lldb-commits] [clang] [lldb] Use CLANG_RESOURCE_DIR more consistently (PR #103388)

2024-08-26 Thread Kim Gräsman via lldb-commits

kimgr wrote:

> > Do we need anything more to make progress with this PR?
> 
> @kimgr Do you have committer permission? Would you like some help to get this 
> merged?

Oh, no, I don't, I would need someone to merge this for me. It's still pretty 
early in the v.20 cycle, right, so maybe this is a good time to try and see if 
it sticks?

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


[Lldb-commits] [clang] [lldb] Use CLANG_RESOURCE_DIR more consistently (PR #103388)

2024-08-26 Thread Tulio Magno Quites Machado Filho via lldb-commits

tuliom wrote:

Agreed. Let me merge this.

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


[Lldb-commits] [lldb] 924a7d8 - Use CLANG_RESOURCE_DIR more consistently (#103388)

2024-08-26 Thread via lldb-commits

Author: Kim Gräsman
Date: 2024-08-26T14:49:56-03:00
New Revision: 924a7d83b4287b3b85dd1ca29d2d3e1f0a10ea68

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

LOG: Use CLANG_RESOURCE_DIR more consistently (#103388)

When Clang is consumed as a library, the CLANG_RESOURCE_DIR definition
is not exported from the CMake system, so external clients will be
unable to compute the same resource dir as Clang itself would, because
they don't know what to pass for the optional CustomResourceDir
argument.

All call sites except one would pass CLANG_RESOURCE_DIR to
Driver::GetResourcesPath. It seems the one exception in libclang
CIndexer was an oversight.

Move the use of CLANG_RESOURCE_DIR into GetResourcesPath and remove the
optional argument to avoid this inconsistency between internal and
external clients.

Added: 


Modified: 
clang/include/clang/Driver/Driver.h
clang/lib/Driver/Driver.cpp
clang/lib/Frontend/CompilerInvocation.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
lldb/unittests/Expression/ClangParserTest.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Driver.h 
b/clang/include/clang/Driver/Driver.h
index 84eadd42880a50..9177d56718ee77 100644
--- a/clang/include/clang/Driver/Driver.h
+++ b/clang/include/clang/Driver/Driver.h
@@ -379,8 +379,7 @@ class Driver {
 
   /// Takes the path to a binary that's either in bin/ or lib/ and returns
   /// the path to clang's resource directory.
-  static std::string GetResourcesPath(StringRef BinaryPath,
-  StringRef CustomResourceDir = "");
+  static std::string GetResourcesPath(StringRef BinaryPath);
 
   Driver(StringRef ClangExecutable, StringRef TargetTriple,
  DiagnosticsEngine &Diags, std::string Title = "clang LLVM compiler",

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index e12416e51f8d24..43002add33774b 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -171,18 +171,18 @@ getHIPOffloadTargetTriple(const Driver &D, const ArgList 
&Args) {
 }
 
 // static
-std::string Driver::GetResourcesPath(StringRef BinaryPath,
- StringRef CustomResourceDir) {
+std::string Driver::GetResourcesPath(StringRef BinaryPath) {
   // Since the resource directory is embedded in the module hash, it's 
important
   // that all places that need it call this function, so that they get the
   // exact same string ("a/../b/" and "b/" get 
diff erent hashes, for example).
 
   // Dir is bin/ or lib/, depending on where BinaryPath is.
-  std::string Dir = std::string(llvm::sys::path::parent_path(BinaryPath));
-
+  StringRef Dir = llvm::sys::path::parent_path(BinaryPath);
   SmallString<128> P(Dir);
-  if (CustomResourceDir != "") {
-llvm::sys::path::append(P, CustomResourceDir);
+
+  StringRef ConfiguredResourceDir(CLANG_RESOURCE_DIR);
+  if (!ConfiguredResourceDir.empty()) {
+llvm::sys::path::append(P, ConfiguredResourceDir);
   } else {
 // On Windows, libclang.dll is in bin/.
 // On non-Windows, libclang.so/.dylib is in lib/.
@@ -239,7 +239,7 @@ Driver::Driver(StringRef ClangExecutable, StringRef 
TargetTriple,
 #endif
 
   // Compute the path to the resource directory.
-  ResourceDir = GetResourcesPath(ClangExecutable, CLANG_RESOURCE_DIR);
+  ResourceDir = GetResourcesPath(ClangExecutable);
 }
 
 void Driver::setDriverMode(StringRef Value) {

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 0bb4175dd021ee..32628c5e84332d 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -3130,7 +3130,7 @@ std::string CompilerInvocation::GetResourcesPath(const 
char *Argv0,
  void *MainAddr) {
   std::string ClangExecutable =
   llvm::sys::fs::getMainExecutable(Argv0, MainAddr);
-  return Driver::GetResourcesPath(ClangExecutable, CLANG_RESOURCE_DIR);
+  return Driver::GetResourcesPath(ClangExecutable);
 }
 
 static void GenerateHeaderSearchArgs(const HeaderSearchOptions &Opts,

diff  --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp 
b/lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
index 6064c02c7fd67d..6de851081598fd 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
@@ -53,7 +53,7 @@ static bool DefaultComputeClangResourceDirectory(FileSpec 
&lldb_shlib_spec,
   std::string raw_path = lldb_shlib_spec.GetPath();
   llvm::StringRef parent_dir = llvm::sys::path::parent_path(raw_path);
   static const std::string clang_resource_path =
-  clang::driver::Driver::GetResourcesPath("bin/lldb", CLANG_RESOURCE_DIR);
+  

[Lldb-commits] [clang] [lldb] Use CLANG_RESOURCE_DIR more consistently (PR #103388)

2024-08-26 Thread Tulio Magno Quites Machado Filho via lldb-commits

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


[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread Santhosh Kumar Ellendula via lldb-commits


@@ -996,4 +996,33 @@ void DAP::SetThreadFormat(llvm::StringRef format) {
   }
 }
 
+InstructionBreakpoint *
+DAP::GetInstructionBreakpoint(const lldb::break_id_t bp_id) {
+

santhoshe447 wrote:

I did not understand this.

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


[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread Santhosh Kumar Ellendula via lldb-commits


@@ -0,0 +1,36 @@
+//===-- InstructionBreakpoint.h --*- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_TOOLS_LLDB_DAP_INSTRUCTIONBREAKPOINT_H
+#define LLDB_TOOLS_LLDB_DAP_INSTRUCTIONBREAKPOINT_H
+
+#include "Breakpoint.h"
+#include "llvm/ADT/StringRef.h"
+
+namespace lldb_dap {
+
+// Instruction Breakpoint
+struct InstructionBreakpoint : public Breakpoint {
+
+  lldb::addr_t instructionReference;

santhoshe447 wrote:

renamed to "instructionAddressReference"  from instructionReference.

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


[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread Walter Erquinigo via lldb-commits


@@ -996,4 +996,33 @@ void DAP::SetThreadFormat(llvm::StringRef format) {
   }
 }
 
+InstructionBreakpoint *
+DAP::GetInstructionBreakpoint(const lldb::break_id_t bp_id) {
+

walter-erquinigo wrote:

The empty line :) Just to keep consistency with the rest of the codebase.

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


[Lldb-commits] [lldb] Add logs for SymbolFileDWARF::FindTypes (PR #106030)

2024-08-26 Thread Augusto Noronha via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb] Add frame recognizers for libc++ `std::invoke` (PR #105695)

2024-08-26 Thread Petr Hosek via lldb-commits

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


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


[Lldb-commits] [clang] [lldb] Use CLANG_RESOURCE_DIR more consistently (PR #103388)

2024-08-26 Thread Kim Gräsman via lldb-commits

kimgr wrote:

Thanks!

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


[Lldb-commits] [lldb] 89c27d6 - [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (#105278)

2024-08-26 Thread via lldb-commits

Author: Santhosh Kumar Ellendula
Date: 2024-08-27T00:19:39+05:30
New Revision: 89c27d6b07dd03a71e5692caa4e20ab14f948921

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

LOG: [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (#105278)

Added support for "supportsInstructionBreakpoints" capability and now it
this command is triggered when we set instruction breakpoint.
We need this support as part of enabling disassembly view debugging.
Following features should work as part of this feature enablement:

1. Settings breakpoints in disassembly view: Unsetting the breakpoint is
not happening from the disassembly view. Currently we need to unset
breakpoint manually from the breakpoint List. Multiple breakpoints are
getting set for the same $

2. Step over, step into, continue in the disassembly view

The format for DisassembleRequest and DisassembleResponse at
https://raw.githubusercontent.com/microsoft/vscode/master/src/vs/workbench/contrib/debug/common/debugProtocol.d.ts
.

Ref Images:
Set instruction breakpoint in disassembly view:

![image](https://github.com/user-attachments/assets/833bfb34-86f4-40e2-8c20-14b638a612a2)

After issuing continue:

![image](https://github.com/user-attachments/assets/884572a3-915e-422b-b8dd-d132e5c00de6)

-

Co-authored-by: Santhosh Kumar Ellendula 
Co-authored-by: Santhosh Kumar Ellendula 

Added: 
lldb/test/API/tools/lldb-dap/instruction-breakpoint/Makefile

lldb/test/API/tools/lldb-dap/instruction-breakpoint/TestDAP_instruction_breakpoint.py
lldb/test/API/tools/lldb-dap/instruction-breakpoint/main.cpp
lldb/tools/lldb-dap/InstructionBreakpoint.cpp
lldb/tools/lldb-dap/InstructionBreakpoint.h

Modified: 
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
lldb/tools/lldb-dap/CMakeLists.txt
lldb/tools/lldb-dap/DAP.cpp
lldb/tools/lldb-dap/DAP.h
lldb/tools/lldb-dap/DAPForward.h
lldb/tools/lldb-dap/JSONUtils.cpp
lldb/tools/lldb-dap/JSONUtils.h
lldb/tools/lldb-dap/lldb-dap.cpp

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index 874383a13e2bb6..b095171d8fd1a4 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -1099,6 +1099,20 @@ def terminate(self):
 self.send.close()
 # self.recv.close()
 
+def request_setInstructionBreakpoints(self, memory_reference=[]):
+breakpoints = []
+for i in memory_reference:
+args_dict = {
+"instructionReference": i,
+}
+breakpoints.append(args_dict)
+args_dict = {"breakpoints": breakpoints}
+command_dict = {
+"command": "setInstructionBreakpoints",
+"type": "request",
+"arguments": args_dict,
+}
+return self.send_recv(command_dict)
 
 class DebugAdaptorServer(DebugCommunication):
 def __init__(

diff  --git 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index 86eba355da83db..709b7aff11d7f2 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -81,7 +81,10 @@ def verify_breakpoint_hit(self, breakpoint_ids):
 body = stopped_event["body"]
 if "reason" not in body:
 continue
-if body["reason"] != "breakpoint":
+if (
+body["reason"] != "breakpoint"
+and body["reason"] != "instruction breakpoint"
+):
 continue
 if "description" not in body:
 continue

diff  --git a/lldb/test/API/tools/lldb-dap/instruction-breakpoint/Makefile 
b/lldb/test/API/tools/lldb-dap/instruction-breakpoint/Makefile
new file mode 100644
index 00..697527c4e55223
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/instruction-breakpoint/Makefile
@@ -0,0 +1,6 @@
+CXX_SOURCES := main-copy.cpp
+CXXFLAGS_EXTRAS := -O0 -g
+include Makefile.rules
+
+main-copy.cpp: main.cpp
+   cp -f $< $@

diff  --git 
a/lldb/test/API/tools/lldb-dap/instruction-breakpoint/TestDAP_instruction_breakpoint.py
 
b/lldb/test/API/tools/lldb-dap/instruction-breakpoint/TestDAP_instruction_breakpoint.py
new file mode 100644
index 00..91b04aca7b7bd8
--- /dev/null
+++ 
b/lldb/test/API/tools/lldb-dap/instruction-breakpoint/TestDAP_instruction_breakpoint.p

[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread Santhosh Kumar Ellendula via lldb-commits

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


[Lldb-commits] [lldb] [llvm] [Docs] Use cacheable myst_heading_slug_func value (PR #104847)

2024-08-26 Thread Alex Langford via lldb-commits

bulbazord wrote:

I don't know much about the documentation but I added the two people who touch 
it more frequently than anyone else.

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


[Lldb-commits] [lldb] Add logs for SymbolFileDWARF::FindTypes (PR #106030)

2024-08-26 Thread Michael Buch via lldb-commits


@@ -2779,7 +2788,19 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
 return !results.Done(query); // Keep iterating if we aren't done.
   });
 
-  if (results.Done(query))
+  auto CheckIsDoneAndLog = [&results, &query, log, type_basename, this] {

Michael137 wrote:

Thanks for adding this back. Usually I'm in favour of DRY but personally I find 
it more readable if you just inline the logging, instead of the lambda. Mind 
changing that?

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


[Lldb-commits] [lldb] Add logs for SymbolFileDWARF::FindTypes (PR #106030)

2024-08-26 Thread Michael Buch via lldb-commits


@@ -2779,7 +2788,19 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
 return !results.Done(query); // Keep iterating if we aren't done.
   });
 
-  if (results.Done(query))
+  auto CheckIsDoneAndLog = [&results, &query, log, type_basename, this] {

Michael137 wrote:

And for the one in the `-gsimple-template-names` block, it might be worth 
adding an something in the log that we found it during the 
simple-template-names (i.e., stripped template args) lookup

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


[Lldb-commits] [lldb] Add logs for SymbolFileDWARF::FindTypes (PR #106030)

2024-08-26 Thread Michael Buch via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Add frame recognizers for libc++ `std::invoke` (PR #105695)

2024-08-26 Thread Petr Hosek via lldb-commits

petrhosek wrote:

@vogelsgesang Can we please merge this PR to unbreak the builders that were 
broken by #104523?

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


[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)

2024-08-26 Thread LLVM Continuous Integration via lldb-commits

llvm-ci wrote:

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

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


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

```
Step 6 (test) failure: build (failure)
...
UNSUPPORTED: lldb-api :: 
tools/lldb-dap/console/TestDAP_redirection_to_console.py (1124 of 2011)
UNSUPPORTED: lldb-api :: tools/lldb-dap/coreFile/TestDAP_coreFile.py (1125 of 
2011)
UNSUPPORTED: lldb-api :: 
tools/lldb-dap/databreakpoint/TestDAP_setDataBreakpoints.py (1126 of 2011)
UNSUPPORTED: lldb-api :: tools/lldb-dap/disassemble/TestDAP_disassemble.py 
(1127 of 2011)
UNSUPPORTED: lldb-api :: tools/lldb-dap/disconnect/TestDAP_disconnect.py (1128 
of 2011)
UNSUPPORTED: lldb-api :: tools/lldb-dap/evaluate/TestDAP_evaluate.py (1129 of 
2011)
UNSUPPORTED: lldb-api :: tools/lldb-dap/exception/TestDAP_exception.py (1130 of 
2011)
PASS: lldb-api :: tools/lldb-dap/commands/TestDAP_commands.py (1131 of 2011)
UNSUPPORTED: lldb-api :: tools/lldb-dap/launch/TestDAP_launch.py (1132 of 2011)
UNRESOLVED: lldb-api :: 
tools/lldb-dap/instruction-breakpoint/TestDAP_instruction_breakpoint.py (1133 
of 2011)
 TEST 'lldb-api :: 
tools/lldb-dap/instruction-breakpoint/TestDAP_instruction_breakpoint.py' FAILED 

Script:
--
C:/Users/tcwg/scoop/apps/python/current/python.exe 
C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/llvm-project/lldb\test\API\dotest.py
 -u CXXFLAGS -u CFLAGS --env 
OBJCOPY=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/llvm-objcopy.exe
 --env LLVM_LIBS_DIR=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./lib 
--env 
LLVM_INCLUDE_DIR=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/include 
--env LLVM_TOOLS_DIR=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin 
--arch aarch64 --build-dir 
C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex 
--lldb-module-cache-dir 
C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-lldb\lldb-api
 --clang-module-cache-dir 
C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-clang\lldb-api
 --executable 
C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/lldb.exe --compiler 
C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/clang.exe --dsymutil 
C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/dsymutil.exe 
--llvm-tools-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin 
--lldb-obj-root C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/tools/lldb 
--lldb-libs-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./lib 
--skip-category=watchpoint 
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\tools\lldb-dap\instruction-breakpoint
 -p TestDAP_instruction_breakpoint.py
--
Exit Code: 1

Command Output (stdout):
--
lldb version 20.0.0git (https://github.com/llvm/llvm-project.git revision 
89c27d6b07dd03a71e5692caa4e20ab14f948921)
  clang revision 89c27d6b07dd03a71e5692caa4e20ab14f948921
  llvm revision 89c27d6b07dd03a71e5692caa4e20ab14f948921
Skipping the following test categories: ['watchpoint', 'libc++', 'libstdcxx', 
'dwo', 'dsym', 'gmodules', 'debugserver', 'objc', 'fork', 'pexpect']


--
Command Output (stderr):
--
FAIL: LLDB 
(C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe-aarch64) :: 
test_instruction_breakpoint 
(TestDAP_instruction_breakpoint.TestDAP_InstructionBreakpointTestCase.test_instruction_breakpoint)

==

ERROR: test_instruction_breakpoint 
(TestDAP_instruction_breakpoint.TestDAP_InstructionBreakpointTestCase.test_instruction_breakpoint)

--

Error when building test subject.



Build Command:

make 
'VPATH=C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\tools\lldb-dap\instruction-breakpoint'
 -C 
'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\lldb-test-build.noindex\tools\lldb-dap\instruction-breakpoint\TestDAP_instruction_breakpoint.test_instruction_breakpoint'
 -I 
'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\tools\lldb-dap\instruction-breakpoint'
 -I 
'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\make'
 -f 
'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\tools\lldb-dap\instruction-breakpoint\Makefile'
 all ARCH=aarch64 
'CC="C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe"' 
'CLANG_MODULE_CACHE_DIR=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-clang\lldb-api'
 LLDB_OBJ_ROOT=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/tools/lldb 
OS=Windows_NT HOST_OS=Windows_NT



Build Command Output:

[Lldb-commits] [lldb] [llvm] [Docs] Use cacheable myst_heading_slug_func value (PR #104847)

2024-08-26 Thread Med Ismail Bennani via lldb-commits

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

LGTM

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


[Lldb-commits] [lldb] [llvm] [Docs] Use cacheable myst_heading_slug_func value (PR #104847)

2024-08-26 Thread Med Ismail Bennani via lldb-commits

medismailben wrote:

> Requires myst_parser 0.19.0 (specifically 
> [executablebooks/MyST-Parser#696](https://github.com/executablebooks/MyST-Parser/pull/696))
>  which is over a year old by now. Do we mandate any minimum version for these 
> dependencies?

Kinda: 
[llvm/docs/requirements.txt](https://github.com/llvm/llvm-project/blob/main/llvm/docs/requirements.txt)
 describes the dependencies required to build the documentation and their 
version. It looks like for `myst_parser` the builder should have version 2.0.0 
so your patch should be good.

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


[Lldb-commits] [clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)

2024-08-26 Thread Med Ismail Bennani via lldb-commits

medismailben wrote:

Nice! Please make sure to run the python formatter (`darker`) before landing 
this.

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


[Lldb-commits] [lldb] [lldb] Cleanup dyld_process_t after constructing SharedCacheInfo (PR #106157)

2024-08-26 Thread Alex Langford via lldb-commits

https://github.com/bulbazord created 
https://github.com/llvm/llvm-project/pull/106157

Without calling `dyld_process_dispose`, LLDB will leak the memory associated 
with the `dyld_process_t`.

rdar://134738265

>From 62bd1e90ea84cfb7bd6d18529918be544d036221 Mon Sep 17 00:00:00 2001
From: Alex Langford 
Date: Mon, 26 Aug 2024 16:13:59 -0700
Subject: [PATCH] [lldb] Cleanup dyld_process_t after constructing
 SharedCacheInfo

Without calling `dyld_process_dispose`, LLDB will leak the memory
associated with the `dyld_process_t`.

rdar://134738265
---
 lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm 
b/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
index d27bd1b7426e6c..6e924fdc684cfe 100644
--- a/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
+++ b/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
@@ -650,12 +650,15 @@ static bool ResolveAndVerifyCandidateSupportDir(FileSpec 
&path) {
   if (!dyld_process)
 return false;
 
+  auto cleanup_process_on_exit =
+  llvm::make_scope_exit([&]() { dyld_process_dispose(dyld_process); });
+
   dyld_process_snapshot_t snapshot =
   dyld_process_snapshot_create_for_process(dyld_process, nullptr);
   if (!snapshot)
 return false;
 
-  auto on_exit =
+  auto cleanup_snapshot_on_exit =
   llvm::make_scope_exit([&]() { dyld_process_snapshot_dispose(snapshot); 
});
 
   dyld_shared_cache_t shared_cache =

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


[Lldb-commits] [lldb] [lldb] Cleanup dyld_process_t after constructing SharedCacheInfo (PR #106157)

2024-08-26 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Alex Langford (bulbazord)


Changes

Without calling `dyld_process_dispose`, LLDB will leak the memory associated 
with the `dyld_process_t`.

rdar://134738265

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


1 Files Affected:

- (modified) lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm (+4-1) 


``diff
diff --git a/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm 
b/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
index d27bd1b7426e6c..6e924fdc684cfe 100644
--- a/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
+++ b/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
@@ -650,12 +650,15 @@ static bool ResolveAndVerifyCandidateSupportDir(FileSpec 
&path) {
   if (!dyld_process)
 return false;
 
+  auto cleanup_process_on_exit =
+  llvm::make_scope_exit([&]() { dyld_process_dispose(dyld_process); });
+
   dyld_process_snapshot_t snapshot =
   dyld_process_snapshot_create_for_process(dyld_process, nullptr);
   if (!snapshot)
 return false;
 
-  auto on_exit =
+  auto cleanup_snapshot_on_exit =
   llvm::make_scope_exit([&]() { dyld_process_snapshot_dispose(snapshot); 
});
 
   dyld_shared_cache_t shared_cache =

``




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


[Lldb-commits] [lldb] [lldb-dap] Support inspecting memory (PR #104317)

2024-08-26 Thread Greg Clayton via lldb-commits


@@ -1085,6 +1084,17 @@ std::string 
VariableDescription::GetResult(llvm::StringRef context) {
   return description.trim().str();
 }
 
+std::optional GetMemoryReference(lldb::SBValue v) {
+  if (!v.GetType().IsPointerType() && !v.GetType().IsArrayType())
+return std::nullopt;
+

clayborg wrote:

I used to love being able to see a value in memory with the Metrowerks IDE many 
years ago. Do we want to just alway return the load address?
```
std::optional GetMemoryReference(lldb::SBValue v) {
  lldb::addr_t load_addr = v.GetLoadAddress();
  if (load_addr != LLDB_INVALID_ADDRESS)
return load_addr;
  return std::nullopt;
}
```
This way we always show the address of any value. If the value is a pointer, we 
will show the address of pointer itself in memory, not what is being pointed 
to. This way these will have different memory addresses:
```
int my_value;
int* my_ptr = &my_value;
```
The specification states:
```
/**
 * A memory reference to a location appropriate for this result.
 * For pointer type eval results, this is generally a reference to the
 * memory address contained in the pointer.
 * This attribute may be returned by a debug adapter if corresponding
 * capability `supportsMemoryReferences` is true.
 */
memoryReference?: string;
```

So `A memory reference to a location appropriate for this result.` in my mind 
is where the value lives in memory and I would like to see any value and where 
it is in memory. Even though the next sentence mentions a pointer should be 
dereferenced. Seems like a shame to only allow us to view memory for pointers 
as they are the easiest to view in memory with `memory read` commands already 
because we can copy the value of the pointer from the variable view and then 
type `memory read ` and see the memory in the debug console already. But 
if we have a structure that lives in memory, it is harder to see that value in 
memory as we would always need to first type `&myStruct` in the debug console 
just to get a pointer so that we could then open up the memory viewer.

Happy to hear opinions on this.

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


[Lldb-commits] [lldb] Add logs for SymbolFileDWARF::FindTypes (PR #106030)

2024-08-26 Thread Dmitrii Galimzianov via lldb-commits

https://github.com/DmT021 updated 
https://github.com/llvm/llvm-project/pull/106030

>From a370fbb7b497eb12ca9faf9a760db3c023ee6052 Mon Sep 17 00:00:00 2001
From: Dmitrii Galimzianov 
Date: Tue, 27 Aug 2024 01:32:49 +0200
Subject: [PATCH] Add logs for SymbolFileDWARF::FindTypes

---
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  | 39 ---
 1 file changed, 33 insertions(+), 6 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 7e0cf36d0de1b8..d887d81912b27e 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -2737,10 +2737,19 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
   if (results.AlreadySearched(this))
 return;
 
+  auto type_basename = query.GetTypeBasename();
+
+  Log *log = GetLog(DWARFLog::Lookups);
+  if (log) {
+GetObjectFile()->GetModule()->LogMessage(
+log, "SymbolFileDWARF::FindTypes(type_basename=\"{0}\")",
+type_basename);
+  }
+
   std::lock_guard guard(GetModuleMutex());
 
   bool have_index_match = false;
-  m_index->GetTypes(query.GetTypeBasename(), [&](DWARFDIE die) {
+  m_index->GetTypes(type_basename, [&](DWARFDIE die) {
 // Check the language, but only if we have a language filter.
 if (query.HasLanguage()) {
   if (!query.LanguageMatches(GetLanguageFamily(*die.GetCU(
@@ -2779,8 +2788,14 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
 return !results.Done(query); // Keep iterating if we aren't done.
   });
 
-  if (results.Done(query))
+  if (results.Done(query)) {
+if (log) {
+  GetObjectFile()->GetModule()->LogMessage(
+  log, "SymbolFileDWARF::FindTypes(type_basename=\"{0}\") => {1}",
+  type_basename, results.GetTypeMap().GetSize());
+}
 return;
+  }
 
   // With -gsimple-template-names, a templated type's DW_AT_name will not
   // contain the template parameters. Try again stripping '<' and anything
@@ -2795,10 +2810,10 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
 // it trims any context items down by removing template parameter names.
 TypeQuery query_simple(query);
 if (UpdateCompilerContextForSimpleTemplateNames(query_simple)) {
-
+  auto type_basename_simple = query_simple.GetTypeBasename();
   // Copy our match's context and update the basename we are looking for
   // so we can use this only to compare the context correctly.
-  m_index->GetTypes(query_simple.GetTypeBasename(), [&](DWARFDIE die) {
+  m_index->GetTypes(type_basename_simple, [&](DWARFDIE die) {
 // Check the language, but only if we have a language filter.
 if (query.HasLanguage()) {
   if (!query.LanguageMatches(GetLanguageFamily(*die.GetCU(
@@ -2834,8 +2849,17 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
 }
 return !results.Done(query); // Keep iterating if we aren't done.
   });
-  if (results.Done(query))
+  if (results.Done(query)) {
+if (log) {
+  GetObjectFile()->GetModule()->LogMessage(
+  log,
+  "SymbolFileDWARF::FindTypes(type_basename=\"{0}\") => {1} "
+  "(simplified as \"{2}\")",
+  type_basename, results.GetTypeMap().GetSize(),
+  type_basename_simple);
+}
 return;
+  }
 }
   }
 
@@ -2847,8 +2871,11 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
   for (const auto &pair : m_external_type_modules) {
 if (ModuleSP external_module_sp = pair.second) {
   external_module_sp->FindTypes(query, results);
-  if (results.Done(query))
+  if (results.Done(query)) {
+// We don't log the results here as they are already logged in the
+// nested FindTypes call
 return;
+  }
 }
   }
 }

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


[Lldb-commits] [lldb] Add logs for SymbolFileDWARF::FindTypes (PR #106030)

2024-08-26 Thread Dmitrii Galimzianov via lldb-commits


@@ -2779,7 +2788,19 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
 return !results.Done(query); // Keep iterating if we aren't done.
   });
 
-  if (results.Done(query))
+  auto CheckIsDoneAndLog = [&results, &query, log, type_basename, this] {

DmT021 wrote:

Alright, I added "(simplified as )" to the end of the message, 
but if you prefer some other format let me know

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


[Lldb-commits] [lldb] [lldb] Turn lldb_private::Status into a value type. (PR #106163)

2024-08-26 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Adrian Prantl (adrian-prantl)


Changes

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the 
anti-pattern of keeping a long-lives Status object around and updating it while 
dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step (3) will 
dramatically clean up the error handling code in various places. In the end my 
goal is to convert all APIs that are of the form

`ResultTy DoFoo(Status& error)
`
to

`llvm::Expected DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other changes are 
mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git grep 
-l SetErrorString lldb/source)
`
plus the occasional manual cleanup.

---

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


260 Files Affected:

- (modified) lldb/bindings/python/python-wrapper.swig (+11-9) 
- (modified) lldb/include/lldb/Core/StructuredDataImpl.h (+9-19) 
- (modified) lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h 
(+1-1) 
- (modified) 
lldb/include/lldb/Interpreter/Interfaces/ScriptedPlatformInterface.h (+6-3) 
- (modified) 
lldb/include/lldb/Interpreter/Interfaces/ScriptedProcessInterface.h (+10-5) 
- (modified) lldb/include/lldb/Interpreter/OptionValue.h (+2-1) 
- (modified) lldb/include/lldb/Interpreter/ScriptInterpreter.h (+15-28) 
- (modified) lldb/include/lldb/Target/Process.h (+22-47) 
- (modified) lldb/include/lldb/Target/ProcessTrace.h (+1-3) 
- (modified) lldb/include/lldb/Utility/Status.h (+27-66) 
- (modified) lldb/source/API/SBBreakpoint.cpp (+9-8) 
- (modified) lldb/source/API/SBBreakpointLocation.cpp (+2-2) 
- (modified) lldb/source/API/SBBreakpointName.cpp (+1-1) 
- (modified) lldb/source/API/SBDebugger.cpp (+28-24) 
- (modified) lldb/source/API/SBError.cpp (+13-6) 
- (modified) lldb/source/API/SBFile.cpp (+3-3) 
- (modified) lldb/source/API/SBFrame.cpp (+5-5) 
- (modified) lldb/source/API/SBPlatform.cpp (+15-17) 
- (modified) lldb/source/API/SBProcess.cpp (+44-42) 
- (modified) lldb/source/API/SBStructuredData.cpp (+1-1) 
- (modified) lldb/source/API/SBTarget.cpp (+7-6) 
- (modified) lldb/source/API/SBThread.cpp (+36-34) 
- (modified) lldb/source/API/SBTrace.cpp (+16-14) 
- (modified) lldb/source/API/SBValue.cpp (+22-21) 
- (modified) lldb/source/Breakpoint/Breakpoint.cpp (+8-7) 
- (modified) lldb/source/Breakpoint/BreakpointID.cpp (+9-7) 
- (modified) lldb/source/Breakpoint/BreakpointLocation.cpp (+7-6) 
- (modified) lldb/source/Breakpoint/BreakpointOptions.cpp (+19-14) 
- (modified) lldb/source/Breakpoint/BreakpointPrecondition.cpp (+2-3) 
- (modified) lldb/source/Breakpoint/BreakpointResolver.cpp (+11-7) 
- (modified) lldb/source/Breakpoint/BreakpointResolverAddress.cpp (+4-2) 
- (modified) lldb/source/Breakpoint/BreakpointResolverFileLine.cpp (+10-5) 
- (modified) lldb/source/Breakpoint/BreakpointResolverFileRegex.cpp (+5-4) 
- (modified) lldb/source/Breakpoint/BreakpointResolverName.cpp (+13-10) 
- (modified) lldb/source/Breakpoint/BreakpointResolverScripted.cpp (+2-1) 
- (modified) lldb/source/Commands/CommandObjectBreakpointCommand.cpp (+2-3) 
- (modified) lldb/source/Commands/CommandObjectCommands.cpp (+111-73) 
- (modified) lldb/source/Commands/CommandObjectDisassemble.cpp (+6-5) 
- (modified) lldb/source/Commands/CommandObjectExpression.cpp (+13-13) 
- (modified) lldb/source/Commands/CommandObjectFrame.cpp (+7-7) 
- (modified) lldb/source/Commands/CommandObjectLog.cpp (+4-6) 
- (modified) lldb/source/Commands/CommandObjectMemory.cpp (+8-8) 
- (modified) lldb/source/Commands/CommandObjectPlatform.cpp (+22-22) 
- (modified) lldb/source/Commands/CommandObjectProcess.cpp (+3-3) 
- (modified) lldb/source/Commands/CommandObjectScripting.cpp (+3-3) 
- (modified) lldb/source/Commands/CommandObjectSource.cpp (+12-13) 
- (modified) lldb/source/Commands/CommandObjectTarget.cpp (+21-20) 
- (modified) lldb/source/Commands/CommandObjectThread.cpp (+25-21) 
- (modified) lldb/source/Commands/CommandObjectType.cpp (+30-28) 
- (modified) lldb/source/Commands/CommandObjectWatchpoint.cpp (+2-2) 
- (modified) lldb/source/Commands/CommandObjectWatchpointCommand.cpp (+2-3) 
- (modified) lldb/source/Commands/CommandOptionsProcessAttach.cpp (+2-2) 
- (modified) lldb/source/Commands/CommandOptionsProcessLaunch.cpp (+4-5) 
- (modified) lldb/source/Core/Communication.cpp (+3-3) 
- (modified) lldb/source/Core/Debugger.cpp (+13-11) 
- (modified) lldb/source/Core/FormatEntity.cpp (+21-16) 
- (modified) lldb/source/Core/Module.cpp (+9-8) 
- (modified) lldb/source/Core/ModuleList.cpp (+15-13) 

[Lldb-commits] [lldb] [lldb] Cleanup dyld_process_t after constructing SharedCacheInfo (PR #106157)

2024-08-26 Thread Jason Molenda via lldb-commits

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

Good catch, LGTM.

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


[Lldb-commits] [lldb] [lldb] Turn lldb_private::Status into a value type. (PR #106163)

2024-08-26 Thread Med Ismail Bennani via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Turn lldb_private::Status into a value type. (PR #106163)

2024-08-26 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben commented:

Cool stuff! I think this is fine except for the python files.

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


[Lldb-commits] [lldb] [lldb] Turn lldb_private::Status into a value type. (PR #106163)

2024-08-26 Thread Med Ismail Bennani via lldb-commits


@@ -15,7 +15,7 @@ def __init__(self, exe_ctx: lldb.SBExecutionContext, args: 
lldb.SBStructuredData
 def read_memory_at_address(
 self, addr: int, size: int, error: lldb.SBError
 ) -> lldb.SBData:
-error.SetErrorString("This is an invalid scripted process!")
+error = Status::FromErrorString("This is an invalid scripted process!")

medismailben wrote:

This is not valid python. The regex should only be applied to C++.

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


[Lldb-commits] [lldb] [lldb] Turn lldb_private::Status into a value type. (PR #106163)

2024-08-26 Thread Med Ismail Bennani via lldb-commits


@@ -56,19 +56,41 @@ class Status {
   ///
   /// \param[in] type
   /// The type for \a err.
-  explicit Status(ValueType err,
-  lldb::ErrorType type = lldb::eErrorTypeGeneric);
+  explicit Status(ValueType err, lldb::ErrorType type = 
lldb::eErrorTypeGeneric,
+  llvm::StringRef msg = {});
 
   Status(std::error_code EC);
 
-  explicit Status(const char *format, ...)
-  __attribute__((format(printf, 2, 3)));
+  /// Create a generic error with the message err_str.
+  explicit Status(std::string &&err_str);
+  /// Create a generic error with the message err_str.
+  explicit Status(llvm::StringRef err_str);
+
+  static Status FromErrorString(const char *format) {
+if (format)
+  return Status(std::string(format));
+return Status(std::string("null error"));

medismailben wrote:

```suggestion
return Status(llvm::StringRef("null error"));
```

This should be more efficient.

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


[Lldb-commits] [lldb] Disable ThreadPlanSingleThreadTimeout during step over breakpoint (PR #104532)

2024-08-26 Thread via lldb-commits

jimingham wrote:

This seems an okay solution for now.  We really don't want to miss breakpoint 
hits if we can at all avoid it.  

This isn't a regression, it's just one case where the proposed enhancement to 
stepping doesn't enhance stepping.

We haven't had many (any?) reports of single stepping over a breakpoint 
blocking because we're running only one thread.  Mostly that's because the 
actual instructions that might block are in system libraries that people tend 
to `next` over.  

Note, there's no inherent problem with the instruction we're stepping over not 
returning, it's only an issue if WE cause it to not return. By "block" we 
really mean "artificially block because the thread that should have caused the 
return was suspended by lldb".  So this would have to be something like a read 
that was expecting another thread in the program to be the writer, which also 
limits the scope of the problem.  

In any case, if we are going to implement true "non-stop" debugging we will 
need to avoid the "remove and replace instructions" dance and instead leave the 
traps always in place.  Since we are contractually obligated not to stop the 
other threads from the outside, that's the only way we can avoid missing 
breakpoint hits.  We'll have to come up with some scheme to execute the 
instruction that was under the breakpoint out of place, so that we never have 
to remove the traps.  At that point, ThreadPlanStepOverBreakpoint will be fine 
with running the other threads, and this problem will go away.

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


[Lldb-commits] [lldb] [lldb] Extend frame recognizers to hide frames from backtraces (PR #104523)

2024-08-26 Thread via lldb-commits

jimingham wrote:

> > When we were talking about this originally I thought that StackFrames would 
> > get an "ImplementationFrame" property, and we would use that to determine 
> > whether to hide the frame in bt (when not passing --unfiltered). Then the 
> > frame recognizers when they are run on the frame in the ordinary course of 
> > things (we do this to determine recognized args anyway) they would set the 
> > property on the StackFrame. Then StackFrameList could just check that 
> > property. RecognizeFrame might be expensive, and we don't currently have 
> > any machinery in place to make sure it caches the results per stop. Most of 
> > the RecognizeFrame's just do the work every time. I also think for 
> > structural reasons we shouldn't force FrameRecognizers to be the only 
> > entity that can mark frames as "should be hidden."
> 
> I understand that not recomputing them might be desirable, but this is not 
> how recognizers currently work. The only place frame recognizers currently 
> get called is by `Thread::GetStopDescription()` (for frame #0) and by 
> `Thread::GetCurrentException()` (also frame #0). So it's not true that we are 
> computing them anyway and thus have an opportunity to precompute the isHidden 
> attribute. I also think that from an architectural perspective it would be 
> wrong for a frame recognizer to be allowed to modify the state of a 
> StackFrame.

This is entirely tangential to this patch, which looks fine to me, but one of 
the jobs of a Frame recognizer is to add arguments to a StackFrame that doesn't 
have them.  That's way more intrusive than just setting a "ShouldHide" type 
flag...

> 
> When a frame recognizer is registered it takes a module regex a function 
> regex and a first_instruction flag. All three of these must match before the 
> recognizer is executed. That's num_recognizers*num_frames regexes. That's not 
> expensive in the grans scheme of things, but you're right that it's not 
> necessary.
> 
> I'll see if I can hide the recognizer invocation inside 
> StackFrame::shouldHide() and let StackFrame cache the result instead of 
> having the Recognizer modify the StackFrame. Maybe I can come up with some 
> cache invalidation strategy that makes sense.



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


[Lldb-commits] [lldb] [lldb][dap] always add column field in StackFrame body (PR #73393)

2024-08-26 Thread via lldb-commits

CheapMeow wrote:

It still has bug in VSCode: The editor could not be opened due to an unexpected 
error: Invalid arguments

My llvm version is

```
lldb version 18.1.8
clang version 18.1.8
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: E:\software\LLVM\bin
Found HIP installation: E:\software\AMD\ROCm\6.1\, version 6.1.40252
```

platform is

microsoft windows 11 professional

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


[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)

2024-08-26 Thread Greg Clayton via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb][dap] always add column field in StackFrame body (PR #73393)

2024-08-26 Thread Greg Clayton via lldb-commits

clayborg wrote:

I wonder if this needs to default to column 1? We might end up adding column 
zero. 
```
  /**
   * Start position of the range covered by the stack frame. It is measured in
   * UTF-16 code units and the client capability `columnsStartAt1` determines
   * whether it is 0- or 1-based. If attribute `source` is missing or doesn't
   * exist, `column` is 0 and should be ignored by the client.
   */
  column: number;
```
So if we return zero, it might cause a problem as the 
`InitializeRequestArguments` contains:
```
  /**
   * If true all column numbers are 1-based (default).
   */
  columnsStartAt1?: boolean;
```

1 is the default, and if we return zero, this could cause a problem?

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


[Lldb-commits] [lldb] [lldb] Turn lldb_private::Status into a value type. (PR #106163)

2024-08-26 Thread Greg Clayton via lldb-commits

https://github.com/clayborg commented:

I worry the assert will kill the LLDB library and cause issues. Can we add a 
temporary setting that can override this in case it does cause crashes? I 
really don't want LLDB crashing if we can help it. It will be hard to test all 
of the error code paths that can happen out in the wild

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


[Lldb-commits] [lldb] Add logs for SymbolFileDWARF::FindTypes (PR #106030)

2024-08-26 Thread Greg Clayton via lldb-commits

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


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