[Lldb-commits] [lldb] Initial step in targets DAP support (PR #86623)

[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 
93f9fb2c825dba48db64d5f726b54bcbd4766009...b2dfdb546808c495779e5781c6619fcadb752b00
 lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py 
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
``





View the diff from darker here.


``diff
--- packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 2024-03-26 
03:51:56.00 +
+++ packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 2024-03-26 
04:01:48.278326 +
@@ -813,13 +813,17 @@
 
 def request_stepInTargets(self, frameId):
 if self.exit_status is not None:
 raise ValueError("request_stepInTargets called after process 
exited")
 args_dict = {"frameId": frameId}
-command_dict = {"command": "stepInTargets", "type": "request", 
"arguments": args_dict}
-return self.send_recv(command_dict)
-
+command_dict = {
+"command": "stepInTargets",
+"type": "request",
+"arguments": args_dict,
+}
+return self.send_recv(command_dict)
+
 def request_stepIn(self, threadId, targetId):
 if self.exit_status is not None:
 raise ValueError("request_stepIn called after process exited")
 args_dict = {"threadId": threadId, "targetId": targetId}
 command_dict = {"command": "stepIn", "type": "request", "arguments": 
args_dict}

``




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

[Lldb-commits] [lldb] Initial step in targets DAP support (PR #86623)

[via lldb-commits]

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff 93f9fb2c825dba48db64d5f726b54bcbd4766009 
b2dfdb546808c495779e5781c6619fcadb752b00 -- 
lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp 
lldb/include/lldb/API/SBLineEntry.h lldb/include/lldb/API/SBSymbolContextList.h 
lldb/source/API/SBLineEntry.cpp lldb/tools/lldb-dap/DAP.h 
lldb/tools/lldb-dap/lldb-dap.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp 
b/lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp
index cd4419e8a4..d3c3dbcc13 100644
--- a/lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp
+++ b/lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp
@@ -1,17 +1,11 @@
 
-int foo(int val, int extra) {
-  return val + extra;
-}
+int foo(int val, int extra) { return val + extra; }
 
-int bar() {
-  return 22;
-}
+int bar() { return 22; }
 
-int bar2() {
-  return 54;
-}
+int bar2() { return 54; }
 
-int main(int argc, char const *argv[]) { 
+int main(int argc, char const *argv[]) {
   foo(bar(), bar2()); // set breakpoint here
   return 0;
 }
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index e27c078d14..30cba6d23f 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -3186,7 +3186,7 @@ void request_stepIn(const llvm::json::Object ) {
   auto it = g_dap.step_in_targets.find(target_id);
   if (it != g_dap.step_in_targets.end())
 step_in_target = it->second;
-  
+
   const bool single_thread = GetBoolean(arguments, "singleThread", false);
   lldb::RunMode run_mode =
   single_thread ? lldb::eOnlyThisThread : lldb::eOnlyDuringStepping;

``




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

[Lldb-commits] [lldb] Initial step in targets DAP support (PR #86623)

[via lldb-commits]

https://github.com/jeffreytan81 created 
https://github.com/llvm/llvm-project/pull/86623

None

>From 6cccde22723157260e7c0b19bf8372aae8d1afaa Mon Sep 17 00:00:00 2001
From: jeffreytan81 
Date: Wed, 6 Mar 2024 12:07:03 -0800
Subject: [PATCH 1/3] Fix strcmp build error on buildbot

---
 lldb/test/API/functionalities/fork/concurrent_vfork/main.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lldb/test/API/functionalities/fork/concurrent_vfork/main.cpp 
b/lldb/test/API/functionalities/fork/concurrent_vfork/main.cpp
index b0a4446ba01581..40cb63755ee8a5 100644
--- a/lldb/test/API/functionalities/fork/concurrent_vfork/main.cpp
+++ b/lldb/test/API/functionalities/fork/concurrent_vfork/main.cpp
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

>From 06ec5e2a045e6ab4d97029fa0de5cc52dc4f0769 Mon Sep 17 00:00:00 2001
From: jeffreytan81 
Date: Mon, 25 Mar 2024 20:51:56 -0700
Subject: [PATCH 2/3] Initial support for stepInTargets feature

---
 lldb/include/lldb/API/SBCompileUnit.h |   5 +
 lldb/include/lldb/API/SBLineEntry.h   |   3 +
 lldb/include/lldb/API/SBSymbolContextList.h   |   1 +
 .../test/tools/lldb-dap/dap_server.py |  17 +-
 .../test/tools/lldb-dap/lldbdap_testcase.py   |   4 +-
 lldb/source/API/SBCompileUnit.cpp |  17 ++
 lldb/source/API/SBLineEntry.cpp   |  15 ++
 .../API/tools/lldb-dap/stepInTargets/Makefile |   6 +
 .../stepInTargets/TestDAP_stepInTargets.py|  66 
 .../API/tools/lldb-dap/stepInTargets/main.cpp |  17 ++
 lldb/tools/lldb-dap/DAP.h |   2 +
 lldb/tools/lldb-dap/lldb-dap.cpp  | 149 +-
 12 files changed, 293 insertions(+), 9 deletions(-)
 create mode 100644 lldb/test/API/tools/lldb-dap/stepInTargets/Makefile
 create mode 100644 
lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
 create mode 100644 lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp

diff --git a/lldb/include/lldb/API/SBCompileUnit.h 
b/lldb/include/lldb/API/SBCompileUnit.h
index 36492d9398ce9e..4fc9ad43386f45 100644
--- a/lldb/include/lldb/API/SBCompileUnit.h
+++ b/lldb/include/lldb/API/SBCompileUnit.h
@@ -11,6 +11,7 @@
 
 #include "lldb/API/SBDefines.h"
 #include "lldb/API/SBFileSpec.h"
+#include 
 
 namespace lldb {
 
@@ -30,6 +31,10 @@ class LLDB_API SBCompileUnit {
 
   lldb::SBFileSpec GetFileSpec() const;
 
+  lldb::SBSymbolContextList
+  ResolveSymbolContext(const char *file, uint32_t line,
+   std::optional column = std::nullopt) const;
+
   uint32_t GetNumLineEntries() const;
 
   lldb::SBLineEntry GetLineEntryAtIndex(uint32_t idx) const;
diff --git a/lldb/include/lldb/API/SBLineEntry.h 
b/lldb/include/lldb/API/SBLineEntry.h
index 7c2431ba3c8a51..d70c4fac6ec717 100644
--- a/lldb/include/lldb/API/SBLineEntry.h
+++ b/lldb/include/lldb/API/SBLineEntry.h
@@ -29,6 +29,9 @@ class LLDB_API SBLineEntry {
 
   lldb::SBAddress GetEndAddress() const;
 
+  lldb::SBAddress
+  GetSameLineContiguousAddressRangeEnd(bool include_inlined_functions) const;
+
   explicit operator bool() const;
 
   bool IsValid() const;
diff --git a/lldb/include/lldb/API/SBSymbolContextList.h 
b/lldb/include/lldb/API/SBSymbolContextList.h
index 4026afc213571c..95100d219df20f 100644
--- a/lldb/include/lldb/API/SBSymbolContextList.h
+++ b/lldb/include/lldb/API/SBSymbolContextList.h
@@ -44,6 +44,7 @@ class LLDB_API SBSymbolContextList {
 protected:
   friend class SBModule;
   friend class SBTarget;
+  friend class SBCompileUnit;
 
   lldb_private::SymbolContextList *operator->() const;
 
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 27a76a652f4063..f2ee6bd8212415 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
@@ -811,23 +811,30 @@ def request_next(self, threadId):
 command_dict = {"command": "next", "type": "request", "arguments": 
args_dict}
 return self.send_recv(command_dict)
 
-def request_stepIn(self, threadId):
+def request_stepInTargets(self, frameId):
 if self.exit_status is not None:
-raise ValueError("request_continue called after process exited")
-args_dict = {"threadId": threadId}
+raise ValueError("request_stepInTargets called after process 
exited")
+args_dict = {"frameId": frameId}
+command_dict = {"command": "stepInTargets", "type": "request", 
"arguments": args_dict}
+return self.send_recv(command_dict)
+
+def request_stepIn(self, threadId, targetId):
+if self.exit_status is not None:
+raise ValueError("request_stepIn called after process exited")
+args_dict = {"threadId": threadId, "targetId": targetId}
 command_dict = {"command": "stepIn", "type": "request", "arguments": 
args_dict}
 return 

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Chris B via lldb-commits]

llvm-beanz wrote:

> I'm a bit confused. Are you saying that as I've expressed it, `autocrlf=true` 
> won't work correctly? I _think_ you're saying you're in favour of this patch 
> _in principal_, but I need to fix the mixed line endings case?

Sorry for being unclear. I meant to express that I'm so strongly in favor of 
what you're accomplishing here that I don't want any of my feedback to stand in 
the way.

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

[Lldb-commits] [lldb] [lldb] [ObjC runtime] Don't cast to signed when left shifting (PR #86605)

[Jason Molenda via lldb-commits]

jasonmolenda wrote:

I've seen this ubsan error every time I run the testsuite for years, i just 
finally sat down and figured out what was going on.

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

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Chris B via lldb-commits]

llvm-beanz wrote:

> This ^ seems a bit problematic to me, though (where the contents of the repo 
> isn't representative of the bits we want - but perhaps it's schrodinger's 
> line endings & it doesn't matter if it's always checked out as crlf - though 
> if we one day converted to another source control system, would that be a 
> problem? are there some things that examine the underlying/"real" repo 
> contents?) - what would be the cost to using `eol=input` as you've done for 
> the mixed line ending case? below \=

The argument I would have in favor of an explicit value rather than `eol=input` 
is that it at least gives us a source of truth in the `.gitattributes` as to 
what type of line ending the file is supposed to have.

I don't have a strong feeling one way or another. I just want `autocrlf=true` 
to work reliably on all platforms.


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

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Chris B via lldb-commits]

llvm-beanz wrote:

> I am not saying this isn't a problem at all, but how often has anyone done a 
> one line change and caused a 50k diff, and submitted it without noticing?

Way more often than you would hope. I don't have numbers but if you search 
through the git history for `crlf` or `dos2unix` those phrases hit on a lot of 
commits (more than just my abolishcrlf.org email address).


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

[Lldb-commits] [lldb] b6dfaf4 - Make the correct (5 argument) form of the command definition be the primary one suggested in the docs (#86593)

[via lldb-commits]

Author: jimingham
Date: 2024-03-25T16:06:51-07:00
New Revision: b6dfaf4c291ee186481f6c1dcab03874d931c307

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

LOG: Make the correct (5 argument) form of the command definition be the 
primary one suggested in the docs (#86593)

This has been available for years now, so it should be safe to always
use it.

Added: 


Modified: 
lldb/docs/use/python-reference.rst

Removed: 




diff  --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index e5195a2471d9af..795e38fab3794b 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -491,14 +491,17 @@ which will work like all the natively defined lldb 
commands. This provides a
 very flexible and easy way to extend LLDB to meet your debugging requirements.
 
 To write a python function that implements a new LLDB command define the
-function to take four arguments as follows:
+function to take five arguments as follows:
 
 ::
 
-  def command_function(debugger, command, result, internal_dict):
+  def command_function(debugger, command, exe_ctx, result, internal_dict):
   # Your code goes here
 
-Optionally, you can also provide a Python docstring, and LLDB will use it when 
providing help for your command, as in:
+The meaning of the arguments is given in the table below.
+
+If you provide a Python docstring in your command function LLDB will use it
+when providing "long help" for your command, as in:
 
 ::
 
@@ -506,19 +509,24 @@ Optionally, you can also provide a Python docstring, and 
LLDB will use it when p
   """This command takes a lot of options and does many fancy things"""
   # Your code goes here
 
-Since lldb 3.5.2, LLDB Python commands can also take an SBExecutionContext as 
an
-argument. This is useful in cases where the command's notion of where to act is
-independent of the currently-selected entities in the debugger.
+though providing help can also be done programmatically (see below).
 
-This feature is enabled if the command-implementing function can be recognized
-as taking 5 arguments, or a variable number of arguments, and it alters the
-signature as such:
+Prior to lldb 3.5.2 (April 2015), LLDB Python command definitions didn't take 
the SBExecutionContext
+argument. So you may still see commands where the command definition is:
 
 ::
 
-  def command_function(debugger, command, exe_ctx, result, internal_dict):
+  def command_function(debugger, command, result, internal_dict):
   # Your code goes here
 
+Using this form is strongly discouraged because it can only operate on the 
"currently selected"
+target, process, thread, frame.  The command will behave as expected when run
+directly on the command line.  But if the command is used in a stop-hook, 
breakpoint
+callback, etc. where the response to the callback determines whether we will 
select
+this or that particular process/frame/thread, the global "currently selected"
+entity is not necessarily the one the callback is meant to handle.  In that 
case, this
+command definition form can't do the right thing.
+
 
+---++--+
 | Argument  | Type   | Description 

 |
 
+---++--+



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

[Lldb-commits] [lldb] Make the correct (5 argument) form of the command definition be the primary one suggested in the docs (PR #86593)

[via lldb-commits]

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

[Lldb-commits] [lldb] Make the correct (5 argument) form of the command definition be the primary one suggested in the docs (PR #86593)

[via lldb-commits]

https://github.com/jimingham updated 
https://github.com/llvm/llvm-project/pull/86593

>From 1886d705aee10cf608b4c452bea6ea3e47c4b25d Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Mon, 25 Mar 2024 15:31:50 -0700
Subject: [PATCH 1/2] Make the correct (5 argument) form of the command
 definition be the primary one suggested in the docs.  This has been available
 for years now, so it should be safe to always use it.

---
 lldb/docs/use/python-reference.rst | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index e5195a2471d9af..bafbe812383d69 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -491,14 +491,17 @@ which will work like all the natively defined lldb 
commands. This provides a
 very flexible and easy way to extend LLDB to meet your debugging requirements.
 
 To write a python function that implements a new LLDB command define the
-function to take four arguments as follows:
+function to take five arguments as follows:
 
 ::
 
-  def command_function(debugger, command, result, internal_dict):
+  def command_function(debugger, command, exe_ctx, result, internal_dict):
   # Your code goes here
 
-Optionally, you can also provide a Python docstring, and LLDB will use it when 
providing help for your command, as in:
+The meaning of the arguments is given in the table below.
+
+If you provide a Python docstring in your command function LLDB will use it
+when providing "long help" for your command, as in:
 
 ::
 
@@ -506,19 +509,24 @@ Optionally, you can also provide a Python docstring, and 
LLDB will use it when p
   """This command takes a lot of options and does many fancy things"""
   # Your code goes here
 
-Since lldb 3.5.2, LLDB Python commands can also take an SBExecutionContext as 
an
-argument. This is useful in cases where the command's notion of where to act is
-independent of the currently-selected entities in the debugger.
+though providing help can also be done programmatically (see below).
 
-This feature is enabled if the command-implementing function can be recognized
-as taking 5 arguments, or a variable number of arguments, and it alters the
-signature as such:
+Prior to lldb 3.5.2, LLDB Python command definitions didn't take the 
SBExecutionContext
+argument. So you may still see commands where the command definition is:
 
 ::
-
-  def command_function(debugger, command, exe_ctx, result, internal_dict):
+   
+  def command_function(debugger, command, result, internal_dict):
   # Your code goes here
 
+This form is deprecated because it can only operate on the "currently selected"
+target, process, thread, frame.  The command will behave as expected when run
+directly on the command line.  But if the command is used in a stop-hook, 
breakpoint
+callback, etc. where the response to the callback determines whether we will 
select
+this or that particular process/frame/thread, the global "currently selected"
+entity is not necessarily the one the callback is meant to handle.  In that 
case, this
+command definition form can't do the right thing.
+
 
+---++--+
 | Argument  | Type   | Description 

 |
 
+---++--+

>From 0a246c1ec13986d5fb819258b2c2ae2b93ea8508 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Mon, 25 Mar 2024 16:06:00 -0700
Subject: [PATCH 2/2] Address review comments; give a date for 3.5.2 not just a
 version.

---
 lldb/docs/use/python-reference.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index bafbe812383d69..795e38fab3794b 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -511,15 +511,15 @@ when providing "long help" for your command, as in:
 
 though providing help can also be done programmatically (see below).
 
-Prior to lldb 3.5.2, LLDB Python command definitions didn't take the 
SBExecutionContext
+Prior to lldb 3.5.2 (April 2015), LLDB Python command definitions didn't take 
the SBExecutionContext
 argument. So you may still see commands where the command definition is:
 
 ::
-   
+
   def command_function(debugger, command, result, internal_dict):
   # Your code goes here
 
-This form is deprecated because it can only operate on the "currently selected"
+Using this form is strongly discouraged because it can only operate on the 
"currently 

[Lldb-commits] [lldb] Make the correct (5 argument) form of the command definition be the primary one suggested in the docs (PR #86593)

[Alex Langford via lldb-commits]

@@ -491,34 +491,42 @@ which will work like all the natively defined lldb 
commands. This provides a
 very flexible and easy way to extend LLDB to meet your debugging requirements.
 
 To write a python function that implements a new LLDB command define the
-function to take four arguments as follows:
+function to take five arguments as follows:
 
 ::
 
-  def command_function(debugger, command, result, internal_dict):
+  def command_function(debugger, command, exe_ctx, result, internal_dict):
   # Your code goes here
 
-Optionally, you can also provide a Python docstring, and LLDB will use it when 
providing help for your command, as in:
+The meaning of the arguments is given in the table below.
+
+If you provide a Python docstring in your command function LLDB will use it
+when providing "long help" for your command, as in:
 
 ::
 
   def command_function(debugger, command, result, internal_dict):
   """This command takes a lot of options and does many fancy things"""
   # Your code goes here
 
-Since lldb 3.5.2, LLDB Python commands can also take an SBExecutionContext as 
an
-argument. This is useful in cases where the command's notion of where to act is
-independent of the currently-selected entities in the debugger.
+though providing help can also be done programmatically (see below).
 
-This feature is enabled if the command-implementing function can be recognized
-as taking 5 arguments, or a variable number of arguments, and it alters the
-signature as such:
+Prior to lldb 3.5.2, LLDB Python command definitions didn't take the 
SBExecutionContext
+argument. So you may still see commands where the command definition is:
 
 ::
-
-  def command_function(debugger, command, exe_ctx, result, internal_dict):
+   
+  def command_function(debugger, command, result, internal_dict):
   # Your code goes here
 
+This form is deprecated because it can only operate on the "currently selected"
+target, process, thread, frame.  The command will behave as expected when run
+directly on the command line.  But if the command is used in a stop-hook, 
breakpoint
+callback, etc. where the response to the callback determines whether we will 
select
+this or that particular process/frame/thread, the global "currently selected"
+entity is not necessarily the one the callback is meant to handle.  In that 
case, this
+command definition form can't do the right thing.

bulbazord wrote:

You wrote that it's deprecated at the beginning of the paragraph, but LLDB 
never removes functions nor removes working implementations of deprecated 
functions. I would recommend wording the conclusion more strongly, e.g.
`In that case, this command definition form can't do the right thing and is 
therefore highly discouraged from use.`

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

[Lldb-commits] [lldb] Make the correct (5 argument) form of the command definition be the primary one suggested in the docs (PR #86593)

[Alex Langford via lldb-commits]

@@ -491,34 +491,42 @@ which will work like all the natively defined lldb 
commands. This provides a
 very flexible and easy way to extend LLDB to meet your debugging requirements.
 
 To write a python function that implements a new LLDB command define the
-function to take four arguments as follows:
+function to take five arguments as follows:
 
 ::
 
-  def command_function(debugger, command, result, internal_dict):
+  def command_function(debugger, command, exe_ctx, result, internal_dict):
   # Your code goes here
 
-Optionally, you can also provide a Python docstring, and LLDB will use it when 
providing help for your command, as in:
+The meaning of the arguments is given in the table below.
+
+If you provide a Python docstring in your command function LLDB will use it
+when providing "long help" for your command, as in:
 
 ::
 
   def command_function(debugger, command, result, internal_dict):
   """This command takes a lot of options and does many fancy things"""
   # Your code goes here
 
-Since lldb 3.5.2, LLDB Python commands can also take an SBExecutionContext as 
an
-argument. This is useful in cases where the command's notion of where to act is
-independent of the currently-selected entities in the debugger.
+though providing help can also be done programmatically (see below).
 
-This feature is enabled if the command-implementing function can be recognized
-as taking 5 arguments, or a variable number of arguments, and it alters the
-signature as such:
+Prior to lldb 3.5.2, LLDB Python command definitions didn't take the 
SBExecutionContext
+argument. So you may still see commands where the command definition is:
 
 ::
-
-  def command_function(debugger, command, exe_ctx, result, internal_dict):
+   

bulbazord wrote:

nit: Spurious whitespace

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

[Lldb-commits] [lldb] Make the correct (5 argument) form of the command definition be the primary one suggested in the docs (PR #86593)

[Alex Langford via lldb-commits]

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

LGTM

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

[Lldb-commits] [lldb] Make the correct (5 argument) form of the command definition be the primary one suggested in the docs (PR #86593)

[Alex Langford via lldb-commits]

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

[Lldb-commits] [lldb] Make the correct (5 argument) form of the command definition be the primary one suggested in the docs (PR #86593)

[Chelsea Cassanova via lldb-commits]

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


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

[Lldb-commits] [lldb] Make the correct (5 argument) form of the command definition be the primary one suggested in the docs (PR #86593)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (jimingham)


Changes

This has been available for years now, so it should be safe to always use it.

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


1 Files Affected:

- (modified) lldb/docs/use/python-reference.rst (+19-11) 


``diff
diff --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index e5195a2471d9af..bafbe812383d69 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -491,14 +491,17 @@ which will work like all the natively defined lldb 
commands. This provides a
 very flexible and easy way to extend LLDB to meet your debugging requirements.
 
 To write a python function that implements a new LLDB command define the
-function to take four arguments as follows:
+function to take five arguments as follows:
 
 ::
 
-  def command_function(debugger, command, result, internal_dict):
+  def command_function(debugger, command, exe_ctx, result, internal_dict):
   # Your code goes here
 
-Optionally, you can also provide a Python docstring, and LLDB will use it when 
providing help for your command, as in:
+The meaning of the arguments is given in the table below.
+
+If you provide a Python docstring in your command function LLDB will use it
+when providing "long help" for your command, as in:
 
 ::
 
@@ -506,19 +509,24 @@ Optionally, you can also provide a Python docstring, and 
LLDB will use it when p
   """This command takes a lot of options and does many fancy things"""
   # Your code goes here
 
-Since lldb 3.5.2, LLDB Python commands can also take an SBExecutionContext as 
an
-argument. This is useful in cases where the command's notion of where to act is
-independent of the currently-selected entities in the debugger.
+though providing help can also be done programmatically (see below).
 
-This feature is enabled if the command-implementing function can be recognized
-as taking 5 arguments, or a variable number of arguments, and it alters the
-signature as such:
+Prior to lldb 3.5.2, LLDB Python command definitions didn't take the 
SBExecutionContext
+argument. So you may still see commands where the command definition is:
 
 ::
-
-  def command_function(debugger, command, exe_ctx, result, internal_dict):
+   
+  def command_function(debugger, command, result, internal_dict):
   # Your code goes here
 
+This form is deprecated because it can only operate on the "currently selected"
+target, process, thread, frame.  The command will behave as expected when run
+directly on the command line.  But if the command is used in a stop-hook, 
breakpoint
+callback, etc. where the response to the callback determines whether we will 
select
+this or that particular process/frame/thread, the global "currently selected"
+entity is not necessarily the one the callback is meant to handle.  In that 
case, this
+command definition form can't do the right thing.
+
 
+---++--+
 | Argument  | Type   | Description 

 |
 
+---++--+

``




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

[Lldb-commits] [lldb] Make the correct (5 argument) form of the command definition be the primary one suggested in the docs (PR #86593)

[via lldb-commits]

https://github.com/jimingham created 
https://github.com/llvm/llvm-project/pull/86593

This has been available for years now, so it should be safe to always use it.

>From 1886d705aee10cf608b4c452bea6ea3e47c4b25d Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Mon, 25 Mar 2024 15:31:50 -0700
Subject: [PATCH] Make the correct (5 argument) form of the command definition
 be the primary one suggested in the docs.  This has been available for years
 now, so it should be safe to always use it.

---
 lldb/docs/use/python-reference.rst | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index e5195a2471d9af..bafbe812383d69 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -491,14 +491,17 @@ which will work like all the natively defined lldb 
commands. This provides a
 very flexible and easy way to extend LLDB to meet your debugging requirements.
 
 To write a python function that implements a new LLDB command define the
-function to take four arguments as follows:
+function to take five arguments as follows:
 
 ::
 
-  def command_function(debugger, command, result, internal_dict):
+  def command_function(debugger, command, exe_ctx, result, internal_dict):
   # Your code goes here
 
-Optionally, you can also provide a Python docstring, and LLDB will use it when 
providing help for your command, as in:
+The meaning of the arguments is given in the table below.
+
+If you provide a Python docstring in your command function LLDB will use it
+when providing "long help" for your command, as in:
 
 ::
 
@@ -506,19 +509,24 @@ Optionally, you can also provide a Python docstring, and 
LLDB will use it when p
   """This command takes a lot of options and does many fancy things"""
   # Your code goes here
 
-Since lldb 3.5.2, LLDB Python commands can also take an SBExecutionContext as 
an
-argument. This is useful in cases where the command's notion of where to act is
-independent of the currently-selected entities in the debugger.
+though providing help can also be done programmatically (see below).
 
-This feature is enabled if the command-implementing function can be recognized
-as taking 5 arguments, or a variable number of arguments, and it alters the
-signature as such:
+Prior to lldb 3.5.2, LLDB Python command definitions didn't take the 
SBExecutionContext
+argument. So you may still see commands where the command definition is:
 
 ::
-
-  def command_function(debugger, command, exe_ctx, result, internal_dict):
+   
+  def command_function(debugger, command, result, internal_dict):
   # Your code goes here
 
+This form is deprecated because it can only operate on the "currently selected"
+target, process, thread, frame.  The command will behave as expected when run
+directly on the command line.  But if the command is used in a stop-hook, 
breakpoint
+callback, etc. where the response to the callback determines whether we will 
select
+this or that particular process/frame/thread, the global "currently selected"
+entity is not necessarily the one the callback is meant to handle.  In that 
case, this
+command definition form can't do the right thing.
+
 
+---++--+
 | Argument  | Type   | Description 

 |
 
+---++--+

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

[Lldb-commits] [lldb] 4dcb1db - Revert "[lldb] Implement coalescing of disjoint progress events (#84854)"

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2024-03-25T15:25:58-07:00
New Revision: 4dcb1db44f9dbfa09c220703a1b097f51d20a2a5

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

LOG: Revert "[lldb] Implement coalescing of disjoint progress events (#84854)"

This reverts commit 930f64689c1fb487714c3836ffa43e49e46aa488 as it's
failing on the Linux bots.

Added: 


Modified: 
lldb/include/lldb/Core/Progress.h
lldb/source/Core/Progress.cpp
lldb/source/Initialization/SystemInitializerCommon.cpp
lldb/unittests/Core/ProgressReportTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/Progress.h 
b/lldb/include/lldb/Core/Progress.h
index cd87be79c4f0e3..eb3af9816dc6ca 100644
--- a/lldb/include/lldb/Core/Progress.h
+++ b/lldb/include/lldb/Core/Progress.h
@@ -9,7 +9,6 @@
 #ifndef LLDB_CORE_PROGRESS_H
 #define LLDB_CORE_PROGRESS_H
 
-#include "lldb/Host/Alarm.h"
 #include "lldb/lldb-forward.h"
 #include "lldb/lldb-types.h"
 #include "llvm/ADT/StringMap.h"
@@ -151,12 +150,9 @@ class ProgressManager {
   void Increment(const Progress::ProgressData &);
   void Decrement(const Progress::ProgressData &);
 
-  static void Initialize();
-  static void Terminate();
-  static bool Enabled();
   static ProgressManager ();
 
-protected:
+private:
   enum class EventType {
 Begin,
 End,
@@ -164,32 +160,9 @@ class ProgressManager {
   static void ReportProgress(const Progress::ProgressData _data,
  EventType type);
 
-  static std::optional ();
-
-  /// Helper function for reporting progress when the alarm in the 
corresponding
-  /// entry in the map expires.
-  void Expire(llvm::StringRef key);
-
-  /// Entry used for bookkeeping.
-  struct Entry {
-/// Reference count used for overlapping events.
-uint64_t refcount = 0;
-
-/// Data used to emit progress events.
-Progress::ProgressData data;
-
-/// Alarm handle used when the refcount reaches zero.
-Alarm::Handle handle = Alarm::INVALID_HANDLE;
-  };
-
-  /// Map used for bookkeeping.
-  llvm::StringMap m_entries;
-
-  /// Mutex to provide the map.
-  std::mutex m_entries_mutex;
-
-  /// Alarm instance to coalesce progress events.
-  Alarm m_alarm;
+  llvm::StringMap>
+  m_progress_category_map;
+  std::mutex m_progress_map_mutex;
 };
 
 } // namespace lldb_private

diff  --git a/lldb/source/Core/Progress.cpp b/lldb/source/Core/Progress.cpp
index 161038284e215a..b4b5e98b7ba493 100644
--- a/lldb/source/Core/Progress.cpp
+++ b/lldb/source/Core/Progress.cpp
@@ -35,10 +35,7 @@ Progress::Progress(std::string title, std::string details,
 
   std::lock_guard guard(m_mutex);
   ReportProgress();
-
-  // Report to the ProgressManager if that subsystem is enabled.
-  if (ProgressManager::Enabled())
-ProgressManager::Instance().Increment(m_progress_data);
+  ProgressManager::Instance().Increment(m_progress_data);
 }
 
 Progress::~Progress() {
@@ -48,10 +45,7 @@ Progress::~Progress() {
   if (!m_completed)
 m_completed = m_total;
   ReportProgress();
-
-  // Report to the ProgressManager if that subsystem is enabled.
-  if (ProgressManager::Enabled())
-ProgressManager::Instance().Decrement(m_progress_data);
+  ProgressManager::Instance().Decrement(m_progress_data);
 }
 
 void Progress::Increment(uint64_t amount,
@@ -81,84 +75,45 @@ void Progress::ReportProgress() {
   }
 }
 
-ProgressManager::ProgressManager()
-: m_entries(), m_alarm(std::chrono::milliseconds(100)) {}
+ProgressManager::ProgressManager() : m_progress_category_map() {}
 
 ProgressManager::~ProgressManager() {}
 
-void ProgressManager::Initialize() {
-  assert(!InstanceImpl() && "Already initialized.");
-  InstanceImpl().emplace();
-}
-
-void ProgressManager::Terminate() {
-  assert(InstanceImpl() && "Already terminated.");
-  InstanceImpl().reset();
-}
-
-bool ProgressManager::Enabled() { return InstanceImpl().operator bool(); }
-
 ProgressManager ::Instance() {
-  assert(InstanceImpl() && "ProgressManager must be initialized");
-  return *InstanceImpl();
-}
-
-std::optional ::InstanceImpl() {
-  static std::optional g_progress_manager;
-  return g_progress_manager;
+  static std::once_flag g_once_flag;
+  static ProgressManager *g_progress_manager = nullptr;
+  std::call_once(g_once_flag, []() {
+// NOTE: known leak to avoid global destructor chain issues.
+g_progress_manager = new ProgressManager();
+  });
+  return *g_progress_manager;
 }
 
 void ProgressManager::Increment(const Progress::ProgressData _data) {
-  std::lock_guard lock(m_entries_mutex);
-
-  llvm::StringRef key = progress_data.title;
-  bool new_entry = !m_entries.contains(key);
-  Entry  = m_entries[progress_data.title];
-
-  if (new_entry) {
-// This is a new progress event. Report progress and store the progress
-// data.
+  

[Lldb-commits] [lldb] Add register lookup as another fallback computation for address-expressions (PR #85492)

[via lldb-commits]

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

[Lldb-commits] [lldb] 2c76e88 - Add register lookup as another fallback computation for address-expressions (#85492)

[via lldb-commits]

Author: jimingham
Date: 2024-03-25T15:17:23-07:00
New Revision: 2c76e88e9eb284d17cf409851fb01f1d583bb22a

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

LOG: Add register lookup as another fallback computation for 
address-expressions (#85492)

The idea behind the address-expression is that it handles all the common
expressions that produce addresses. It handles actual valid expressions
that return a scalar, and it handles useful cases that the various
source languages don't support. At present, the fallback handles:

{+-}

which isn't valid C but is very handy.

This patch adds handling of:

$

and

${+-}

That's kind of pointless in C because the C expression parser handles
that expression already. But some languages don't have a straightforward
way to represent register values like this (swift) so having this
fallback is quite a quality of life improvement.

I added a test which tests that I didn't mess up either of these
fallbacks, though it doesn't test the actually handling of registers
that I added, since the expression parser for C succeeds in that case
and returns before this code gets run.

I will add a test on the swift fork for that checks that this works the
same way for a swift frame after this check.

Added: 
lldb/test/API/commands/target/modules/lookup/Makefile
lldb/test/API/commands/target/modules/lookup/TestImageLookupPCExpression.py
lldb/test/API/commands/target/modules/lookup/main.c

Modified: 
lldb/source/Interpreter/OptionArgParser.cpp

Removed: 




diff  --git a/lldb/source/Interpreter/OptionArgParser.cpp 
b/lldb/source/Interpreter/OptionArgParser.cpp
index 75ccad87467e95..9a8275128ede90 100644
--- a/lldb/source/Interpreter/OptionArgParser.cpp
+++ b/lldb/source/Interpreter/OptionArgParser.cpp
@@ -9,7 +9,9 @@
 #include "lldb/Interpreter/OptionArgParser.h"
 #include "lldb/DataFormatters/FormatManager.h"
 #include "lldb/Target/ABI.h"
+#include "lldb/Target/RegisterContext.h"
 #include "lldb/Target/Target.h"
+#include "lldb/Utility/RegisterValue.h"
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/StreamString.h"
 
@@ -233,24 +235,68 @@ OptionArgParser::DoToAddress(const ExecutionContext 
*exe_ctx, llvm::StringRef s,
   // Since the compiler can't handle things like "main + 12" we should try to
   // do this for now. The compiler doesn't like adding offsets to function
   // pointer types.
+  // Some languages also don't have a natural representation for register
+  // values (e.g. swift) so handle simple uses of them here as well.
+  // We use a regex to parse these forms, the regex handles:
+  // $reg_name
+  // $reg_name+offset
+  // symbol_name+offset
+  //
+  // The important matching elements in the regex below are:
+  // 1: The reg name if there's no +offset
+  // 3: The symbol/reg name if there is an offset
+  // 4: +/-
+  // 5: The offset value.
   static RegularExpression g_symbol_plus_offset_regex(
-  "^(.*)([-\\+])[[:space:]]*(0x[0-9A-Fa-f]+|[0-9]+)[[:space:]]*$");
+  "^(\\$[^ +-]+)|(([^ 
+-]+)([-\\+])[[:space:]]*(0x[0-9A-Fa-f]+|[0-9]+)[[:space:]]*)$");
 
   llvm::SmallVector matches;
   if (g_symbol_plus_offset_regex.Execute(sref, )) {
 uint64_t offset = 0;
-llvm::StringRef name = matches[1];
-llvm::StringRef sign = matches[2];
-llvm::StringRef str_offset = matches[3];
-if (!str_offset.getAsInteger(0, offset)) {
+llvm::StringRef name;
+if (!matches[1].empty())
+  name = matches[1];
+else
+  name = matches[3];
+
+llvm::StringRef sign = matches[4];
+llvm::StringRef str_offset = matches[5];
+
+// Some languages don't have a natural type for register values, but it
+// is still useful to look them up here:
+std::optional register_value;
+StackFrame *frame = exe_ctx->GetFramePtr();
+llvm::StringRef reg_name = name;
+if (frame && reg_name.consume_front("$")) {
+  RegisterContextSP reg_ctx_sp = frame->GetRegisterContext();
+  if (reg_ctx_sp) {
+const RegisterInfo *reg_info = 
reg_ctx_sp->GetRegisterInfoByName(reg_name);
+if (reg_info) {
+  RegisterValue reg_val;
+  bool success = reg_ctx_sp->ReadRegister(reg_info, reg_val);
+  if (success && reg_val.GetType() != RegisterValue::eTypeInvalid) {
+register_value = reg_val.GetAsUInt64(0, );
+if (!success)
+  register_value.reset();
+  }
+}
+  } 
+}
+if (!str_offset.empty() && !str_offset.getAsInteger(0, offset)) {
   Status error;
-  addr = ToAddress(exe_ctx, name, LLDB_INVALID_ADDRESS, );
+  if (register_value)
+addr = register_value.value();
+  else
+addr = ToAddress(exe_ctx, name, LLDB_INVALID_ADDRESS, );
   if (addr != LLDB_INVALID_ADDRESS) {
 if 

[Lldb-commits] [lldb] [lldb] [ObjectFileMachO] LLVM_COV is not mapped into firmware memory (PR #86359)

[Jason Molenda via lldb-commits]

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

[Lldb-commits] [lldb] 765d4c4 - [lldb] [ObjectFileMachO] LLVM_COV is not mapped into firmware memory (#86359)

[via lldb-commits]

Author: Jason Molenda
Date: 2024-03-25T15:00:36-07:00
New Revision: 765d4c402fe2ff614a15a762bb7cefe7289663b4

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

LOG: [lldb] [ObjectFileMachO] LLVM_COV is not mapped into firmware memory 
(#86359)

It is possible to gather code coverage in a firmware environment, where
the __LLVM_COV segment will not be mapped in memory but does exist in
the binary, see

https://llvm.org/devmtg/2020-09/slides/PhippsAlan_EmbeddedCodeCoverage_LLVM_Conf_Talk_final.pdf

The __LLVM_COV segment in the binary happens to be at the same address
as the __DATA segment, so if lldb treats this segment as loaded, it
shadows the __DATA segment and address->symbol resolution can fail.

For these non-userland code cases, we need to mark __LLVM_COV as not a
loadable segment.

rdar://124475661

Added: 


Modified: 
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h

Removed: 




diff  --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index bcf3a3274cf3a0..1caf93659956b4 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -905,6 +905,11 @@ ConstString ObjectFileMachO::GetSegmentNameDWARF() {
   return g_section_name;
 }
 
+ConstString ObjectFileMachO::GetSegmentNameLLVM_COV() {
+  static ConstString g_section_name("__LLVM_COV");
+  return g_section_name;
+}
+
 ConstString ObjectFileMachO::GetSectionNameEHFrame() {
   static ConstString g_section_name_eh_frame("__eh_frame");
   return g_section_name_eh_frame;
@@ -6145,6 +6150,13 @@ bool ObjectFileMachO::SectionIsLoadable(const Section 
*section) {
 return false;
   if (GetModule().get() != section->GetModule().get())
 return false;
+  // firmware style binaries with llvm gcov segment do
+  // not have that segment mapped into memory.
+  if (section->GetName() == GetSegmentNameLLVM_COV()) {
+const Strata strata = GetStrata();
+if (strata == eStrataKernel || strata == eStrataRawImage)
+  return false;
+  }
   // Be careful with __LINKEDIT and __DWARF segments
   if (section->GetName() == GetSegmentNameLINKEDIT() ||
   section->GetName() == GetSegmentNameDWARF()) {

diff  --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
index 0a47f3a7dd1861..55bc688126eb36 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
@@ -271,6 +271,7 @@ class ObjectFileMachO : public lldb_private::ObjectFile {
   static lldb_private::ConstString GetSegmentNameOBJC();
   static lldb_private::ConstString GetSegmentNameLINKEDIT();
   static lldb_private::ConstString GetSegmentNameDWARF();
+  static lldb_private::ConstString GetSegmentNameLLVM_COV();
   static lldb_private::ConstString GetSectionNameEHFrame();
 
   llvm::MachO::dysymtab_command m_dysymtab;



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

[Lldb-commits] [lldb] [lldb] [ObjectFileMachO] LLVM_COV is not mapped into firmware memory (PR #86359)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda updated 
https://github.com/llvm/llvm-project/pull/86359

>From 47bf1259289986cdc0df706aa40a18e58e94eee5 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Fri, 22 Mar 2024 16:31:07 -0700
Subject: [PATCH] [lldb] [ObjectFileMachO] LLVM_COV is not mapped into firmware
 memory

It is possible to gather code coverage in a firmware environment,
where the __LLVM_COV segment will not be mapped in memory but does
exist in the binary, see
https://llvm.org/devmtg/2020-09/slides/PhippsAlan_EmbeddedCodeCoverage_LLVM_Conf_Talk_final.pdf

The __LLVM_COV segment in the binary happens to be at the same
address as the __DATA segment, so if lldb treats this segment as
loaded, it shadows the __DATA segment and address->symbol resolution
can fail.

For these non-userland code cases, we need to mark __LLVM_COV as
not a loadable segment.

rdar://124475661
---
 .../Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp| 12 
 .../Plugins/ObjectFile/Mach-O/ObjectFileMachO.h  |  1 +
 2 files changed, 13 insertions(+)

diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index bcf3a3274cf3a0..1caf93659956b4 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -905,6 +905,11 @@ ConstString ObjectFileMachO::GetSegmentNameDWARF() {
   return g_section_name;
 }
 
+ConstString ObjectFileMachO::GetSegmentNameLLVM_COV() {
+  static ConstString g_section_name("__LLVM_COV");
+  return g_section_name;
+}
+
 ConstString ObjectFileMachO::GetSectionNameEHFrame() {
   static ConstString g_section_name_eh_frame("__eh_frame");
   return g_section_name_eh_frame;
@@ -6145,6 +6150,13 @@ bool ObjectFileMachO::SectionIsLoadable(const Section 
*section) {
 return false;
   if (GetModule().get() != section->GetModule().get())
 return false;
+  // firmware style binaries with llvm gcov segment do
+  // not have that segment mapped into memory.
+  if (section->GetName() == GetSegmentNameLLVM_COV()) {
+const Strata strata = GetStrata();
+if (strata == eStrataKernel || strata == eStrataRawImage)
+  return false;
+  }
   // Be careful with __LINKEDIT and __DWARF segments
   if (section->GetName() == GetSegmentNameLINKEDIT() ||
   section->GetName() == GetSegmentNameDWARF()) {
diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
index 0a47f3a7dd1861..55bc688126eb36 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
@@ -271,6 +271,7 @@ class ObjectFileMachO : public lldb_private::ObjectFile {
   static lldb_private::ConstString GetSegmentNameOBJC();
   static lldb_private::ConstString GetSegmentNameLINKEDIT();
   static lldb_private::ConstString GetSegmentNameDWARF();
+  static lldb_private::ConstString GetSegmentNameLLVM_COV();
   static lldb_private::ConstString GetSectionNameEHFrame();
 
   llvm::MachO::dysymtab_command m_dysymtab;

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

[Lldb-commits] [lldb] [lldb] Implement coalescing of disjoint progress events (PR #84854)

[Jonas Devlieghere via lldb-commits]

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

[Lldb-commits] [lldb] 930f646 - [lldb] Implement coalescing of disjoint progress events (#84854)

[via lldb-commits]

Author: Jonas Devlieghere
Date: 2024-03-25T14:50:58-07:00
New Revision: 930f64689c1fb487714c3836ffa43e49e46aa488

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

LOG: [lldb] Implement coalescing of disjoint progress events (#84854)

This implements coalescing of progress events using a timeout, as
discussed in the RFC on Discourse [1]. This PR consists of two commits
which, depending on the feedback, I may split up into two PRs. For now,
I think it's easier to review this as a whole.

1. The first commit introduces a new generic `Alarm` class. The class
lets you to schedule a function (callback) to be executed after a given
timeout expires. You can cancel and reset a callback before its
corresponding timeout expires. It achieves this with the help of a
worker thread that sleeps until the next timeout expires. The only
guarantee it provides is that your function is called no sooner than the
requested timeout. Because the callback is called directly from the
worker thread, a long running callback could potentially block the
worker thread. I intentionally kept the implementation as simple as
possible while addressing the needs for the `ProgressManager` use case.
If we want to rely on this somewhere else, we can reassess whether we
need to address those limitations.

2. The second commit uses the Alarm class to coalesce progress events.
To recap the Discourse discussion, when multiple progress events with
the same title execute in close succession, they get broadcast as one to
`eBroadcastBitProgressCategory`. The `ProgressManager` keeps track of
the in-flight progress events and when the refcount hits zero, the Alarm
class is used to schedule broadcasting the event. If a new progress
event comes in before the alarm fires, the alarm is reset (and the
process repeats when the new progress event ends). If no new event comes
in before the timeout expires, the progress event is broadcast.

[1]
https://discourse.llvm.org/t/rfc-improve-lldb-progress-reporting/75717/

Added: 


Modified: 
lldb/include/lldb/Core/Progress.h
lldb/source/Core/Progress.cpp
lldb/source/Initialization/SystemInitializerCommon.cpp
lldb/unittests/Core/ProgressReportTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/Progress.h 
b/lldb/include/lldb/Core/Progress.h
index eb3af9816dc6ca..cd87be79c4f0e3 100644
--- a/lldb/include/lldb/Core/Progress.h
+++ b/lldb/include/lldb/Core/Progress.h
@@ -9,6 +9,7 @@
 #ifndef LLDB_CORE_PROGRESS_H
 #define LLDB_CORE_PROGRESS_H
 
+#include "lldb/Host/Alarm.h"
 #include "lldb/lldb-forward.h"
 #include "lldb/lldb-types.h"
 #include "llvm/ADT/StringMap.h"
@@ -150,9 +151,12 @@ class ProgressManager {
   void Increment(const Progress::ProgressData &);
   void Decrement(const Progress::ProgressData &);
 
+  static void Initialize();
+  static void Terminate();
+  static bool Enabled();
   static ProgressManager ();
 
-private:
+protected:
   enum class EventType {
 Begin,
 End,
@@ -160,9 +164,32 @@ class ProgressManager {
   static void ReportProgress(const Progress::ProgressData _data,
  EventType type);
 
-  llvm::StringMap>
-  m_progress_category_map;
-  std::mutex m_progress_map_mutex;
+  static std::optional ();
+
+  /// Helper function for reporting progress when the alarm in the 
corresponding
+  /// entry in the map expires.
+  void Expire(llvm::StringRef key);
+
+  /// Entry used for bookkeeping.
+  struct Entry {
+/// Reference count used for overlapping events.
+uint64_t refcount = 0;
+
+/// Data used to emit progress events.
+Progress::ProgressData data;
+
+/// Alarm handle used when the refcount reaches zero.
+Alarm::Handle handle = Alarm::INVALID_HANDLE;
+  };
+
+  /// Map used for bookkeeping.
+  llvm::StringMap m_entries;
+
+  /// Mutex to provide the map.
+  std::mutex m_entries_mutex;
+
+  /// Alarm instance to coalesce progress events.
+  Alarm m_alarm;
 };
 
 } // namespace lldb_private

diff  --git a/lldb/source/Core/Progress.cpp b/lldb/source/Core/Progress.cpp
index b4b5e98b7ba493..161038284e215a 100644
--- a/lldb/source/Core/Progress.cpp
+++ b/lldb/source/Core/Progress.cpp
@@ -35,7 +35,10 @@ Progress::Progress(std::string title, std::string details,
 
   std::lock_guard guard(m_mutex);
   ReportProgress();
-  ProgressManager::Instance().Increment(m_progress_data);
+
+  // Report to the ProgressManager if that subsystem is enabled.
+  if (ProgressManager::Enabled())
+ProgressManager::Instance().Increment(m_progress_data);
 }
 
 Progress::~Progress() {
@@ -45,7 +48,10 @@ Progress::~Progress() {
   if (!m_completed)
 m_completed = m_total;
   ReportProgress();
-  ProgressManager::Instance().Decrement(m_progress_data);
+
+  // Report to the ProgressManager if that subsystem is 

[Lldb-commits] [lldb] [lldb] [ObjectFileMachO] LLVM_COV is not mapped into firmware memory (PR #86359)

[Jonas Devlieghere via lldb-commits]

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

Ship it!

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

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Florian Mayer via lldb-commits]

fmayer wrote:

> . The point of this patch is not to lambast developers or interfere with 
> their local setups; it's to get the line-ending issues out of the way for 
> good so they can focus on what they do best.

Fair enough. I don't think it will fully make them go away for good, as you 
mentioned "[...] except for specific cases like .bat files or tests for parsers 
that need to accept such sequences." Something somewhere is bound to work 
before the transformation, and no longer after. It's possible that that will be 
more rare, though I would say 100 reverts in all of LLVM history isn't really 
that much either, all things considered.

> And, given what I quoted above, it's not about faith - it's about historical 
> evidence that this is a problem.

I am not saying this isn't a problem at all, but how often has anyone done a 
one line change and caused a 50k diff, and submitted it without noticing?

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

[Lldb-commits] [lldb] [lldb][Dwarf] Fix dwarf parse time for line table and .debug_abbrev. (PR #86568)

[Greg Clayton via lldb-commits]

@@ -1228,10 +1231,9 @@ bool SymbolFileDWARF::ParseLineTable(CompileUnit 
_unit) {
   if (offset == DW_INVALID_OFFSET)
 return false;
 
-  ElapsedTime elapsed(m_parse_time);

clayborg wrote:

We want all of the time in LLDB to parse and prepare the data, not just the 
parsing time. We use this same variable via `ElapsedTime 
elapsed(m_dwarf.GetDebugInfoParseTimeRef());` in DWARFUnit.cpp to time how long 
it takes to parse and prepare the DIE tree for usage.

So the m_parse_time _is_ intended to be used to measure how long LLDB needs to 
parse the DWARF from the object file _and_ how long it takes to prepare the 
data so it can be used.

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

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[via lldb-commits]

ldrumm wrote:

> > That wish is fine until you start working with others.
> 
> Do we actually have that little faith in developers that we think they will 
> check in a 50k line diff?

depending on their diff settings, or the web interface they use, it may not 
show until they actually look at a hex editor. The point of this patch is not 
to lambast developers or interfere with their local setups; it's to get the 
line-ending issues out of the way for good so they can focus on what they do 
best.

And, given what I quoted above, it's not about faith - it's about historical 
evidence that this *is* a problem.

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

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Florian Mayer via lldb-commits]

fmayer wrote:

> That wish is fine until you start working with others.

Do we actually have that little faith in developers that we think they will 
check in a 50k line diff?

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

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[via lldb-commits]

ldrumm wrote:

> I don't have a strong opinion, but fundamentally I would prefer if the source 
> control system stored exactly the files I have in my checkout, not mess with 
> them in any way. I understand there are practical concerns, but a linter for 
> unexpected CRLF would maybe be an option?

That wish is fine until you start working with others. Then you get 5 line 
diffs that are somebody changing a single line on *their* system, because they 
happen to use the opposite system to the last person to check code in.  I think 
the best middle ground here is to say `-text` or `eol=input` for files that 
*must* be encoded a certain way.

As for linters: linters require people to run it, and we still have to encode 
those rules somewhere - just not gitattributes. As far as I can see this is the 
lowest overhead and most reliable *pragmatic* option that has the nice property 
of being fully integrated into the tooling, transparent to end users, and in a 
known (semi) central location.


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

[Lldb-commits] [lldb] [lldb][Dwarf] Fix dwarf parse time for line table and .debug_abbrev. (PR #86568)

[Zequan Wu via lldb-commits]

@@ -1228,10 +1231,9 @@ bool SymbolFileDWARF::ParseLineTable(CompileUnit 
_unit) {
   if (offset == DW_INVALID_OFFSET)
 return false;
 
-  ElapsedTime elapsed(m_parse_time);

ZequanWu wrote:

My understanding is m_parse_time is the time spent only on parsing the raw data 
and not about constructing the data structures which will be used by lldb. In 
https://github.com/llvm/llvm-project/blob/b7611370491873722e08e4ce9374312d0c936af1/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp#L223,
 m_parse_time is used to only track the time spent on parsing a DIE in 
.debug_info, which also doesn't include the time on constructing necessary data 
structures. This change is trying to do the same by narrowing the time to just 
on parsing with llvm.  

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

[Lldb-commits] [lldb] [lldb][Dwarf] Fix dwarf parse time for line table and .debug_abbrev. (PR #86568)

[Greg Clayton via lldb-commits]

@@ -1228,10 +1231,9 @@ bool SymbolFileDWARF::ParseLineTable(CompileUnit 
_unit) {
   if (offset == DW_INVALID_OFFSET)
 return false;
 
-  ElapsedTime elapsed(m_parse_time);

clayborg wrote:

We want this to stay in this function so it measures all of the work done by 
lldb. `m_parse_time` measures both how long it takes us to parse the 
information, but also should include any needed work to make this data usable 
for LLDB. 

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

[Lldb-commits] [lldb] [lldb][Dwarf] Fix dwarf parse time for line table and .debug_abbrev. (PR #86568)

[Greg Clayton via lldb-commits]

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

SymbolFileDWARF::ParseLineTable() does more work after using llvm to parse the 
line table and we still need to measure this. So I believe that the current 
timer was in the correct position. Parse time for DWARF means how long to we 
take to both parse and to cleanup the information for LLDB to use, so the 
entire SymbolFileDWARF::ParseLineTable() function should be measured.

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

[Lldb-commits] [lldb] [lldb][Dwarf] Fix dwarf parse time for line table and .debug_abbrev. (PR #86568)

[Greg Clayton via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][Dwarf] Fix dwarf parse time for line table and .debug_abbrev. (PR #86568)

[via lldb-commits]

github-actions[bot] wrote:



:white_check_mark: With the latest revision this PR passed the Python code 
formatter.

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

[Lldb-commits] [lldb] [lldb][Dwarf] Fix dwarf parse time for line table and .debug_abbrev. (PR #86568)

[via lldb-commits]

github-actions[bot] wrote:



:white_check_mark: With the latest revision this PR passed the C/C++ code 
formatter.

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

[Lldb-commits] [lldb] [lldb][Dwarf] Fix dwarf parse time for line table and .debug_abbrev. (PR #86568)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Zequan Wu (ZequanWu)


Changes

`ParseLineTable` not only parses .debug_line but also constructs `LineTable`.

This moves `m_parse_time` into the the function body of `ParseLLVMLineTable` to 
more accurately reflect parsing time on .debug_line. This also add missing 
timer when parsing `.debug_abbrev`.

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


1 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+6-4) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 08ce7b82b0c16a..8039a35ed8941c 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -145,8 +145,10 @@ static PluginProperties () {
 
 static const llvm::DWARFDebugLine::LineTable *
 ParseLLVMLineTable(DWARFContext , llvm::DWARFDebugLine ,
-   dw_offset_t line_offset, dw_offset_t unit_offset) {
+   dw_offset_t line_offset, dw_offset_t unit_offset,
+   StatsDuration _time) {
   Log *log = GetLog(DWARFLog::DebugInfo);
+  ElapsedTime elapsed(parse_time);
 
   llvm::DWARFDataExtractor data = context.getOrLoadLineData().GetAsLLVMDWARF();
   llvm::DWARFContext  = context.GetAsLLVM();
@@ -693,6 +695,7 @@ llvm::DWARFDebugAbbrev *SymbolFileDWARF::DebugAbbrev() {
   if (debug_abbrev_data.GetByteSize() == 0)
 return nullptr;
 
+  ElapsedTime elapsed(m_parse_time);
   auto abbr =
   std::make_unique(debug_abbrev_data.GetAsLLVM());
   llvm::Error error = abbr->parse();
@@ -1228,10 +1231,9 @@ bool SymbolFileDWARF::ParseLineTable(CompileUnit 
_unit) {
   if (offset == DW_INVALID_OFFSET)
 return false;
 
-  ElapsedTime elapsed(m_parse_time);
   llvm::DWARFDebugLine line;
-  const llvm::DWARFDebugLine::LineTable *line_table =
-  ParseLLVMLineTable(m_context, line, offset, dwarf_cu->GetOffset());
+  const llvm::DWARFDebugLine::LineTable *line_table = ParseLLVMLineTable(
+  m_context, line, offset, dwarf_cu->GetOffset(), m_parse_time);
 
   if (!line_table)
 return false;

``




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

[Lldb-commits] [lldb] [lldb][Dwarf] Fix dwarf parse time for line table and .debug_abbrev. (PR #86568)

[Zequan Wu via lldb-commits]

https://github.com/ZequanWu created 
https://github.com/llvm/llvm-project/pull/86568

`ParseLineTable` not only parses .debug_line but also constructs `LineTable`.

This moves `m_parse_time` into the the function body of `ParseLLVMLineTable` to 
more accurately reflect parsing time on .debug_line. This also add missing 
timer when parsing `.debug_abbrev`.

>From 19dd9a13c21d70b42b9d68aed6fb0b5a5e494685 Mon Sep 17 00:00:00 2001
From: Zequan Wu 
Date: Mon, 25 Mar 2024 15:49:42 -0400
Subject: [PATCH] [lldb][Dwarf] Fix dwarf parse time for line table and
 .debug_abbrev.

---
 .../Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp   | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 08ce7b82b0c16a..8039a35ed8941c 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -145,8 +145,10 @@ static PluginProperties () {
 
 static const llvm::DWARFDebugLine::LineTable *
 ParseLLVMLineTable(DWARFContext , llvm::DWARFDebugLine ,
-   dw_offset_t line_offset, dw_offset_t unit_offset) {
+   dw_offset_t line_offset, dw_offset_t unit_offset,
+   StatsDuration _time) {
   Log *log = GetLog(DWARFLog::DebugInfo);
+  ElapsedTime elapsed(parse_time);
 
   llvm::DWARFDataExtractor data = context.getOrLoadLineData().GetAsLLVMDWARF();
   llvm::DWARFContext  = context.GetAsLLVM();
@@ -693,6 +695,7 @@ llvm::DWARFDebugAbbrev *SymbolFileDWARF::DebugAbbrev() {
   if (debug_abbrev_data.GetByteSize() == 0)
 return nullptr;
 
+  ElapsedTime elapsed(m_parse_time);
   auto abbr =
   std::make_unique(debug_abbrev_data.GetAsLLVM());
   llvm::Error error = abbr->parse();
@@ -1228,10 +1231,9 @@ bool SymbolFileDWARF::ParseLineTable(CompileUnit 
_unit) {
   if (offset == DW_INVALID_OFFSET)
 return false;
 
-  ElapsedTime elapsed(m_parse_time);
   llvm::DWARFDebugLine line;
-  const llvm::DWARFDebugLine::LineTable *line_table =
-  ParseLLVMLineTable(m_context, line, offset, dwarf_cu->GetOffset());
+  const llvm::DWARFDebugLine::LineTable *line_table = ParseLLVMLineTable(
+  m_context, line, offset, dwarf_cu->GetOffset(), m_parse_time);
 
   if (!line_table)
 return false;

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

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Florian Mayer via lldb-commits]

fmayer wrote:

I don't have a strong opinion, but fundamentally I would prefer if the source 
control system stored exactly the files I have in my checkout, not mess with 
them in any way. I understand there are practical concerns, but a linter for 
unexpected CRLF would maybe be an option?

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

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[David Blaikie via lldb-commits]

dwblaikie wrote:

> For those files in the repository that do need CRLF endings, I've adopted a 
> policy of eol=crlf which means that git will store them in history with LF, 
> but regardless of user config, they'll be checked out in tree with CRLF.

This ^ seems a bit problematic to me, though (where the contents of the repo 
isn't representative of the bits we want - but perhaps it's schrodinger's line 
endings & it doesn't matter if it's always checked out as crlf - though if we 
one day converted to another source control system, would that be a problem? 
are there some things that examine the underlying/"real" repo contents?) - what 
would be the cost to using `eol=input` as you've done for the mixed line ending 
case? below \=

> There also appears to be a single test,
clang/test/Frontend/rewrite-includes-mixed-eol-crlf.[ch] which needs mixed line 
endings. This one uses eol=input to preserve it as-is.

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

[Lldb-commits] [lldb] [lldb][TypeSystem] Enable colored AST dump (PR #86159)

[via lldb-commits]

jimingham wrote:

You can't get from a TypeSystem to a Target directly, because TypeSystem's live 
in Modules and Modules live outside any particular target in the global module 
cache.  Maybe you need to pass this in to the call to dump the functions.  The 
command-line will always have a current target, and if you are doing this 
through the SB API you probably want local control of whether to use colors or 
not anyway.

Jim

> On Mar 25, 2024, at 7:35 AM, Michael Buch ***@***.***> wrote:
> 
> 
> What happens if you have colors disabled in your terminal? Does this do 
> nothing? Or does it start inserting ANSI escape codes in plain text?
> 
> Yea good question, was about to try this out. It does whatever clang's 
> ast-dump would do if colors aren't turned off
> 
> That keys off of the output stream supporting colors, but LLDB also allows 
> you to disable colors globally. Please also try lldb --no-use-colors and see 
> if that behaves correctly (it might if we set the properties of the stream 
> correctly). If it doesn't you'll need to read debugger.GetUseColor().
> 
> It behaves correctly for the target modules dump ast case because that uses 
> the LLDB streams, as you mentioned. For other diagnostics we would have to 
> use the GetUseColor API, though we'd have to plumb the target through to 
> TypeSystemClang::CreateASTContext first, to get access to the debugger 
> object. Will try that instead
> 
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because you are on a team that was mentioned.
> 



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

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[via lldb-commits]

ldrumm wrote:

> Should we come up with an expected filename format that we can use with 
> gitattributes and rename the existing files rather than just listing each 
> file that has special needs by itself?

Either way, the author has to do or know *something*. I'm not a fan of "magic" 
like this (notwithstanding the use of file extensions for common win32 formats 
here), so I'd personally just prefer that the tests that require knowledge of 
line endings are manually tracked and documented in the gitattributes file.

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

[Lldb-commits] [lldb] DebugInfoD tests + fixing issues exposed by tests (PR #85693)

[Kevin Frei via lldb-commits]

kevinfrei wrote:


> New tests apparently are failing on Arm/AArch64 Linux.

The failure indicates that the failing tests' build don't include a UUID, which 
*should* be generated by the changes to Makefile.rules. Any idea how I ought to 
proceed with reproducing a build on a system that I have no access to? I could 
probably dust off an RPi 4 at home tonight, if that would be a reasonable repro 
platform. Alternatively, I can make the test resolve (but not succeed...) by 
checking to make sure that the UUID is actually found.


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

[Lldb-commits] [lldb] [lldb][TypeSystem] Enable colored AST dump (PR #86159)

[Michael Buch via lldb-commits]

Michael137 wrote:

> > > What happens if you have colors disabled in your terminal? Does this do 
> > > nothing? Or does it start inserting ANSI escape codes in plain text?
> > 
> > 
> > Yea good question, was about to try this out. It does whatever clang's 
> > `ast-dump` would do if colors aren't turned off
> 
> That keys off of the output stream supporting colors, but LLDB also allows 
> you to disable colors globally. Please also try `lldb --no-use-colors` and 
> see if that behaves correctly (it might if we set the properties of the 
> stream correctly). If it doesn't you'll need to read `debugger.GetUseColor()`.

It behaves correctly for the `target modules dump ast` case because that uses 
the LLDB streams, as you mentioned. For other diagnostics we would have to use 
the `GetUseColor` API, though we'd have to plumb the target through to 
`TypeSystemClang::CreateASTContext` first, to get access to the debugger 
object. Will try that instead

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

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Chris B via lldb-commits]

llvm-beanz wrote:

Philosophically I agree with this change, but I think some subprojects may need 
to adopt specific policies about how they handle files that are expected to be 
specific line endings. Specifically, Clang needs testing that verifies correct 
behavior on both CRLF and LF files in some cases, as does LLVM's split-file.

I did a pass a few years ago fixing a bunch of tests that had hard-specified 
file offsets in them that broke if you had CRLF line endings, and fixing how 
the correct line ending type was detected (some of the changes are 
13fa17db3a720d149bcd0783856347a4f09cf634, 
9d3437fbf3419502351d41ff9e28f06b0c3f06e8, 
ea836c880abcc74d3983fc35de407d647f0a002d, 
1c1b0027e86fab2b0877488abc1625a457ca70b3).

Should we come up with an expected filename format that we can use with 
gitattributes and rename the existing files rather than just listing each file 
that has special needs by itself?

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

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[via lldb-commits]

ldrumm wrote:

On Mon Mar 25, 2024 at 1:48 PM GMT, Tobias Hieta wrote:

> > I think .natvis files should be CRLF (those are used with Visual Studio for 
> > debug visualizers).
>
> Agreed, Visual Studio should handle this correctly, but who knows
> 路
>

Thanks. I'll add a rule and update


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

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Tobias Hieta via lldb-commits]

tru wrote:

> I think .natvis files should be CRLF (those are used with Visual Studio for 
> debug visualizers).

Agreed, Visual Studio should handle this correctly, but who knows 路 

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

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Aaron Ballman via lldb-commits]

https://github.com/AaronBallman commented:

The changes seem reasonable to me, but there are test failures in 
`llvm/utils/lit/tests` that could perhaps be related to your changes.

I think .natvis files should be CRLF (those are used with Visual Studio for 
debug visualizers).

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