[Lldb-commits] [lldb] [lldb] Fixed the test TestGdbRemoteLaunch (PR #91931)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

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

>From 361cd689e3900c5ab542a5158807eb532879677e Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Mon, 13 May 2024 11:26:03 +0400
Subject: [PATCH] [lldb] Fixed the test TestGdbRemoteLaunch

Install `a.out` to the remote target (after handshake) if necessary and use the 
remote path to call vRun.
---
 .../tools/lldb-server/TestGdbRemoteLaunch.py  | 41 +--
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py 
b/lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
index 78a4d326c12d1..ad84a40932c65 100644
--- a/lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
+++ b/lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
@@ -12,13 +12,13 @@ class 
GdbRemoteLaunchTestCase(gdbremote_testcase.GdbRemoteTestCaseBase):
 @add_test_categories(["llgs"])
 def test_launch_via_A(self):
 self.build()
-exe_path = self.getBuildArtifact("a.out")
-args = [exe_path, "stderr:arg1", "stderr:arg2", "stderr:arg3"]
-hex_args = [seven.hexlify(x) for x in args]
-
 server = self.connect_to_debug_monitor()
 self.assertIsNotNone(server)
 self.do_handshake()
+exe_path = lldbutil.install_to_target(self, 
self.getBuildArtifact("a.out"))
+args = [exe_path, "stderr:arg1", "stderr:arg2", "stderr:arg3"]
+hex_args = [seven.hexlify(x) for x in args]
+
 # NB: strictly speaking we should use %x here but this packet
 # is deprecated, so no point in changing lldb-server's expectations
 self.test_sequence.add_log_lines(
@@ -38,13 +38,13 @@ def test_launch_via_A(self):
 @add_test_categories(["llgs"])
 def test_launch_via_vRun(self):
 self.build()
-exe_path = self.getBuildArtifact("a.out")
-args = [exe_path, "stderr:arg1", "stderr:arg2", "stderr:arg3"]
-hex_args = [seven.hexlify(x) for x in args]
-
 server = self.connect_to_debug_monitor()
 self.assertIsNotNone(server)
 self.do_handshake()
+exe_path = lldbutil.install_to_target(self, 
self.getBuildArtifact("a.out"))
+args = [exe_path, "stderr:arg1", "stderr:arg2", "stderr:arg3"]
+hex_args = [seven.hexlify(x) for x in args]
+
 self.test_sequence.add_log_lines(
 [
 "read packet: $vRun;%s;%s;%s;%s#00" % tuple(hex_args),
@@ -60,12 +60,12 @@ def test_launch_via_vRun(self):
 @add_test_categories(["llgs"])
 def test_launch_via_vRun_no_args(self):
 self.build()
-exe_path = self.getBuildArtifact("a.out")
-hex_path = seven.hexlify(exe_path)
-
 server = self.connect_to_debug_monitor()
 self.assertIsNotNone(server)
 self.do_handshake()
+exe_path = lldbutil.install_to_target(self, 
self.getBuildArtifact("a.out"))
+hex_path = seven.hexlify(exe_path)
+
 self.test_sequence.add_log_lines(
 [
 "read packet: $vRun;%s#00" % (hex_path,),
@@ -78,6 +78,7 @@ def test_launch_via_vRun_no_args(self):
 self.expect_gdbremote_sequence()
 
 @add_test_categories(["llgs"])
+@skipIfRemote
 def test_launch_failure_via_vRun(self):
 self.build()
 exe_path = self.getBuildArtifact("a.out")
@@ -110,14 +111,13 @@ def test_launch_failure_via_vRun(self):
 @add_test_categories(["llgs"])
 def test_QEnvironment(self):
 self.build()
-exe_path = self.getBuildArtifact("a.out")
-env = {"FOO": "test", "BAR": "a=z"}
-args = [exe_path, "print-env:FOO", "print-env:BAR"]
-hex_args = [seven.hexlify(x) for x in args]
-
 server = self.connect_to_debug_monitor()
 self.assertIsNotNone(server)
 self.do_handshake()
+exe_path = lldbutil.install_to_target(self, 
self.getBuildArtifact("a.out"))
+env = {"FOO": "test", "BAR": "a=z"}
+args = [exe_path, "print-env:FOO", "print-env:BAR"]
+hex_args = [seven.hexlify(x) for x in args]
 
 for key, value in env.items():
 self.test_sequence.add_log_lines(
@@ -143,14 +143,13 @@ def test_QEnvironment(self):
 @add_test_categories(["llgs"])
 def test_QEnvironmentHexEncoded(self):
 self.build()
-exe_path = self.getBuildArtifact("a.out")
-env = {"FOO": "test", "BAR": "a=z", "BAZ": "a*}#z"}
-args = [exe_path, "print-env:FOO", "print-env:BAR", "print-env:BAZ"]
-hex_args = [seven.hexlify(x) for x in args]
-
 server = self.connect_to_debug_monitor()
 self.assertIsNotNone(server)
 self.do_handshake()
+exe_path = lldbutil.install_to_target(self, 
self.getBuildArtifact("a.out"))
+env = {"FOO": "test", "BAR": "a=z", "BAZ": "a*}#z"}
+args = [exe_path, "print-env:FOO", "print-env:BAR", "print-env:BAZ"]
+hex_args = [seven.hexlify(x) for x in args]
 
 for key, valu

[Lldb-commits] [lldb] [lldb] Fix the test TestGdbRemotePlatformFile (PR #91918)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

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

>From 4eee83a3a6b923075a9e6db217349726780c31f4 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Mon, 13 May 2024 10:34:04 +0400
Subject: [PATCH] [lldb] Fix the test TestGdbRemotePlatformFile

It is necessary to transfer the test file to/from the really remote target (for 
example Windows host and Linux target).
Also ignore chmod check in case of Windows host.
---
 .../lldb-server/TestGdbRemotePlatformFile.py  | 33 +--
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/lldb/test/API/tools/lldb-server/TestGdbRemotePlatformFile.py 
b/lldb/test/API/tools/lldb-server/TestGdbRemotePlatformFile.py
index 4c8ce01e8ba31..2e1c72ee56d7a 100644
--- a/lldb/test/API/tools/lldb-server/TestGdbRemotePlatformFile.py
+++ b/lldb/test/API/tools/lldb-server/TestGdbRemotePlatformFile.py
@@ -1,6 +1,7 @@
 # lldb test suite imports
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import TestBase
+from lldbsuite.test import lldbutil
 
 # gdb-remote-specific imports
 import lldbgdbserverutils
@@ -117,6 +118,7 @@ def test_platform_file_wronly_creat_excl_fail(self):
 temp_file = self.getBuildArtifact("test")
 with open(temp_file, "wb"):
 pass
+temp_file = lldbutil.install_to_target(self, temp_file)
 
 # attempt to open the file with O_CREAT|O_EXCL
 self.do_handshake()
@@ -140,6 +142,7 @@ def test_platform_file_size(self):
 test_data = b"test data of some length"
 with open(temp_path, "wb") as temp_file:
 temp_file.write(test_data)
+temp_path = lldbutil.install_to_target(self, temp_path)
 
 self.do_handshake()
 self.test_sequence.add_log_lines(
@@ -167,7 +170,11 @@ def test_platform_file_mode(self):
 test_mode = 0o751
 
 with open(temp_path, "wb") as temp_file:
-os.chmod(temp_file.fileno(), test_mode)
+if lldbplatformutil.getHostPlatform() == "windows":
+test_mode = 0o700
+else:
+os.chmod(temp_file.fileno(), test_mode)
+temp_path = lldbutil.install_to_target(self, temp_path)
 
 self.do_handshake()
 self.test_sequence.add_log_lines(
@@ -213,6 +220,7 @@ def test_platform_file_exists(self):
 temp_path = self.getBuildArtifact("test")
 with open(temp_path, "wb"):
 pass
+temp_path = lldbutil.install_to_target(self, temp_path)
 
 self.do_handshake()
 self.test_sequence.add_log_lines(
@@ -244,6 +252,10 @@ def test_platform_file_exists_not(self):
 self.expect_gdbremote_sequence()
 
 @skipIfWindows
+# FIXME: lldb.remote_platform.Install() cannot copy opened temp file on 
Windows.
+# It is possible to use tempfile.NamedTemporaryFile(..., delete=False) and
+# delete the temp file manually at the end.
+@skipIf(hostoslist=["windows"])
 @add_test_categories(["llgs"])
 def test_platform_file_fstat(self):
 server = self.connect_to_debug_monitor()
@@ -252,12 +264,13 @@ def test_platform_file_fstat(self):
 with tempfile.NamedTemporaryFile() as temp_file:
 temp_file.write(b"some test data for stat")
 temp_file.flush()
+temp_path = lldbutil.install_to_target(self, temp_file.name)
 
 self.do_handshake()
 self.test_sequence.add_log_lines(
 [
 "read packet: $vFile:open:%s,0,0#00"
-% (binascii.b2a_hex(temp_file.name.encode()).decode(),),
+% (binascii.b2a_hex(temp_path.encode()).decode(),),
 {
 "direction": "send",
 "regex": r"^\$F([0-9a-fA-F]+)#[0-9a-fA-F]{2}$",
@@ -359,9 +372,12 @@ def vFile_test(
 
 if creat:
 self.assertFalse(os.path.exists(temp_path))
+if lldb.remote_platform:
+temp_path = lldbutil.append_to_process_working_directory(self, 
"test")
 else:
 with open(temp_path, "wb") as temp_file:
 temp_file.write(test_data.encode())
+temp_path = lldbutil.install_to_target(self, temp_path)
 
 # open the file for reading
 self.do_handshake()
@@ -448,8 +464,19 @@ def vFile_test(
 
 if write:
 # check if the data was actually written
+if lldb.remote_platform:
+local_path = self.getBuildArtifact("file_from_target")
+error = lldb.remote_platform.Get(
+lldb.SBFileSpec(temp_path, False), 
lldb.SBFileSpec(local_path, True)
+)
+self.assertTrue(
+error.Success(),
+"Reading file {0} failed: {1}".format(temp_path, error),
+)
+temp_path = local_path
+
 with open(temp_path, "rb") as temp_file:
-if cre

[Lldb-commits] [lldb] [lldb] Fix the test TestGdbRemotePlatformFile (PR #91918)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits


@@ -108,6 +109,20 @@ def test_platform_file_wronly_fail(self):
 )
 self.expect_gdbremote_sequence()
 
+def remote_install(self, path, filename="test"):
+if lldb.remote_platform:
+remote_path = lldbutil.append_to_process_working_directory(self, 
filename)
+err = lldb.remote_platform.Install(
+lldb.SBFileSpec(path, True), lldb.SBFileSpec(remote_path, 
False)
+)
+if err.Fail():
+raise Exception(
+"remote_platform.Install('%s', '%s') failed: %s"
+% (path, remote_path, err)
+)
+path = remote_path
+return path

slydiman wrote:

I have updated this patch using lldbutil.install_to_target().

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


[Lldb-commits] [lldb] e2f079c - [lldb] Fixed the test TestGdbRemoteLaunch (#91931)

2024-05-14 Thread via lldb-commits

Author: Dmitry Vasilyev
Date: 2024-05-14T11:26:14+04:00
New Revision: e2f079cc6c3689fa5a6f64550b2d4fdc628dad6f

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

LOG: [lldb] Fixed the test TestGdbRemoteLaunch (#91931)

Install `a.out` to the remote target (after handshake) if necessary and
use the remote path to call `vRun`.

Added: 


Modified: 
lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py

Removed: 




diff  --git a/lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py 
b/lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
index 78a4d326c12d1..ad84a40932c65 100644
--- a/lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
+++ b/lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
@@ -12,13 +12,13 @@ class 
GdbRemoteLaunchTestCase(gdbremote_testcase.GdbRemoteTestCaseBase):
 @add_test_categories(["llgs"])
 def test_launch_via_A(self):
 self.build()
-exe_path = self.getBuildArtifact("a.out")
-args = [exe_path, "stderr:arg1", "stderr:arg2", "stderr:arg3"]
-hex_args = [seven.hexlify(x) for x in args]
-
 server = self.connect_to_debug_monitor()
 self.assertIsNotNone(server)
 self.do_handshake()
+exe_path = lldbutil.install_to_target(self, 
self.getBuildArtifact("a.out"))
+args = [exe_path, "stderr:arg1", "stderr:arg2", "stderr:arg3"]
+hex_args = [seven.hexlify(x) for x in args]
+
 # NB: strictly speaking we should use %x here but this packet
 # is deprecated, so no point in changing lldb-server's expectations
 self.test_sequence.add_log_lines(
@@ -38,13 +38,13 @@ def test_launch_via_A(self):
 @add_test_categories(["llgs"])
 def test_launch_via_vRun(self):
 self.build()
-exe_path = self.getBuildArtifact("a.out")
-args = [exe_path, "stderr:arg1", "stderr:arg2", "stderr:arg3"]
-hex_args = [seven.hexlify(x) for x in args]
-
 server = self.connect_to_debug_monitor()
 self.assertIsNotNone(server)
 self.do_handshake()
+exe_path = lldbutil.install_to_target(self, 
self.getBuildArtifact("a.out"))
+args = [exe_path, "stderr:arg1", "stderr:arg2", "stderr:arg3"]
+hex_args = [seven.hexlify(x) for x in args]
+
 self.test_sequence.add_log_lines(
 [
 "read packet: $vRun;%s;%s;%s;%s#00" % tuple(hex_args),
@@ -60,12 +60,12 @@ def test_launch_via_vRun(self):
 @add_test_categories(["llgs"])
 def test_launch_via_vRun_no_args(self):
 self.build()
-exe_path = self.getBuildArtifact("a.out")
-hex_path = seven.hexlify(exe_path)
-
 server = self.connect_to_debug_monitor()
 self.assertIsNotNone(server)
 self.do_handshake()
+exe_path = lldbutil.install_to_target(self, 
self.getBuildArtifact("a.out"))
+hex_path = seven.hexlify(exe_path)
+
 self.test_sequence.add_log_lines(
 [
 "read packet: $vRun;%s#00" % (hex_path,),
@@ -78,6 +78,7 @@ def test_launch_via_vRun_no_args(self):
 self.expect_gdbremote_sequence()
 
 @add_test_categories(["llgs"])
+@skipIfRemote
 def test_launch_failure_via_vRun(self):
 self.build()
 exe_path = self.getBuildArtifact("a.out")
@@ -110,14 +111,13 @@ def test_launch_failure_via_vRun(self):
 @add_test_categories(["llgs"])
 def test_QEnvironment(self):
 self.build()
-exe_path = self.getBuildArtifact("a.out")
-env = {"FOO": "test", "BAR": "a=z"}
-args = [exe_path, "print-env:FOO", "print-env:BAR"]
-hex_args = [seven.hexlify(x) for x in args]
-
 server = self.connect_to_debug_monitor()
 self.assertIsNotNone(server)
 self.do_handshake()
+exe_path = lldbutil.install_to_target(self, 
self.getBuildArtifact("a.out"))
+env = {"FOO": "test", "BAR": "a=z"}
+args = [exe_path, "print-env:FOO", "print-env:BAR"]
+hex_args = [seven.hexlify(x) for x in args]
 
 for key, value in env.items():
 self.test_sequence.add_log_lines(
@@ -143,14 +143,13 @@ def test_QEnvironment(self):
 @add_test_categories(["llgs"])
 def test_QEnvironmentHexEncoded(self):
 self.build()
-exe_path = self.getBuildArtifact("a.out")
-env = {"FOO": "test", "BAR": "a=z", "BAZ": "a*}#z"}
-args = [exe_path, "print-env:FOO", "print-env:BAR", "print-env:BAZ"]
-hex_args = [seven.hexlify(x) for x in args]
-
 server = self.connect_to_debug_monitor()
 self.assertIsNotNone(server)
 self.do_handshake()
+exe_path = lldbutil.install_to_target(self, 
self.getBuildArtifact("a.out"))
+env = {"FOO": "test", "BAR": "a=z", "BAZ": "a*}#z"}
+args = [e

[Lldb-commits] [lldb] [lldb] Fixed the test TestGdbRemoteLaunch (PR #91931)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

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


[Lldb-commits] [lldb] [lldb][Windows] Fixed the test TestGdbRemoteMemoryTagging (PR #92077)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

https://github.com/slydiman created 
https://github.com/llvm/llvm-project/pull/92077

Windows path is case insensitive. Tests `test_QMemTags_packets` and 
`test_qMemTags_packets` will use the same build dir and conflict. Added a 
suffix to resolve conflicts.

>From 2b75da41ef3a0056375d01d45954d0ef033414c4 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Tue, 14 May 2024 11:51:12 +0400
Subject: [PATCH] [lldb][Windows] Fixed the test TestGdbRemoteMemoryTagging

Windows path is case insensitive. Tests `test_QMemTags_packets` and 
`test_qMemTags_packets` will use the same build dir and conflict. Added a 
suffix to resolve conflicts.
---
 .../lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py 
b/lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
index 584de5e2ef49e..e14c7b4a39d58 100644
--- 
a/lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
+++ 
b/lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
@@ -84,7 +84,7 @@ def prep_memtags_test(self):
 @skipUnlessArch("aarch64")
 @skipUnlessPlatform(["linux"])
 @skipUnlessAArch64MTELinuxCompiler
-def test_qMemTags_packets(self):
+def test_qMemTags_packets_A(self):
 """Test that qMemTags packets are parsed correctly and/or rejected."""
 buf_address, page_size = self.prep_memtags_test()
 
@@ -154,7 +154,7 @@ def check_tag_write(self, body, expected):
 @skipUnlessArch("aarch64")
 @skipUnlessPlatform(["linux"])
 @skipUnlessAArch64MTELinuxCompiler
-def test_QMemTags_packets(self):
+def test_QMemTags_packets_B(self):
 """Test that QMemTags packets are parsed correctly and/or rejected."""
 buf_address, page_size = self.prep_memtags_test()
 

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


[Lldb-commits] [lldb] [lldb][Windows] Fixed the test TestGdbRemoteMemoryTagging (PR #92077)

2024-05-14 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Dmitry Vasilyev (slydiman)


Changes

Windows path is case insensitive. Tests `test_QMemTags_packets` and 
`test_qMemTags_packets` will use the same build dir and conflict. Added a 
suffix to resolve conflicts.

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


1 Files Affected:

- (modified) 
lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py 
(+2-2) 


``diff
diff --git 
a/lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py 
b/lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
index 584de5e2ef49e..e14c7b4a39d58 100644
--- 
a/lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
+++ 
b/lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
@@ -84,7 +84,7 @@ def prep_memtags_test(self):
 @skipUnlessArch("aarch64")
 @skipUnlessPlatform(["linux"])
 @skipUnlessAArch64MTELinuxCompiler
-def test_qMemTags_packets(self):
+def test_qMemTags_packets_A(self):
 """Test that qMemTags packets are parsed correctly and/or rejected."""
 buf_address, page_size = self.prep_memtags_test()
 
@@ -154,7 +154,7 @@ def check_tag_write(self, body, expected):
 @skipUnlessArch("aarch64")
 @skipUnlessPlatform(["linux"])
 @skipUnlessAArch64MTELinuxCompiler
-def test_QMemTags_packets(self):
+def test_QMemTags_packets_B(self):
 """Test that QMemTags packets are parsed correctly and/or rejected."""
 buf_address, page_size = self.prep_memtags_test()
 

``




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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread via lldb-commits

https://github.com/GeorgeHuyubo created 
https://github.com/llvm/llvm-project/pull/92078

As we have debuginfod as symbol locator available in lldb now, we want to make 
full use of it.
In case of post mortem debugging, we don't always have the main executable 
available. 
However, the .note.gnu.build-id of the main executable(some other modules too), 
should be available in the core file, as those binaries are loaded in memory 
and dumped in the core file.

We try to iterate through the NT_FILE entries, read and store the gnu build id 
if possible. This will be very useful as this id is the unique key which is 
needed for querying the debuginfod server.

Test:
Build and run lldb. Breakpoint set to 
https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolLocator/Debuginfod/SymbolLocatorDebuginfod.cpp#L147
Verified after this commit, module_uuid is the correct gnu build id of the main 
executable which caused the crash(first in the NT_FILE entry)

>From 6a84c484070d53515c7cc473b4a0c1d566342b0f Mon Sep 17 00:00:00 2001
From: George Hu 
Date: Mon, 13 May 2024 17:03:30 -0700
Subject: [PATCH] Read and store gnu build id from loaded core file

---
 lldb/include/lldb/Target/Process.h| 48 +++
 lldb/source/Commands/CommandObjectMemory.cpp  | 59 +--
 .../Process/elf-core/ProcessElfCore.cpp   | 46 +++
 .../Plugins/Process/elf-core/ProcessElfCore.h | 10 
 lldb/source/Target/Process.cpp| 27 +
 5 files changed, 132 insertions(+), 58 deletions(-)

diff --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index aac0cf51680a9..989434955512f 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -406,6 +406,36 @@ class Process : public 
std::enable_shared_from_this,
   lldb::StateType state);
   } Notifications;
 
+  class ProcessMemoryIterator {
+  public:
+ProcessMemoryIterator(lldb::ProcessSP process_sp, lldb::addr_t base)
+: m_process_sp(process_sp), m_base_addr(base) {
+  lldbassert(process_sp.get() != nullptr);
+}
+
+bool IsValid() { return m_is_valid; }
+
+uint8_t operator[](lldb::addr_t offset) {
+  if (!IsValid())
+return 0;
+
+  uint8_t retval = 0;
+  Status error;
+  if (0 ==
+  m_process_sp->ReadMemory(m_base_addr + offset, &retval, 1, error)) {
+m_is_valid = false;
+return 0;
+  }
+
+  return retval;
+}
+
+  private:
+lldb::ProcessSP m_process_sp;
+lldb::addr_t m_base_addr;
+bool m_is_valid = true;
+  };
+
   class ProcessEventData : public EventData {
 friend class Process;
 
@@ -1649,6 +1679,24 @@ class Process : public 
std::enable_shared_from_this,
 
   lldb::addr_t ReadPointerFromMemory(lldb::addr_t vm_addr, Status &error);
 
+  /// Fast search for a string within a memory region.
+  ///
+  /// This function searches for the string represented by the provided buffer
+  /// within the memory range specified by the low and high addresses. It uses
+  /// a bad character heuristic to optimize the search process.
+  ///
+  /// \param[in] low The starting address of the memory region to be searched.
+  ///
+  /// \param[in] high The ending address of the memory region to be searched.
+  ///
+  /// \param[in] buffer A pointer to the buffer containing the string to be 
searched.
+  ///
+  /// \param[in] buffer_size The size of the buffer in bytes.
+  ///
+  /// \return The address where the string was found or LLDB_INVALID_ADDRESS 
if not found.
+  lldb::addr_t FastSearch(lldb::addr_t low, lldb::addr_t high, uint8_t *buffer,
+  size_t buffer_size);
+
   bool WritePointerToMemory(lldb::addr_t vm_addr, lldb::addr_t ptr_value,
 Status &error);
 
diff --git a/lldb/source/Commands/CommandObjectMemory.cpp 
b/lldb/source/Commands/CommandObjectMemory.cpp
index b78a0492cca55..fd37465e92c46 100644
--- a/lldb/source/Commands/CommandObjectMemory.cpp
+++ b/lldb/source/Commands/CommandObjectMemory.cpp
@@ -977,35 +977,6 @@ class CommandObjectMemoryFind : public CommandObjectParsed 
{
   Options *GetOptions() override { return &m_option_group; }
 
 protected:
-  class ProcessMemoryIterator {
-  public:
-ProcessMemoryIterator(ProcessSP process_sp, lldb::addr_t base)
-: m_process_sp(process_sp), m_base_addr(base) {
-  lldbassert(process_sp.get() != nullptr);
-}
-
-bool IsValid() { return m_is_valid; }
-
-uint8_t operator[](lldb::addr_t offset) {
-  if (!IsValid())
-return 0;
-
-  uint8_t retval = 0;
-  Status error;
-  if (0 ==
-  m_process_sp->ReadMemory(m_base_addr + offset, &retval, 1, error)) {
-m_is_valid = false;
-return 0;
-  }
-
-  return retval;
-}
-
-  private:
-ProcessSP m_process_sp;
-lldb::addr_t m_base_addr;
-bool m_is_valid = true;
-  };
   void DoExecute(Args &command, 

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (GeorgeHuyubo)


Changes

As we have debuginfod as symbol locator available in lldb now, we want to make 
full use of it.
In case of post mortem debugging, we don't always have the main executable 
available. 
However, the .note.gnu.build-id of the main executable(some other modules too), 
should be available in the core file, as those binaries are loaded in memory 
and dumped in the core file.

We try to iterate through the NT_FILE entries, read and store the gnu build id 
if possible. This will be very useful as this id is the unique key which is 
needed for querying the debuginfod server.

Test:
Build and run lldb. Breakpoint set to 
https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolLocator/Debuginfod/SymbolLocatorDebuginfod.cpp#L147
Verified after this commit, module_uuid is the correct gnu build id of the main 
executable which caused the crash(first in the NT_FILE entry)

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


5 Files Affected:

- (modified) lldb/include/lldb/Target/Process.h (+48) 
- (modified) lldb/source/Commands/CommandObjectMemory.cpp (+1-58) 
- (modified) lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp (+46) 
- (modified) lldb/source/Plugins/Process/elf-core/ProcessElfCore.h (+10) 
- (modified) lldb/source/Target/Process.cpp (+27) 


``diff
diff --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index aac0cf51680a9..989434955512f 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -406,6 +406,36 @@ class Process : public 
std::enable_shared_from_this,
   lldb::StateType state);
   } Notifications;
 
+  class ProcessMemoryIterator {
+  public:
+ProcessMemoryIterator(lldb::ProcessSP process_sp, lldb::addr_t base)
+: m_process_sp(process_sp), m_base_addr(base) {
+  lldbassert(process_sp.get() != nullptr);
+}
+
+bool IsValid() { return m_is_valid; }
+
+uint8_t operator[](lldb::addr_t offset) {
+  if (!IsValid())
+return 0;
+
+  uint8_t retval = 0;
+  Status error;
+  if (0 ==
+  m_process_sp->ReadMemory(m_base_addr + offset, &retval, 1, error)) {
+m_is_valid = false;
+return 0;
+  }
+
+  return retval;
+}
+
+  private:
+lldb::ProcessSP m_process_sp;
+lldb::addr_t m_base_addr;
+bool m_is_valid = true;
+  };
+
   class ProcessEventData : public EventData {
 friend class Process;
 
@@ -1649,6 +1679,24 @@ class Process : public 
std::enable_shared_from_this,
 
   lldb::addr_t ReadPointerFromMemory(lldb::addr_t vm_addr, Status &error);
 
+  /// Fast search for a string within a memory region.
+  ///
+  /// This function searches for the string represented by the provided buffer
+  /// within the memory range specified by the low and high addresses. It uses
+  /// a bad character heuristic to optimize the search process.
+  ///
+  /// \param[in] low The starting address of the memory region to be searched.
+  ///
+  /// \param[in] high The ending address of the memory region to be searched.
+  ///
+  /// \param[in] buffer A pointer to the buffer containing the string to be 
searched.
+  ///
+  /// \param[in] buffer_size The size of the buffer in bytes.
+  ///
+  /// \return The address where the string was found or LLDB_INVALID_ADDRESS 
if not found.
+  lldb::addr_t FastSearch(lldb::addr_t low, lldb::addr_t high, uint8_t *buffer,
+  size_t buffer_size);
+
   bool WritePointerToMemory(lldb::addr_t vm_addr, lldb::addr_t ptr_value,
 Status &error);
 
diff --git a/lldb/source/Commands/CommandObjectMemory.cpp 
b/lldb/source/Commands/CommandObjectMemory.cpp
index b78a0492cca55..fd37465e92c46 100644
--- a/lldb/source/Commands/CommandObjectMemory.cpp
+++ b/lldb/source/Commands/CommandObjectMemory.cpp
@@ -977,35 +977,6 @@ class CommandObjectMemoryFind : public CommandObjectParsed 
{
   Options *GetOptions() override { return &m_option_group; }
 
 protected:
-  class ProcessMemoryIterator {
-  public:
-ProcessMemoryIterator(ProcessSP process_sp, lldb::addr_t base)
-: m_process_sp(process_sp), m_base_addr(base) {
-  lldbassert(process_sp.get() != nullptr);
-}
-
-bool IsValid() { return m_is_valid; }
-
-uint8_t operator[](lldb::addr_t offset) {
-  if (!IsValid())
-return 0;
-
-  uint8_t retval = 0;
-  Status error;
-  if (0 ==
-  m_process_sp->ReadMemory(m_base_addr + offset, &retval, 1, error)) {
-m_is_valid = false;
-return 0;
-  }
-
-  return retval;
-}
-
-  private:
-ProcessSP m_process_sp;
-lldb::addr_t m_base_addr;
-bool m_is_valid = true;
-  };
   void DoExecute(Args &command, CommandReturnObject &result) override {
 // No need to check "process" for validity as eCommandRequiresProcess
 // ensures it is valid
@@ -1106,7 +1

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread 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 f8063ffe73a3a1d704b9738169bb76ebb0f8a5e0 
6a84c484070d53515c7cc473b4a0c1d566342b0f -- lldb/include/lldb/Target/Process.h 
lldb/source/Commands/CommandObjectMemory.cpp 
lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp 
lldb/source/Plugins/Process/elf-core/ProcessElfCore.h 
lldb/source/Target/Process.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index 9894349555..102fa5eef1 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -1689,11 +1689,13 @@ public:
   ///
   /// \param[in] high The ending address of the memory region to be searched.
   ///
-  /// \param[in] buffer A pointer to the buffer containing the string to be 
searched.
+  /// \param[in] buffer A pointer to the buffer containing the string to be
+  /// searched.
   ///
   /// \param[in] buffer_size The size of the buffer in bytes.
   ///
-  /// \return The address where the string was found or LLDB_INVALID_ADDRESS 
if not found.
+  /// \return The address where the string was found or LLDB_INVALID_ADDRESS if
+  /// not found.
   lldb::addr_t FastSearch(lldb::addr_t low, lldb::addr_t high, uint8_t *buffer,
   size_t buffer_size);
 
diff --git a/lldb/source/Commands/CommandObjectMemory.cpp 
b/lldb/source/Commands/CommandObjectMemory.cpp
index fd37465e92..574f1dafc2 100644
--- a/lldb/source/Commands/CommandObjectMemory.cpp
+++ b/lldb/source/Commands/CommandObjectMemory.cpp
@@ -1077,8 +1077,8 @@ protected:
 found_location = low_addr;
 bool ever_found = false;
 while (count) {
-  found_location = process->FastSearch(found_location, high_addr, 
buffer.GetBytes(),
-  buffer.GetByteSize());
+  found_location = process->FastSearch(
+  found_location, high_addr, buffer.GetBytes(), buffer.GetByteSize());
   if (found_location == LLDB_INVALID_ADDRESS) {
 if (!ever_found) {
   result.AppendMessage("data not found within the range.\n");
diff --git a/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp 
b/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
index 7dd2577408..4c1f265d07 100644
--- a/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ b/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -996,34 +996,38 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
 }
 
 bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
-  const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c, 0x46}; // ELF file begin 
with this 4 bytes
+  const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4 bytes
   uint8_t buf[4];
   Status error;
   size_t byte_read = ReadMemory(entry.start, buf, 4, error);
   if (byte_read == 4) {
 return memcmp(elf_header, buf, 4) == 0;
-  } else{
+  } else {
 return false;
   }
 }
 
 UUID ProcessElfCore::FindBuildId(const NT_FILE_Entry entry) {
-  if(!IsElf(entry)) {
+  if (!IsElf(entry)) {
 return UUID();
   }
   // Build ID is stored in the ELF file as a section named ".note.gnu.build-id"
-  uint8_t gnu_build_id_bytes[8] = {0x03, 0x00, 0x00, 0x00, 0x47, 0x4e, 0x55, 
0x00};
-  lldb::addr_t gnu_build_id_addr = FastSearch(entry.start, entry.end , 
gnu_build_id_bytes, 8);
+  uint8_t gnu_build_id_bytes[8] = {0x03, 0x00, 0x00, 0x00,
+   0x47, 0x4e, 0x55, 0x00};
+  lldb::addr_t gnu_build_id_addr =
+  FastSearch(entry.start, entry.end, gnu_build_id_bytes, 8);
   if (load_addr == LLDB_INVALID_ADDRESS) {
 return UUID();
   }
   uint8_t buf[36];
   Status error;
   size_t byte_read = ReadMemory(gnu_build_id_addr - 8, buf, 36, error);
-  // .note.gnu.build-id starts with 04 00 00 00 {id_byte_size} 00 00 00 03 00 
00 00 47 4e 55 00 
+  // .note.gnu.build-id starts with 04 00 00 00 {id_byte_size} 00 00 00 03 00 
00
+  // 00 47 4e 55 00
   if (byte_read == 36) {
 if (buf[0] == 0x04) {
-  return UUID(llvm::ArrayRef(buf + 16, buf[4]/*byte size*/));
+  return UUID(llvm::ArrayRef(buf + 16, buf[4] /*byte size*/));
 }
   }
   return UUID();
diff --git a/lldb/source/Plugins/Process/elf-core/ProcessElfCore.h 
b/lldb/source/Plugins/Process/elf-core/ProcessElfCore.h
index 3d78991ed5..6f47aa28be 100644
--- a/lldb/source/Plugins/Process/elf-core/ProcessElfCore.h
+++ b/lldb/source/Plugins/Process/elf-core/ProcessElfCore.h
@@ -117,7 +117,8 @@ private:
 lldb::addr_t end;
 lldb::addr_t file_ofs;
 std::string path;
-lldb_private::UUID uuid; // extracted from .note.gnu.build-id section from 
core file
+lldb_private::UUID
+uuid; // extracted from .note.gnu.build-id section from core file
   };
 
   // For ProcessElfCo

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread via lldb-commits

https://github.com/GeorgeHuyubo updated 
https://github.com/llvm/llvm-project/pull/92078

>From 4a360988cd7242736a9557463fe529c0eaf44dc2 Mon Sep 17 00:00:00 2001
From: George Hu 
Date: Mon, 13 May 2024 17:03:30 -0700
Subject: [PATCH] Read and store gnu build id from loaded core file

---
 lldb/include/lldb/Target/Process.h| 48 +++
 lldb/source/Commands/CommandObjectMemory.cpp  | 59 +--
 .../Process/elf-core/ProcessElfCore.cpp   | 46 +++
 .../Plugins/Process/elf-core/ProcessElfCore.h | 10 
 lldb/source/Target/Process.cpp| 27 +
 5 files changed, 132 insertions(+), 58 deletions(-)

diff --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index aac0cf51680a9..989434955512f 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -406,6 +406,36 @@ class Process : public 
std::enable_shared_from_this,
   lldb::StateType state);
   } Notifications;
 
+  class ProcessMemoryIterator {
+  public:
+ProcessMemoryIterator(lldb::ProcessSP process_sp, lldb::addr_t base)
+: m_process_sp(process_sp), m_base_addr(base) {
+  lldbassert(process_sp.get() != nullptr);
+}
+
+bool IsValid() { return m_is_valid; }
+
+uint8_t operator[](lldb::addr_t offset) {
+  if (!IsValid())
+return 0;
+
+  uint8_t retval = 0;
+  Status error;
+  if (0 ==
+  m_process_sp->ReadMemory(m_base_addr + offset, &retval, 1, error)) {
+m_is_valid = false;
+return 0;
+  }
+
+  return retval;
+}
+
+  private:
+lldb::ProcessSP m_process_sp;
+lldb::addr_t m_base_addr;
+bool m_is_valid = true;
+  };
+
   class ProcessEventData : public EventData {
 friend class Process;
 
@@ -1649,6 +1679,24 @@ class Process : public 
std::enable_shared_from_this,
 
   lldb::addr_t ReadPointerFromMemory(lldb::addr_t vm_addr, Status &error);
 
+  /// Fast search for a string within a memory region.
+  ///
+  /// This function searches for the string represented by the provided buffer
+  /// within the memory range specified by the low and high addresses. It uses
+  /// a bad character heuristic to optimize the search process.
+  ///
+  /// \param[in] low The starting address of the memory region to be searched.
+  ///
+  /// \param[in] high The ending address of the memory region to be searched.
+  ///
+  /// \param[in] buffer A pointer to the buffer containing the string to be 
searched.
+  ///
+  /// \param[in] buffer_size The size of the buffer in bytes.
+  ///
+  /// \return The address where the string was found or LLDB_INVALID_ADDRESS 
if not found.
+  lldb::addr_t FastSearch(lldb::addr_t low, lldb::addr_t high, uint8_t *buffer,
+  size_t buffer_size);
+
   bool WritePointerToMemory(lldb::addr_t vm_addr, lldb::addr_t ptr_value,
 Status &error);
 
diff --git a/lldb/source/Commands/CommandObjectMemory.cpp 
b/lldb/source/Commands/CommandObjectMemory.cpp
index b78a0492cca55..fd37465e92c46 100644
--- a/lldb/source/Commands/CommandObjectMemory.cpp
+++ b/lldb/source/Commands/CommandObjectMemory.cpp
@@ -977,35 +977,6 @@ class CommandObjectMemoryFind : public CommandObjectParsed 
{
   Options *GetOptions() override { return &m_option_group; }
 
 protected:
-  class ProcessMemoryIterator {
-  public:
-ProcessMemoryIterator(ProcessSP process_sp, lldb::addr_t base)
-: m_process_sp(process_sp), m_base_addr(base) {
-  lldbassert(process_sp.get() != nullptr);
-}
-
-bool IsValid() { return m_is_valid; }
-
-uint8_t operator[](lldb::addr_t offset) {
-  if (!IsValid())
-return 0;
-
-  uint8_t retval = 0;
-  Status error;
-  if (0 ==
-  m_process_sp->ReadMemory(m_base_addr + offset, &retval, 1, error)) {
-m_is_valid = false;
-return 0;
-  }
-
-  return retval;
-}
-
-  private:
-ProcessSP m_process_sp;
-lldb::addr_t m_base_addr;
-bool m_is_valid = true;
-  };
   void DoExecute(Args &command, CommandReturnObject &result) override {
 // No need to check "process" for validity as eCommandRequiresProcess
 // ensures it is valid
@@ -1106,7 +1077,7 @@ class CommandObjectMemoryFind : public 
CommandObjectParsed {
 found_location = low_addr;
 bool ever_found = false;
 while (count) {
-  found_location = FastSearch(found_location, high_addr, buffer.GetBytes(),
+  found_location = process->FastSearch(found_location, high_addr, 
buffer.GetBytes(),
   buffer.GetByteSize());
   if (found_location == LLDB_INVALID_ADDRESS) {
 if (!ever_found) {
@@ -1144,34 +1115,6 @@ class CommandObjectMemoryFind : public 
CommandObjectParsed {
 result.SetStatus(lldb::eReturnStatusSuccessFinishResult);
   }
 
-  lldb::addr_t FastSearch(lldb::addr_t low, lldb::addr_t high, uint8_t *buffer,
-  size

[Lldb-commits] [lldb] [lldb] Fixed the test TestDyldLaunchLinux (PR #92080)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

https://github.com/slydiman created 
https://github.com/llvm/llvm-project/pull/92080

Install a.out and libsignal_file.so to the remote target if necessary.

>From a5b005cbbfd25c9fb3e59f2cb0f98c2f6a3e405d Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Tue, 14 May 2024 12:05:27 +0400
Subject: [PATCH] [lldb] Fixed the test TestDyldLaunchLinux

Install a.out and libsignal_file.so to the remote target if necessary.
---
 .../dyld-launch-linux/TestDyldLaunchLinux.py| 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git 
a/lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py 
b/lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py
index 26360c20db1e2..016b60ec88111 100644
--- a/lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py
+++ b/lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py
@@ -7,6 +7,7 @@
 
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
 
 
 class TestLinux64LaunchingViaDynamicLoader(TestBase):
@@ -39,11 +40,14 @@ def test(self):
 breakpoint_shared_library = target.BreakpointCreateBySourceRegex(
 "get_signal_crash", lldb.SBFileSpec("signal_file.cpp")
 )
+inferior_exe_path = lldbutil.install_to_target(self, 
self.getBuildArtifact("a.out"))
+lldbutil.install_to_target(self, 
self.getBuildArtifact("libsignal_file.so"))
+
 launch_info = lldb.SBLaunchInfo(
 [
 "--library-path",
 self.get_process_working_directory(),
-self.getBuildArtifact("a.out"),
+inferior_exe_path,
 ]
 )
 launch_info.SetWorkingDirectory(self.get_process_working_directory())

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread via lldb-commits

https://github.com/GeorgeHuyubo updated 
https://github.com/llvm/llvm-project/pull/92078

>From fa962b461d949cc26f09f8b4bdbd533d7b73131d Mon Sep 17 00:00:00 2001
From: George Hu 
Date: Mon, 13 May 2024 17:03:30 -0700
Subject: [PATCH] Read and store gnu build id from loaded core file

---
 lldb/include/lldb/Target/Process.h| 50 +++
 lldb/source/Commands/CommandObjectMemory.cpp  | 61 +--
 .../Process/elf-core/ProcessElfCore.cpp   | 50 +++
 .../Plugins/Process/elf-core/ProcessElfCore.h | 11 
 lldb/source/Target/Process.cpp| 27 
 5 files changed, 140 insertions(+), 59 deletions(-)

diff --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index aac0cf51680a9..102fa5eef1e04 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -406,6 +406,36 @@ class Process : public 
std::enable_shared_from_this,
   lldb::StateType state);
   } Notifications;
 
+  class ProcessMemoryIterator {
+  public:
+ProcessMemoryIterator(lldb::ProcessSP process_sp, lldb::addr_t base)
+: m_process_sp(process_sp), m_base_addr(base) {
+  lldbassert(process_sp.get() != nullptr);
+}
+
+bool IsValid() { return m_is_valid; }
+
+uint8_t operator[](lldb::addr_t offset) {
+  if (!IsValid())
+return 0;
+
+  uint8_t retval = 0;
+  Status error;
+  if (0 ==
+  m_process_sp->ReadMemory(m_base_addr + offset, &retval, 1, error)) {
+m_is_valid = false;
+return 0;
+  }
+
+  return retval;
+}
+
+  private:
+lldb::ProcessSP m_process_sp;
+lldb::addr_t m_base_addr;
+bool m_is_valid = true;
+  };
+
   class ProcessEventData : public EventData {
 friend class Process;
 
@@ -1649,6 +1679,26 @@ class Process : public 
std::enable_shared_from_this,
 
   lldb::addr_t ReadPointerFromMemory(lldb::addr_t vm_addr, Status &error);
 
+  /// Fast search for a string within a memory region.
+  ///
+  /// This function searches for the string represented by the provided buffer
+  /// within the memory range specified by the low and high addresses. It uses
+  /// a bad character heuristic to optimize the search process.
+  ///
+  /// \param[in] low The starting address of the memory region to be searched.
+  ///
+  /// \param[in] high The ending address of the memory region to be searched.
+  ///
+  /// \param[in] buffer A pointer to the buffer containing the string to be
+  /// searched.
+  ///
+  /// \param[in] buffer_size The size of the buffer in bytes.
+  ///
+  /// \return The address where the string was found or LLDB_INVALID_ADDRESS if
+  /// not found.
+  lldb::addr_t FastSearch(lldb::addr_t low, lldb::addr_t high, uint8_t *buffer,
+  size_t buffer_size);
+
   bool WritePointerToMemory(lldb::addr_t vm_addr, lldb::addr_t ptr_value,
 Status &error);
 
diff --git a/lldb/source/Commands/CommandObjectMemory.cpp 
b/lldb/source/Commands/CommandObjectMemory.cpp
index b78a0492cca55..574f1dafc2965 100644
--- a/lldb/source/Commands/CommandObjectMemory.cpp
+++ b/lldb/source/Commands/CommandObjectMemory.cpp
@@ -977,35 +977,6 @@ class CommandObjectMemoryFind : public CommandObjectParsed 
{
   Options *GetOptions() override { return &m_option_group; }
 
 protected:
-  class ProcessMemoryIterator {
-  public:
-ProcessMemoryIterator(ProcessSP process_sp, lldb::addr_t base)
-: m_process_sp(process_sp), m_base_addr(base) {
-  lldbassert(process_sp.get() != nullptr);
-}
-
-bool IsValid() { return m_is_valid; }
-
-uint8_t operator[](lldb::addr_t offset) {
-  if (!IsValid())
-return 0;
-
-  uint8_t retval = 0;
-  Status error;
-  if (0 ==
-  m_process_sp->ReadMemory(m_base_addr + offset, &retval, 1, error)) {
-m_is_valid = false;
-return 0;
-  }
-
-  return retval;
-}
-
-  private:
-ProcessSP m_process_sp;
-lldb::addr_t m_base_addr;
-bool m_is_valid = true;
-  };
   void DoExecute(Args &command, CommandReturnObject &result) override {
 // No need to check "process" for validity as eCommandRequiresProcess
 // ensures it is valid
@@ -1106,8 +1077,8 @@ class CommandObjectMemoryFind : public 
CommandObjectParsed {
 found_location = low_addr;
 bool ever_found = false;
 while (count) {
-  found_location = FastSearch(found_location, high_addr, buffer.GetBytes(),
-  buffer.GetByteSize());
+  found_location = process->FastSearch(
+  found_location, high_addr, buffer.GetBytes(), buffer.GetByteSize());
   if (found_location == LLDB_INVALID_ADDRESS) {
 if (!ever_found) {
   result.AppendMessage("data not found within the range.\n");
@@ -1144,34 +1115,6 @@ class CommandObjectMemoryFind : public 
CommandObjectParsed {
 result.SetStatus(lldb::eReturnStatusSuccessFinishResult);
   

[Lldb-commits] [lldb] [lldb] Fixed the test TestDyldLaunchLinux (PR #92080)

2024-05-14 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Dmitry Vasilyev (slydiman)


Changes

Install a.out and libsignal_file.so to the remote target if necessary.

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


1 Files Affected:

- (modified) 
lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py (+5-1) 


``diff
diff --git 
a/lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py 
b/lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py
index 26360c20db1e2..016b60ec88111 100644
--- a/lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py
+++ b/lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py
@@ -7,6 +7,7 @@
 
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
 
 
 class TestLinux64LaunchingViaDynamicLoader(TestBase):
@@ -39,11 +40,14 @@ def test(self):
 breakpoint_shared_library = target.BreakpointCreateBySourceRegex(
 "get_signal_crash", lldb.SBFileSpec("signal_file.cpp")
 )
+inferior_exe_path = lldbutil.install_to_target(self, 
self.getBuildArtifact("a.out"))
+lldbutil.install_to_target(self, 
self.getBuildArtifact("libsignal_file.so"))
+
 launch_info = lldb.SBLaunchInfo(
 [
 "--library-path",
 self.get_process_working_directory(),
-self.getBuildArtifact("a.out"),
+inferior_exe_path,
 ]
 )
 launch_info.SetWorkingDirectory(self.get_process_working_directory())

``




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


[Lldb-commits] [lldb] [lldb] Fix redundant condition in Target.cpp (PR #91882)

2024-05-14 Thread David Spickett via lldb-commits

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

Thanks!

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


[Lldb-commits] [lldb] [lldb] Fix redundant condition in Target.cpp (PR #91882)

2024-05-14 Thread David Spickett via lldb-commits

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


[Lldb-commits] [lldb] c285297 - [lldb] Fix redundant condition in Target.cpp (#91882)

2024-05-14 Thread via lldb-commits

Author: aabhinavg
Date: 2024-05-14T09:14:17+01:00
New Revision: c28529788955dbfada9f8a5092432f09eec2c3ab

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

LOG: [lldb] Fix redundant condition in Target.cpp (#91882)

This commit addresses issue #87244, where a redundant condition was
found in the Target.cpp file. Static analyzer cppcheck flagged the issue
in the Target.cpp file

fix #87244

Added: 


Modified: 
lldb/source/Target/Target.cpp

Removed: 




diff  --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index 82f3040e539a3..77731167995e1 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -841,7 +841,7 @@ static bool CheckIfWatchpointsSupported(Target *target, 
Status &error) {
   if (!num_supported_hardware_watchpoints)
 return true;
 
-  if (num_supported_hardware_watchpoints == 0) {
+  if (*num_supported_hardware_watchpoints == 0) {
 error.SetErrorStringWithFormat(
 "Target supports (%u) hardware watchpoint slots.\n",
 *num_supported_hardware_watchpoints);



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


[Lldb-commits] [lldb] [lldb] Fixed the test TestDyldLaunchLinux (PR #92080)

2024-05-14 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 
c441aa51e16e2fa5f407191287f48d2b7c302ceb...a5b005cbbfd25c9fb3e59f2cb0f98c2f6a3e405d
 lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py
``





View the diff from darker here.


``diff
--- TestDyldLaunchLinux.py  2024-05-14 08:09:09.00 +
+++ TestDyldLaunchLinux.py  2024-05-14 08:14:21.760387 +
@@ -38,13 +38,15 @@
 "// Break here", lldb.SBFileSpec("main.cpp")
 )
 breakpoint_shared_library = target.BreakpointCreateBySourceRegex(
 "get_signal_crash", lldb.SBFileSpec("signal_file.cpp")
 )
-inferior_exe_path = lldbutil.install_to_target(self, 
self.getBuildArtifact("a.out"))
+inferior_exe_path = lldbutil.install_to_target(
+self, self.getBuildArtifact("a.out")
+)
 lldbutil.install_to_target(self, 
self.getBuildArtifact("libsignal_file.so"))
-
+
 launch_info = lldb.SBLaunchInfo(
 [
 "--library-path",
 self.get_process_working_directory(),
 inferior_exe_path,

``




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


[Lldb-commits] [clang] [lldb] [llvm] [openmp] [polly] fix(python): fix comparison to True/False (PR #91858)

2024-05-14 Thread David Spickett via lldb-commits

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


[Lldb-commits] [clang] [lldb] [llvm] [openmp] [polly] fix(python): fix comparison to True/False (PR #91858)

2024-05-14 Thread David Spickett via lldb-commits

DavidSpickett wrote:

If this is split out from the other larger PR, should there be `clang/` changes 
in here?

I've copied your commit message into the PR description, because with the way 
llvm is setup, we use the PR's description as the commit message for a squashed 
version of the changes.

(maybe Github uses the commit message if there's only one and the PR 
description is blank, but I wouldn't bet on it)

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


[Lldb-commits] [lldb] [lldb] Fix the test TestGdbRemotePlatformFile (PR #91918)

2024-05-14 Thread David Spickett via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb] Fix the test TestGdbRemotePlatformFile when run with a remote target (PR #91918)

2024-05-14 Thread David Spickett via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Fixed the test TestThreadStates when run with a remote target (PR #92086)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

https://github.com/slydiman created 
https://github.com/llvm/llvm-project/pull/92086

self.wait_for_running_event(process) is always called after 
self.runCmd("continue"). It is strange to expect eStateConnected here. This 
test failed in case of a remote target. The correct state is eStateRunning. 
Removed incorrect checking.

>From 27df461f6a03581cdcdb6911a943e694125061ee Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Tue, 14 May 2024 12:52:20 +0400
Subject: [PATCH] [lldb] Fixed the test TestThreadStates when run with a remote
 target

self.wait_for_running_event(process) is always called after 
self.runCmd("continue").
It is strange to expect eStateConnected here. This test failed in case of a 
remote target.
The correct state is eStateRunning. Removed incorrect checking.
---
 .../test/API/functionalities/thread/state/TestThreadStates.py | 4 
 1 file changed, 4 deletions(-)

diff --git a/lldb/test/API/functionalities/thread/state/TestThreadStates.py 
b/lldb/test/API/functionalities/thread/state/TestThreadStates.py
index f4c17df523382..4dbe230c0ce85 100644
--- a/lldb/test/API/functionalities/thread/state/TestThreadStates.py
+++ b/lldb/test/API/functionalities/thread/state/TestThreadStates.py
@@ -102,10 +102,6 @@ def thread_state_after_breakpoint_test(self):
 
 def wait_for_running_event(self, process):
 listener = self.dbg.GetListener()
-if lldb.remote_platform:
-lldbutil.expect_state_changes(
-self, listener, process, [lldb.eStateConnected]
-)
 lldbutil.expect_state_changes(self, listener, process, 
[lldb.eStateRunning])
 
 def thread_state_after_continue_test(self):

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


[Lldb-commits] [lldb] [lldb] Fixed the test TestThreadStates when run with a remote target (PR #92086)

2024-05-14 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Dmitry Vasilyev (slydiman)


Changes

self.wait_for_running_event(process) is always called after 
self.runCmd("continue"). It is strange to expect eStateConnected here. This 
test failed in case of a remote target. The correct state is eStateRunning. 
Removed incorrect checking.

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


1 Files Affected:

- (modified) lldb/test/API/functionalities/thread/state/TestThreadStates.py 
(-4) 


``diff
diff --git a/lldb/test/API/functionalities/thread/state/TestThreadStates.py 
b/lldb/test/API/functionalities/thread/state/TestThreadStates.py
index f4c17df523382..4dbe230c0ce85 100644
--- a/lldb/test/API/functionalities/thread/state/TestThreadStates.py
+++ b/lldb/test/API/functionalities/thread/state/TestThreadStates.py
@@ -102,10 +102,6 @@ def thread_state_after_breakpoint_test(self):
 
 def wait_for_running_event(self, process):
 listener = self.dbg.GetListener()
-if lldb.remote_platform:
-lldbutil.expect_state_changes(
-self, listener, process, [lldb.eStateConnected]
-)
 lldbutil.expect_state_changes(self, listener, process, 
[lldb.eStateRunning])
 
 def thread_state_after_continue_test(self):

``




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


[Lldb-commits] [lldb] [lldb][Windows] Fixed the test gdb_remote_client/TestGDBRemotePlatformFile (PR #92088)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

https://github.com/slydiman created 
https://github.com/llvm/llvm-project/pull/92088

The tests `test_file_permissions` and `test_file_permissions_fallback` are 
disabled for Windows target. These tests use MockGDBServerResponder and do not 
depend on the real target. These tests failed in case of Windows host and Linux 
target. Disable them for Windows host too.

>From 7dcfe773b6eef27aabbcc7fc68cd6448bc3c2e88 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Tue, 14 May 2024 13:08:35 +0400
Subject: [PATCH] [lldb][Windows] Fixed the test
 gdb_remote_client/TestGDBRemotePlatformFile

The tests `test_file_permissions` and `test_file_permissions_fallback` are 
disabled for Windows target. These tests use MockGDBServerResponder and do not 
depend on the real target. These tests failed in case of Windows host and Linux 
target. Disable them for Windows host too.
---
 .../gdb_remote_client/TestGDBRemotePlatformFile.py  | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
index 2be5ae3132038..9ef0954af1fe3 100644
--- 
a/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
+++ 
b/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
@@ -148,6 +148,7 @@ def vFile(self, packet):
 )
 
 @skipIfWindows
+@skipIf(hostoslist=["windows"])
 def test_file_permissions(self):
 """Test 'platform get-permissions'"""
 
@@ -168,6 +169,7 @@ def vFile(self, packet):
 )
 
 @skipIfWindows
+@skipIf(hostoslist=["windows"])
 def test_file_permissions_fallback(self):
 """Test 'platform get-permissions' fallback to fstat"""
 

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


[Lldb-commits] [lldb] [lldb][Windows] Fixed the test gdb_remote_client/TestGDBRemotePlatformFile (PR #92088)

2024-05-14 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Dmitry Vasilyev (slydiman)


Changes

The tests `test_file_permissions` and `test_file_permissions_fallback` are 
disabled for Windows target. These tests use MockGDBServerResponder and do not 
depend on the real target. These tests failed in case of Windows host and Linux 
target. Disable them for Windows host too.

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


1 Files Affected:

- (modified) 
lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py 
(+2) 


``diff
diff --git 
a/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
index 2be5ae3132038..9ef0954af1fe3 100644
--- 
a/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
+++ 
b/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
@@ -148,6 +148,7 @@ def vFile(self, packet):
 )
 
 @skipIfWindows
+@skipIf(hostoslist=["windows"])
 def test_file_permissions(self):
 """Test 'platform get-permissions'"""
 
@@ -168,6 +169,7 @@ def vFile(self, packet):
 )
 
 @skipIfWindows
+@skipIf(hostoslist=["windows"])
 def test_file_permissions_fallback(self):
 """Test 'platform get-permissions' fallback to fstat"""
 

``




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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Pavel Labath via lldb-commits

labath wrote:

Can we make this less brute force? I believe searching for the Build ID Note 
should be a completely deterministic process, without the need for heuristics. 
You start with the elf header, find the program headers, iterate to find the 
PT_NOTE segment (there could be more of them), and iterate over the notes until 
you find NT_GNU_BUILD_ID. All of these things should be in the memory (=> also 
in the core file) and within the first 4k of the mapping. There should be no 
need to search through a potentially huge file mapping just to see if it 
contains the build id.

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


[Lldb-commits] [lldb] [lldb][Windows] Fixed the test TestGdbRemoteMemoryTagging (PR #92077)

2024-05-14 Thread David Spickett via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb][Windows] Fixed the test TestGdbRemoteMemoryTagging (PR #92077)

2024-05-14 Thread David Spickett via lldb-commits

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


[Lldb-commits] [lldb] 429ce59 - [lldb][Windows] Fixed the test TestGdbRemoteMemoryTagging (#92077)

2024-05-14 Thread via lldb-commits

Author: Dmitry Vasilyev
Date: 2024-05-14T10:15:03+01:00
New Revision: 429ce59bd0a7d93ef833939d4a92b56aae103a5a

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

LOG: [lldb][Windows] Fixed the test TestGdbRemoteMemoryTagging (#92077)

Windows path is case insensitive. Tests `test_QMemTags_packets` and
`test_qMemTags_packets` will use the same build dir and conflict. Added
a suffix to resolve conflicts.

Added: 


Modified: 
lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py

Removed: 




diff  --git 
a/lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py 
b/lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
index 584de5e2ef49e..6ddd264057c3c 100644
--- 
a/lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
+++ 
b/lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
@@ -84,7 +84,7 @@ def prep_memtags_test(self):
 @skipUnlessArch("aarch64")
 @skipUnlessPlatform(["linux"])
 @skipUnlessAArch64MTELinuxCompiler
-def test_qMemTags_packets(self):
+def test_tag_read_qMemTags_packets(self):
 """Test that qMemTags packets are parsed correctly and/or rejected."""
 buf_address, page_size = self.prep_memtags_test()
 
@@ -154,7 +154,7 @@ def check_tag_write(self, body, expected):
 @skipUnlessArch("aarch64")
 @skipUnlessPlatform(["linux"])
 @skipUnlessAArch64MTELinuxCompiler
-def test_QMemTags_packets(self):
+def test_tag_write_QMemTags_packets(self):
 """Test that QMemTags packets are parsed correctly and/or rejected."""
 buf_address, page_size = self.prep_memtags_test()
 



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


[Lldb-commits] [lldb] [lldb][Windows] Enforce exec permission using Platform::Install() from Windows host (PR #91887)

2024-05-14 Thread Pavel Labath via lldb-commits

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

I like this new version, thanks for sticking with me.

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


[Lldb-commits] [lldb] [lldb][Windows] Fixed tests TestPty and TestPtyServer (PR #92090)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

https://github.com/slydiman created 
https://github.com/llvm/llvm-project/pull/92090

The tests TestPty and TestPtyServer use the Unix specific python builtin module 
termios. They are failed in case of Windows host and Linux target. Disable them 
for Windows host too.

>From b5b4b996bfa0cdba70f7935e452d6adde6b3cc15 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Tue, 14 May 2024 13:18:42 +0400
Subject: [PATCH] [lldb][Windows] Fixed tests TestPty and TestPtyServer

The tests TestPty and TestPtyServer use the Unix specific python builtin module 
termios. They are failed in case of Windows host and Linux target. Disable them 
for Windows host too.
---
 lldb/test/API/functionalities/gdb_remote_client/TestPty.py | 1 +
 lldb/test/API/tools/lldb-server/TestPtyServer.py   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/lldb/test/API/functionalities/gdb_remote_client/TestPty.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestPty.py
index 4d4dd489b294a..9e5c780a24b1b 100644
--- a/lldb/test/API/functionalities/gdb_remote_client/TestPty.py
+++ b/lldb/test/API/functionalities/gdb_remote_client/TestPty.py
@@ -6,6 +6,7 @@
 
 
 @skipIfWindows
+@skipIf(hostoslist=["windows"])
 class TestPty(GDBRemoteTestBase):
 server_socket_class = PtyServerSocket
 
diff --git a/lldb/test/API/tools/lldb-server/TestPtyServer.py 
b/lldb/test/API/tools/lldb-server/TestPtyServer.py
index aa5bd635650ac..7d91d762cb3ba 100644
--- a/lldb/test/API/tools/lldb-server/TestPtyServer.py
+++ b/lldb/test/API/tools/lldb-server/TestPtyServer.py
@@ -8,6 +8,7 @@
 
 
 @skipIfWindows
+@skipIf(hostoslist=["windows"])
 class PtyServerTestCase(gdbremote_testcase.GdbRemoteTestCaseBase):
 def setUp(self):
 super().setUp()

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


[Lldb-commits] [lldb] [lldb][Windows] Fixed tests TestPty and TestPtyServer (PR #92090)

2024-05-14 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Dmitry Vasilyev (slydiman)


Changes

The tests TestPty and TestPtyServer use the Unix specific python builtin module 
termios. They are failed in case of Windows host and Linux target. Disable them 
for Windows host too.

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


2 Files Affected:

- (modified) lldb/test/API/functionalities/gdb_remote_client/TestPty.py (+1) 
- (modified) lldb/test/API/tools/lldb-server/TestPtyServer.py (+1) 


``diff
diff --git a/lldb/test/API/functionalities/gdb_remote_client/TestPty.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestPty.py
index 4d4dd489b294a..9e5c780a24b1b 100644
--- a/lldb/test/API/functionalities/gdb_remote_client/TestPty.py
+++ b/lldb/test/API/functionalities/gdb_remote_client/TestPty.py
@@ -6,6 +6,7 @@
 
 
 @skipIfWindows
+@skipIf(hostoslist=["windows"])
 class TestPty(GDBRemoteTestBase):
 server_socket_class = PtyServerSocket
 
diff --git a/lldb/test/API/tools/lldb-server/TestPtyServer.py 
b/lldb/test/API/tools/lldb-server/TestPtyServer.py
index aa5bd635650ac..7d91d762cb3ba 100644
--- a/lldb/test/API/tools/lldb-server/TestPtyServer.py
+++ b/lldb/test/API/tools/lldb-server/TestPtyServer.py
@@ -8,6 +8,7 @@
 
 
 @skipIfWindows
+@skipIf(hostoslist=["windows"])
 class PtyServerTestCase(gdbremote_testcase.GdbRemoteTestCaseBase):
 def setUp(self):
 super().setUp()

``




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


[Lldb-commits] [lldb] [lldb] Fixed the test TestExec (PR #92082)

2024-05-14 Thread Pavel Labath via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb] Fixed the test TestDyldLaunchLinux (PR #92080)

2024-05-14 Thread Pavel Labath via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb] Fixed the test TestThreadStates when run with a remote target (PR #92086)

2024-05-14 Thread Pavel Labath via lldb-commits

labath wrote:

I'm pretty sure lldb was sending these events at some point, but that could 
have change since then. I slightly surprised that this wasn't caught before as 
that would mean noone is running these tests remotely.

Jonas, are you running lldb tests in remote configurations?

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


[Lldb-commits] [lldb] [lldb][Windows] Fixed the test gdb_remote_client/TestGDBRemotePlatformFile (PR #92088)

2024-05-14 Thread Pavel Labath via lldb-commits

labath wrote:

Given that the tests use a mock server, why is it a problem that they're 
running on a windows host? What's the actual failure? Could they be adapted so 
that they run everywhere?

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


[Lldb-commits] [lldb] [lldb][Windows] Fixed tests TestPty and TestPtyServer (PR #92090)

2024-05-14 Thread Pavel Labath via lldb-commits

labath wrote:

Maybe the `skipIfWindows` decorator can also be removed here? We haven't been 
historically very good at distinguishing windows hosts and targets (nobody 
cared until now), and from the looks of things, these tests could conceivably 
work in a linux->windows remote scenario (although they wouldn't really test 
much given that they use a mock server, so maybe slapping `skipIfRemote` would 
be reasonable as well).

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


[Lldb-commits] [lldb] 7b1b127 - [lldb][Windows] Enforce exec permission using Platform::Install() from Windows host (#91887)

2024-05-14 Thread via lldb-commits

Author: Dmitry Vasilyev
Date: 2024-05-14T13:57:37+04:00
New Revision: 7b1b1279414217ea7f2402a03dfb5a18ea5a5367

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

LOG: [lldb][Windows] Enforce exec permission using Platform::Install() from 
Windows host (#91887)

Target::Install() set 0700 permissions for the main executable file.
Platform::Install() just copies permissions from the source. But the
permission eFilePermissionsUserExecute is missing on the Windows host. A
lot of tests failed in case of Windows host and Linux target because of
this issue. There is no API to provide the exec flag. This patch set the
permission eFilePermissionsUserExecute for all files installed via
Platform::Install() from the Windows host. It fixes a lot of tests in
case of Windows host and Linux target.

Added: 


Modified: 
lldb/source/Target/Platform.cpp

Removed: 




diff  --git a/lldb/source/Target/Platform.cpp b/lldb/source/Target/Platform.cpp
index 4af4aa68ccd01..ee1f92470e162 100644
--- a/lldb/source/Target/Platform.cpp
+++ b/lldb/source/Target/Platform.cpp
@@ -1225,7 +1225,7 @@ Status Platform::PutFile(const FileSpec &source, const 
FileSpec &destination,
 
   uint32_t permissions = source_file.get()->GetPermissions(error);
   if (permissions == 0)
-permissions = lldb::eFilePermissionsFileDefault;
+permissions = lldb::eFilePermissionsUserRWX;
 
   lldb::user_id_t dest_file = OpenFile(
   destination, File::eOpenOptionCanCreate | File::eOpenOptionWriteOnly |



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


[Lldb-commits] [lldb] [lldb][Windows] Enforce exec permission using Platform::Install() from Windows host (PR #91887)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

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


[Lldb-commits] [lldb] ac42f76 - [lldb] Fixed the test TestDyldLaunchLinux (#92080)

2024-05-14 Thread via lldb-commits

Author: Dmitry Vasilyev
Date: 2024-05-14T14:00:16+04:00
New Revision: ac42f7689d741feda2badc438101e7952db048f3

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

LOG: [lldb] Fixed the test TestDyldLaunchLinux (#92080)

Install a.out and libsignal_file.so to the remote target if necessary.

Added: 


Modified: 
lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py 
b/lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py
index 26360c20db1e2..c4eba023ea722 100644
--- a/lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py
+++ b/lldb/test/API/functionalities/dyld-launch-linux/TestDyldLaunchLinux.py
@@ -7,6 +7,7 @@
 
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
 
 
 class TestLinux64LaunchingViaDynamicLoader(TestBase):
@@ -39,11 +40,16 @@ def test(self):
 breakpoint_shared_library = target.BreakpointCreateBySourceRegex(
 "get_signal_crash", lldb.SBFileSpec("signal_file.cpp")
 )
+inferior_exe_path = lldbutil.install_to_target(
+self, self.getBuildArtifact("a.out")
+)
+lldbutil.install_to_target(self, 
self.getBuildArtifact("libsignal_file.so"))
+
 launch_info = lldb.SBLaunchInfo(
 [
 "--library-path",
 self.get_process_working_directory(),
-self.getBuildArtifact("a.out"),
+inferior_exe_path,
 ]
 )
 launch_info.SetWorkingDirectory(self.get_process_working_directory())



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


[Lldb-commits] [lldb] [lldb] Fixed the test TestDyldLaunchLinux (PR #92080)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

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


[Lldb-commits] [lldb] f658d84 - [lldb] Fixed the test TestExec (#92082)

2024-05-14 Thread via lldb-commits

Author: Dmitry Vasilyev
Date: 2024-05-14T14:02:31+04:00
New Revision: f658d84e01bcdd49e27dc9ef80e1a6cc5f9417fe

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

LOG: [lldb] Fixed the test TestExec (#92082)

Install `secondprog` to the remote target if necessary.

Added: 


Modified: 
lldb/test/API/functionalities/exec/TestExec.py

Removed: 




diff  --git a/lldb/test/API/functionalities/exec/TestExec.py 
b/lldb/test/API/functionalities/exec/TestExec.py
index aab1f5c9455f5..968b879c4cd44 100644
--- a/lldb/test/API/functionalities/exec/TestExec.py
+++ b/lldb/test/API/functionalities/exec/TestExec.py
@@ -45,6 +45,8 @@ def do_test(self, skip_exec):
 # Create the target
 target = self.dbg.CreateTarget(exe)
 
+lldbutil.install_to_target(self, secondprog)
+
 # Create any breakpoints we need
 breakpoint1 = target.BreakpointCreateBySourceRegex(
 "Set breakpoint 1 here", lldb.SBFileSpec("main.c", False)
@@ -143,6 +145,8 @@ def test_correct_thread_plan_state_before_exec(self):
 exe = self.getBuildArtifact("a.out")
 target = self.dbg.CreateTarget(exe)
 
+lldbutil.install_to_target(self, self.getBuildArtifact("secondprog"))
+
 (target, process, thread, breakpoint1) = 
lldbutil.run_to_source_breakpoint(
 self, "Set breakpoint 1 here", lldb.SBFileSpec("main.c", False)
 )



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


[Lldb-commits] [lldb] [lldb] Fixed the test TestExec (PR #92082)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

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


[Lldb-commits] [lldb] [lldb/aarch64] Allow unaligned PC addresses below a trap handler (PR #92093)

2024-05-14 Thread Pavel Labath via lldb-commits

https://github.com/labath created 
https://github.com/llvm/llvm-project/pull/92093

The stack validation heuristic is counter-productive in this case, as the 
unaligned address is most likely the thing that caused the signal in the first 
place.

>From 391a4129d3da4c4730e50d6ebca23a3c36c3b462 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Tue, 14 May 2024 01:27:45 -0700
Subject: [PATCH] [lldb/aarch64] Allow unaligned PC addresses below a trap
 handler

The stack validation heuristic is counter-productive in this case, as
the unaligned address is most likely the thing that caused the signal in
the first place.
---
 lldb/source/Target/UnwindLLDB.cpp |  7 -
 .../Shell/Unwind/Inputs/unaligned-pc-sigbus.c | 21 +++
 .../Shell/Unwind/unaligned-pc-sigbus.test | 26 +++
 3 files changed, 53 insertions(+), 1 deletion(-)
 create mode 100644 lldb/test/Shell/Unwind/Inputs/unaligned-pc-sigbus.c
 create mode 100644 lldb/test/Shell/Unwind/unaligned-pc-sigbus.test

diff --git a/lldb/source/Target/UnwindLLDB.cpp 
b/lldb/source/Target/UnwindLLDB.cpp
index 1d8bf2f88ae67..f43e940492b09 100644
--- a/lldb/source/Target/UnwindLLDB.cpp
+++ b/lldb/source/Target/UnwindLLDB.cpp
@@ -261,7 +261,12 @@ UnwindLLDB::CursorSP UnwindLLDB::GetOneMoreFrame(ABI *abi) 
{
   cur_idx < 100 ? cur_idx : 100, "", cur_idx);
 return nullptr;
   }
-  if (abi && !abi->CodeAddressIsValid(cursor_sp->start_pc)) {
+
+  // Invalid code addresses should not appear on the stack *unless* we're
+  // directly below a trap handler frame (in this case, the invalid address is
+  // likely the cause of the trap).
+  if (abi && !abi->CodeAddressIsValid(cursor_sp->start_pc) &&
+  !prev_frame->reg_ctx_lldb_sp->IsTrapHandlerFrame()) {
 // If the RegisterContextUnwind has a fallback UnwindPlan, it will switch 
to
 // that and return true.  Subsequent calls to TryFallbackUnwindPlan() will
 // return false.
diff --git a/lldb/test/Shell/Unwind/Inputs/unaligned-pc-sigbus.c 
b/lldb/test/Shell/Unwind/Inputs/unaligned-pc-sigbus.c
new file mode 100644
index 0..b4818de3b7fb3
--- /dev/null
+++ b/lldb/test/Shell/Unwind/Inputs/unaligned-pc-sigbus.c
@@ -0,0 +1,21 @@
+#include 
+#include 
+#include 
+
+void sigbus_handler(int signo) { _exit(47); }
+
+int target_function() { return 47; }
+
+int main() {
+  signal(SIGBUS, sigbus_handler);
+
+  // Generate a SIGBUS by deliverately calling through an unaligned function
+  // pointer.
+  union {
+int (*t)();
+uintptr_t p;
+  } u;
+  u.t = target_function;
+  u.p |= 1;
+  return u.t();
+}
diff --git a/lldb/test/Shell/Unwind/unaligned-pc-sigbus.test 
b/lldb/test/Shell/Unwind/unaligned-pc-sigbus.test
new file mode 100644
index 0..f74ec1e858551
--- /dev/null
+++ b/lldb/test/Shell/Unwind/unaligned-pc-sigbus.test
@@ -0,0 +1,26 @@
+# REQUIRES: (target-aarch64 || target-arm) && native
+# UNSUPPORTED: system-windows
+
+# RUN: %clang_host %S/Inputs/unaligned-pc-sigbus.c -o %t
+# RUN: %lldb -s %s -o exit %t | FileCheck %s
+
+breakpoint set -n sigbus_handler
+# CHECK: Breakpoint 1: where = {{.*}}`sigbus_handler
+
+run
+# CHECK: thread #1, {{.*}} stop reason = signal SIGBUS
+
+thread backtrace
+# CHECK: (lldb) thread backtrace
+# CHECK: frame #0: [[TARGET:0x[0-9a-fA-F]*]] {{.*}}`target_function
+
+continue
+# CHECK: thread #1, {{.*}} stop reason = breakpoint 1
+
+
+thread backtrace
+# CHECK: (lldb) thread backtrace
+# CHECK: frame #0: {{.*}}`sigbus_handler
+# Unknown number of signal trampoline frames
+# CHECK: frame #{{[0-9]+}}: [[TARGET]] {{.*}}`target_function
+

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


[Lldb-commits] [lldb] [lldb/aarch64] Allow unaligned PC addresses below a trap handler (PR #92093)

2024-05-14 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Pavel Labath (labath)


Changes

The stack validation heuristic is counter-productive in this case, as the 
unaligned address is most likely the thing that caused the signal in the first 
place.

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


3 Files Affected:

- (modified) lldb/source/Target/UnwindLLDB.cpp (+6-1) 
- (added) lldb/test/Shell/Unwind/Inputs/unaligned-pc-sigbus.c (+21) 
- (added) lldb/test/Shell/Unwind/unaligned-pc-sigbus.test (+26) 


``diff
diff --git a/lldb/source/Target/UnwindLLDB.cpp 
b/lldb/source/Target/UnwindLLDB.cpp
index 1d8bf2f88ae67..f43e940492b09 100644
--- a/lldb/source/Target/UnwindLLDB.cpp
+++ b/lldb/source/Target/UnwindLLDB.cpp
@@ -261,7 +261,12 @@ UnwindLLDB::CursorSP UnwindLLDB::GetOneMoreFrame(ABI *abi) 
{
   cur_idx < 100 ? cur_idx : 100, "", cur_idx);
 return nullptr;
   }
-  if (abi && !abi->CodeAddressIsValid(cursor_sp->start_pc)) {
+
+  // Invalid code addresses should not appear on the stack *unless* we're
+  // directly below a trap handler frame (in this case, the invalid address is
+  // likely the cause of the trap).
+  if (abi && !abi->CodeAddressIsValid(cursor_sp->start_pc) &&
+  !prev_frame->reg_ctx_lldb_sp->IsTrapHandlerFrame()) {
 // If the RegisterContextUnwind has a fallback UnwindPlan, it will switch 
to
 // that and return true.  Subsequent calls to TryFallbackUnwindPlan() will
 // return false.
diff --git a/lldb/test/Shell/Unwind/Inputs/unaligned-pc-sigbus.c 
b/lldb/test/Shell/Unwind/Inputs/unaligned-pc-sigbus.c
new file mode 100644
index 0..b4818de3b7fb3
--- /dev/null
+++ b/lldb/test/Shell/Unwind/Inputs/unaligned-pc-sigbus.c
@@ -0,0 +1,21 @@
+#include 
+#include 
+#include 
+
+void sigbus_handler(int signo) { _exit(47); }
+
+int target_function() { return 47; }
+
+int main() {
+  signal(SIGBUS, sigbus_handler);
+
+  // Generate a SIGBUS by deliverately calling through an unaligned function
+  // pointer.
+  union {
+int (*t)();
+uintptr_t p;
+  } u;
+  u.t = target_function;
+  u.p |= 1;
+  return u.t();
+}
diff --git a/lldb/test/Shell/Unwind/unaligned-pc-sigbus.test 
b/lldb/test/Shell/Unwind/unaligned-pc-sigbus.test
new file mode 100644
index 0..f74ec1e858551
--- /dev/null
+++ b/lldb/test/Shell/Unwind/unaligned-pc-sigbus.test
@@ -0,0 +1,26 @@
+# REQUIRES: (target-aarch64 || target-arm) && native
+# UNSUPPORTED: system-windows
+
+# RUN: %clang_host %S/Inputs/unaligned-pc-sigbus.c -o %t
+# RUN: %lldb -s %s -o exit %t | FileCheck %s
+
+breakpoint set -n sigbus_handler
+# CHECK: Breakpoint 1: where = {{.*}}`sigbus_handler
+
+run
+# CHECK: thread #1, {{.*}} stop reason = signal SIGBUS
+
+thread backtrace
+# CHECK: (lldb) thread backtrace
+# CHECK: frame #0: [[TARGET:0x[0-9a-fA-F]*]] {{.*}}`target_function
+
+continue
+# CHECK: thread #1, {{.*}} stop reason = breakpoint 1
+
+
+thread backtrace
+# CHECK: (lldb) thread backtrace
+# CHECK: frame #0: {{.*}}`sigbus_handler
+# Unknown number of signal trampoline frames
+# CHECK: frame #{{[0-9]+}}: [[TARGET]] {{.*}}`target_function
+

``




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


[Lldb-commits] [lldb] [lldb/aarch64] Allow unaligned PC addresses below a trap handler (PR #92093)

2024-05-14 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,26 @@
+# REQUIRES: (target-aarch64 || target-arm) && native
+# UNSUPPORTED: system-windows
+
+# RUN: %clang_host %S/Inputs/unaligned-pc-sigbus.c -o %t
+# RUN: %lldb -s %s -o exit %t | FileCheck %s
+
+breakpoint set -n sigbus_handler
+# CHECK: Breakpoint 1: where = {{.*}}`sigbus_handler
+
+run
+# CHECK: thread #1, {{.*}} stop reason = signal SIGBUS

labath wrote:

I'm guessing I'll also need to forward some mach exception to make this work. 
Would that be EXC_BAD_ACCESS?

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


[Lldb-commits] [lldb] [lldb/aarch64] Allow unaligned PC addresses below a trap handler (PR #92093)

2024-05-14 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,26 @@
+# REQUIRES: (target-aarch64 || target-arm) && native
+# UNSUPPORTED: system-windows
+
+# RUN: %clang_host %S/Inputs/unaligned-pc-sigbus.c -o %t
+# RUN: %lldb -s %s -o exit %t | FileCheck %s
+
+breakpoint set -n sigbus_handler
+# CHECK: Breakpoint 1: where = {{.*}}`sigbus_handler
+
+run
+# CHECK: thread #1, {{.*}} stop reason = signal SIGBUS
+
+thread backtrace
+# CHECK: (lldb) thread backtrace
+# CHECK: frame #0: [[TARGET:0x[0-9a-fA-F]*]] {{.*}}`target_function
+
+continue
+# CHECK: thread #1, {{.*}} stop reason = breakpoint 1
+
+
+thread backtrace
+# CHECK: (lldb) thread backtrace
+# CHECK: frame #0: {{.*}}`sigbus_handler
+# Unknown number of signal trampoline frames
+# CHECK: frame #{{[0-9]+}}: [[TARGET]] {{.*}}`target_function

labath wrote:

This will currently not unwind past the `target_function` without the fix in 
#91321

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


[Lldb-commits] [lldb] [lldb-dap] Updating VariableDescription to use GetDescription() as a fallback. (PR #77026)

2024-05-14 Thread Pavel Labath via lldb-commits

labath wrote:

I'm currently optimizing our data formatters for some fairly complex data 
structures, and I've ran into something I don't understand. My DAP packet 
sequence for a hover request consists of two (mostly redundant) packets:

```
--> 
Content-Length: 114

{
  "arguments": {
"context": "hover",
"expression": "v",
"frameId": 524288
  },
  "command": "evaluate",
  "seq": 21,
  "type": "request"
}
<-- 
Content-Length: 1830

{
  "body": {
"result": "(std::vector) v = size=121 {\n  [0] = 1\n  [1] = 2\n  [2] = 
3\n  [3] = 4\n  [4] = 5\n  [5] = 6\n  [6] = 7\n  [7] = 77\n  [8] = 3\n  [9] = 
33\n  [10] = 54\n  [11] = 5\n  [12] = 53\n  [13] = 523\n  [14] = 532\n  [15] = 
53\n  [16] = 3535\n  [17] = 53\n  [18] = 2235\n  [19] = 352\n  [20] = 35\n  
[21] = 352\n  [22] = 532\n  [23] = 532\n  [24] = 53\n  [25] = 35523\n  [26] = 
523\n  [27] = 532\n  [28] = 523\n  [29] = 523\n  [30] = 523\n  [31] = 523\n  
[32] = 235\n  [33] = 523\n  [34] = 532\n  [35] = 532\n  [36] = 523\n  [37] = 
523\n  [38] = 53\n  [39] = 312\n  [40] = 5\n  [41] = 346\n  [42] = 4256\n  [43] 
= 346\n  [44] = 234\n  [45] = 632\n  [46] = 523\n  [47] = 6\n  [48] = 246\n  
[49] = 54\n  [50] = 672\n  [51] = 67\n  [52] = 2457\n  [53] = 234\n  [54] = 
7524\n  [55] = 7\n  [56] = 4376\n  [57] = 23467\n  [58] = 432\n  [59] = 6\n  
[60] = 2347\n  [61] = 5435\n  [62] = 2\n  [63] = 346\n  [64] = 4536\n  [65] = 
34\n  [66] = 53\n  [67] = 324\n  [68] = 645\n  [69] = 645\n  [70] = 456\n  [71] 
= 75\n  [72] = 343\n  [73] = 3\n  [74] = 4\n  [75] = 654\n  [76] = 3545\n  [77] 
= 5\n  [78] = 4\n  [79] = 435\n  [80] = 5\n  [81] = 345\n  [82] = 54\n  [83] = 
435\n  [84] = 43\n  [85] = 245\n  [86] = 54\n  [87] = 32\n  [88] = 4565\n  [89] 
= 65\n  [90] = 54\n  [91] = 43\n  [92] = 54\n  [93] = 535\n  [94] = 3\n  [95] = 
4\n  [96] = 5\n  [97] = 5\n  [98] = 65\n  [99] = 1342\n  [100] = 43657\n  [101] 
= 67856\n  [102] = 523\n  [103] = 4\n  [104] = 534\n  [105] = 576\n  [106] = 
57\n  [107] = 46\n  [108] = 24\n  [109] = 6\n  [110] = 568\n  [111] = 5658\n  
[112] = 76\n  [113] = 42\n  [114] = 634\n  [115] = 8\n  [116] = 54657\n  [117] 
= 6\n  [118] = 4\n  [119] = 8356\n  [120] = 75\n}",
"type": "std::vector",
"variablesReference": 8
  },
  "command": "evaluate",
  "request_seq": 21,
  "seq": 0,
  "success": true,
  "type": "response"
}
--> 
Content-Length: 86

{
  "arguments": {
"variablesReference": 8
  },
  "command": "variables",
  "seq": 22,
  "type": "request"
}
<-- 
Content-Length: 17549

{
  "body": {
"variables": [
  {
"$__lldb_extensions": {
  "value": "1"
},
"evaluateName": "v._M_impl._M_start->[0]",
"name": "[0]",
"type": "int",
"value": "1",
"variablesReference": 0
  },
// ...
  {
"$__lldb_extensions": {
  "value": "75"
},
"evaluateName": "v._M_impl._M_start->[120]",
"name": "[120]",
"type": "int",
"value": "75",
"variablesReference": 0
  }
]
  },
  "command": "variables",
  "request_seq": 22,
  "seq": 0,
  "success": true,
  "type": "response"
}
```

The first response contains the contents of the formatted variable (a vector, 
in this example) as a string, while the second one contains the same data in a 
structured form. Looking at the history, I've found this PR, which seems to 
indicate that the first packet is necessary in order to provide the contents of 
data structure in the hover window. However, that does not appear to match what 
I'm seeing:

![sc-0](https://github.com/llvm/llvm-project/assets/3129331/9305bf38-314f-46a3-9c79-b3b08beadca1)

>From what I can tell by this screenshot, the only part that VSCode uses from 
>the first response is the first line (which it uses as the "summary" of the 
>value, while the rest of the data (the vector contents) comes from the second 
>response.

The first response is problematic for me, because that output can contain a lot 
more information (if the vector contained structures rather than ints, those 
structures would get expanded recursively) than what's displayed on the screen, 
which makes the popups slower than necessary. From what I'm seeing, it would be 
ideal to remove the expansion in the first response completely (which would 
essentially amount to reverting this PR), given that the information is already 
contained in the second one. However, I am assuming there is a reason for why 
that code exists -- but then I don't understand why does my experience (and 
screenshots) differ so much from the screenshots on this PR. Could something 
have changed  (over the last 4 months)  in how VSCode behaves that would mean 
this PR is not necessary?

Can anyone shed any light on this?

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-14 Thread Miro Bucko via lldb-commits


@@ -242,6 +244,12 @@ class AddressRange {
   lldb::addr_t m_byte_size = 0; ///< The size in bytes of this address range.
 };
 
+// Forward-declarable wrapper.
+class AddressRanges : public std::vector {
+public:
+  using std::vector::vector;
+};

mbucko wrote:

I followed the same convention as here:
https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Target/MemoryRegionInfo.h#L172

Do you have a preference?

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-14 Thread Miro Bucko via lldb-commits

mbucko wrote:

> I forgot to ask, what is the motivation behind this change? Is there 
> something you can't do with the SBAPI right now or that is better expressed 
> with SBAddressRange and SBAddressRangeList?

Yes, I want to add the following API:

lldb::SBError SBProcess::FindInMemory(const SBAddressRangeList &ranges, const 
void *buf, uint64_t size, SBAddressRangeList &matches, size_t alignment);

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


[Lldb-commits] [lldb] [lldb] Document some more packets (PR #92124)

2024-05-14 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett created 
https://github.com/llvm/llvm-project/pull/92124

Comparing a bit of the mock GDB server code to what was in the document I found 
these:
* QLaunchArch
* qSpeedTest
* qSymbol

qSymbol is the most mysterious but it did have some examples in a comment so 
I've adapted that.

>From 0da56876f1d421c14b7af493da826e49ed272e6f Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Tue, 14 May 2024 10:47:33 +0100
Subject: [PATCH] [lldb] Document some more packets

Comparing a bit of the mock GDB server code to what was in the
document I found these.

qSymbol is the most mysterious but it did have some examples
in a comment so I've adapted that.
---
 lldb/docs/resources/lldbgdbremote.md | 87 
 1 file changed, 87 insertions(+)

diff --git a/lldb/docs/resources/lldbgdbremote.md 
b/lldb/docs/resources/lldbgdbremote.md
index 1467723fb79dc..7076a75032dae 100644
--- a/lldb/docs/resources/lldbgdbremote.md
+++ b/lldb/docs/resources/lldbgdbremote.md
@@ -867,6 +867,22 @@ error replies.
 **Priority To Implement:** Low. Only needed if the remote target wants to
 provide strings that are human readable along with an error code.
 
+## QLaunchArch
+
+Set the architecture to use when launching a process for hosts that can run
+multiple architecture slices that are contained in a single universal program
+file.
+
+```
+send packet: $QLaunchArch:
+```
+
+The response is `OK` if the value in `` was recognised as valid
+and will be used for the next launch request. `E63` if not.
+
+**Priority To Implement:** Only required for hosts that support program files
+that contain code for multiple architectures.
+
 ## QListThreadsInStopReply
 
 Enable the `threads:` and `thread-pcs:` data in the question-mark packet
@@ -1883,6 +1899,77 @@ some platforms know, or can find out where this 
information is.
 Low if you have a debug target where all object and symbol files
 contain static load addresses.
 
+## qSpeedTest
+
+Test the maximum speed at which packets can be sent and received.
+
+```
+send packet: qSpeedTest:response_size:;
+read packet: data:
+```
+
+`` is a hex encoded unsigned number up to 64 bits in size.
+The remote will respond with `data:` followed by a block of `a` characters
+whose size should match ``, if the connection is stable.
+
+If there is an error parsing the packet, the response is `E79`.
+
+This packet is used by LLDB to discover how reliable the connection is by
+varying the amount of data requested by `` and checking whether
+the expected amount and values were received.
+
+**Priority to Implemment:** Not required for debugging on the same host, 
otherwise
+low unless you know your connection quality is variable.
+
+## qSymbol
+
+Notify the remote that LLDB is ready to do symbol lookups on behalf of the
+debug server. The response is the symbol name the debug server wants to know 
the
+value of, or `OK` if the debug server does not need to know any more symbol 
values.
+
+The exchange always begins with:
+```
+send packet: qSymbol::
+```
+
+The `::` are delimiters for fields that may be filled in future responses. 
These
+delimiters must be included even in the first packet sent.
+
+The debug server can reply one of two ways. If it doesn't need any symbol 
values:
+```
+read packet: OK
+```
+
+If it does need a symbol value, it includes the ASCII hex encoded name of the
+symbol:
+```
+read packet: qSymbol:6578616D706C65
+```
+
+This should be looked up by LLDB then sent back to the server. Include the name
+again, with the vaue as a hex number:
+```
+read packet: qSymbol:6578616D706C65:CAFEF00D
+```
+
+If LLDB cannot find the value, it should respond with only the name. Note that
+the second `:` is not included here, whereas it is in the initial packet.
+```
+read packet: qSymbol:6578616D706C65
+```
+
+If LLDB is asked for any symbols that it cannot find, it should send the
+initial `qSymbol::` again at any point where new libraries are loaded. In case
+the symbol can now be resolved.
+
+If the debug server has requested all the symbols it wants, the final response
+will be `OK` (whether they were all found or not).
+
+If LLDB did find all the symbols and recieves an `OK` it does not need to send
+`qSymbol::` again during the debug session.
+
+**Priority To Implement:** Low, this is rarely used.
+
 ## qThreadStopInfo\
 
 Get information about why a thread, whose ID is ``, is stopped.

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


[Lldb-commits] [lldb] [lldb] Document some more packets (PR #92124)

2024-05-14 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)


Changes

Comparing a bit of the mock GDB server code to what was in the document I found 
these:
* QLaunchArch
* qSpeedTest
* qSymbol

qSymbol is the most mysterious but it did have some examples in a comment so 
I've adapted that.

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


1 Files Affected:

- (modified) lldb/docs/resources/lldbgdbremote.md (+87) 


``diff
diff --git a/lldb/docs/resources/lldbgdbremote.md 
b/lldb/docs/resources/lldbgdbremote.md
index 1467723fb79dc..7076a75032dae 100644
--- a/lldb/docs/resources/lldbgdbremote.md
+++ b/lldb/docs/resources/lldbgdbremote.md
@@ -867,6 +867,22 @@ error replies.
 **Priority To Implement:** Low. Only needed if the remote target wants to
 provide strings that are human readable along with an error code.
 
+## QLaunchArch
+
+Set the architecture to use when launching a process for hosts that can run
+multiple architecture slices that are contained in a single universal program
+file.
+
+```
+send packet: $QLaunchArch:
+```
+
+The response is `OK` if the value in `` was recognised as valid
+and will be used for the next launch request. `E63` if not.
+
+**Priority To Implement:** Only required for hosts that support program files
+that contain code for multiple architectures.
+
 ## QListThreadsInStopReply
 
 Enable the `threads:` and `thread-pcs:` data in the question-mark packet
@@ -1883,6 +1899,77 @@ some platforms know, or can find out where this 
information is.
 Low if you have a debug target where all object and symbol files
 contain static load addresses.
 
+## qSpeedTest
+
+Test the maximum speed at which packets can be sent and received.
+
+```
+send packet: qSpeedTest:response_size:;
+read packet: data:
+```
+
+`` is a hex encoded unsigned number up to 64 bits in size.
+The remote will respond with `data:` followed by a block of `a` characters
+whose size should match ``, if the connection is stable.
+
+If there is an error parsing the packet, the response is `E79`.
+
+This packet is used by LLDB to discover how reliable the connection is by
+varying the amount of data requested by `` and checking whether
+the expected amount and values were received.
+
+**Priority to Implemment:** Not required for debugging on the same host, 
otherwise
+low unless you know your connection quality is variable.
+
+## qSymbol
+
+Notify the remote that LLDB is ready to do symbol lookups on behalf of the
+debug server. The response is the symbol name the debug server wants to know 
the
+value of, or `OK` if the debug server does not need to know any more symbol 
values.
+
+The exchange always begins with:
+```
+send packet: qSymbol::
+```
+
+The `::` are delimiters for fields that may be filled in future responses. 
These
+delimiters must be included even in the first packet sent.
+
+The debug server can reply one of two ways. If it doesn't need any symbol 
values:
+```
+read packet: OK
+```
+
+If it does need a symbol value, it includes the ASCII hex encoded name of the
+symbol:
+```
+read packet: qSymbol:6578616D706C65
+```
+
+This should be looked up by LLDB then sent back to the server. Include the name
+again, with the vaue as a hex number:
+```
+read packet: qSymbol:6578616D706C65:CAFEF00D
+```
+
+If LLDB cannot find the value, it should respond with only the name. Note that
+the second `:` is not included here, whereas it is in the initial packet.
+```
+read packet: qSymbol:6578616D706C65
+```
+
+If LLDB is asked for any symbols that it cannot find, it should send the
+initial `qSymbol::` again at any point where new libraries are loaded. In case
+the symbol can now be resolved.
+
+If the debug server has requested all the symbols it wants, the final response
+will be `OK` (whether they were all found or not).
+
+If LLDB did find all the symbols and recieves an `OK` it does not need to send
+`qSymbol::` again during the debug session.
+
+**Priority To Implement:** Low, this is rarely used.
+
 ## qThreadStopInfo\
 
 Get information about why a thread, whose ID is ``, is stopped.

``




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


[Lldb-commits] [lldb] [lldb/aarch64] Fix unwinding when signal interrupts a leaf function (PR #91321)

2024-05-14 Thread Pavel Labath via lldb-commits

labath wrote:

> Ah, so the problem here is that we're missing the eh_frame instructions for 
> _sigtramp on arm64 with macOS 14. `signal_generating_add` is a frameless 
> function (a great stress test in this instance), and _sigtramp is called with 
> enough of a faked-up stack that a stack walk will find the last frame that 
> set up a stack frame before faulting, main in this case. But we skip 
> `signal_generating_add`. We're going to need to skip this test on macOS for 
> now, and I'll dig in to where the eh_frame instructions went and see about 
> getting them re-added, but it may take a while to get that into builds and on 
> to the bots.

Makes sense. I'll leave the test XFAILed then (once the windows issue is sorted 
out). Thanks for looking into this, I'm glad the test proved to be useful.

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


[Lldb-commits] [lldb] [lldb] Document some more packets (PR #92124)

2024-05-14 Thread Jonas Devlieghere via lldb-commits

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

LGTM. TILL about `qSpeedTest`. 

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


[Lldb-commits] [lldb] [lldb] Document some more packets (PR #92124)

2024-05-14 Thread Jonas Devlieghere via lldb-commits

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


[Lldb-commits] [clang] [lldb] [llvm] [openmp] [polly] fix(python): fix comparison to True/False (PR #91858)

2024-05-14 Thread Jonas Devlieghere via lldb-commits

JDevlieghere wrote:

> If this is split out from the other larger PR, should there be `clang/` 
> changes in here?

+1, please unstage the `clang` and `openmp` changes. 

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


[Lldb-commits] [lldb] [lldb] Fixed the test TestThreadStates when run with a remote target (PR #92086)

2024-05-14 Thread Jonas Devlieghere via lldb-commits

JDevlieghere wrote:

> I'm pretty sure lldb was sending these events at some point, but that could 
> have change since then. I slightly surprised that this wasn't caught before 
> as that would mean noone is running these tests remotely.
> 
> Jonas, are you running lldb tests in remote configurations?

Yup, I am. Looks like all these tests are marked as `@skipIfDarwin` so that 
would explain why it wasn't caught before. 

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


[Lldb-commits] [lldb] [lldb] Fixed the test TestThreadStates when run with a remote target (PR #92086)

2024-05-14 Thread Pavel Labath via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb] Fixed the test TestThreadStates when run with a remote target (PR #92086)

2024-05-14 Thread Pavel Labath via lldb-commits

labath wrote:

Ah, that explains it. Ship it then.

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


[Lldb-commits] [lldb] [lldb-dap] Correctly detect alias commands with arguments in repl (PR #92137)

2024-05-14 Thread Pavel Labath via lldb-commits

https://github.com/labath created 
https://github.com/llvm/llvm-project/pull/92137

ResolveCommand will not succeed for an alias command with arguments, and the 
code wasn't providing any. Replace that with explicit query(ies) for the 
existence of a command with the given name.

>From 6d4df820e84e84a871a6d24a196608047470d7d7 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Tue, 14 May 2024 15:32:15 +
Subject: [PATCH] [lldb-dap] Correctly detect alias commands with arguments in
 repl

ResolveCommand will not succeed for an alias command with arguments, and
the code wasn't providing any. Replace that with explicit query(ies) for
the existence of a command with the given name.
---
 .../API/tools/lldb-dap/repl-mode/Makefile |  3 +
 .../repl-mode/TestDAP_repl_mode_detection.py  | 56 +++
 .../API/tools/lldb-dap/repl-mode/main.cpp | 15 +
 lldb/tools/lldb-dap/DAP.cpp   |  8 ++-
 4 files changed, 79 insertions(+), 3 deletions(-)
 create mode 100644 lldb/test/API/tools/lldb-dap/repl-mode/Makefile
 create mode 100644 
lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py
 create mode 100644 lldb/test/API/tools/lldb-dap/repl-mode/main.cpp

diff --git a/lldb/test/API/tools/lldb-dap/repl-mode/Makefile 
b/lldb/test/API/tools/lldb-dap/repl-mode/Makefile
new file mode 100644
index 0..8b20bcb05
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/repl-mode/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules
diff --git 
a/lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py 
b/lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py
new file mode 100644
index 0..8beecac26160e
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py
@@ -0,0 +1,56 @@
+"""
+Test lldb-dap repl mode detection
+"""
+
+import lldbdap_testcase
+import dap_server
+from lldbsuite.test import lldbutil
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TestDAP_repl_mode_detection(lldbdap_testcase.DAPTestCaseBase):
+
+def assertEvaluate(self, expression, regex):
+self.assertRegex(
+self.dap_server.request_evaluate(expression, 
context="repl")["body"][
+"result"
+],
+regex,
+)
+
+def test_completions(self):
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+
+source = "main.cpp"
+breakpoint1_line = line_number(source, "// breakpoint 1")
+breakpoint2_line = line_number(source, "// breakpoint 2")
+
+self.set_source_breakpoints(source, [breakpoint1_line, 
breakpoint2_line])
+
+self.assertEvaluate(
+"`command regex user_command s/^$/platform/", r"\(lldb\) command 
regex"
+)
+self.assertEvaluate(
+"`command alias alias_command platform", r"\(lldb\) command alias"
+)
+self.assertEvaluate(
+"`command alias alias_command_with_arg platform select --sysroot 
%1 remote-linux",
+r"\(lldb\) command alias",
+)
+
+self.continue_to_next_stop()
+self.assertEvaluate("user_command", "474747")
+self.assertEvaluate("alias_command", "474747")
+self.assertEvaluate("alias_command_with_arg", "474747")
+self.assertEvaluate("platform", "474747")
+
+self.continue_to_next_stop()
+platform_help_needle = "Commands to manage and create platforms"
+self.assertEvaluate("user_command", platform_help_needle)
+self.assertEvaluate("alias_command", platform_help_needle)
+self.assertEvaluate(
+"alias_command_with_arg " + self.getBuildDir(), "Platform: 
remote-linux"
+)
+self.assertEvaluate("platform", platform_help_needle)
diff --git a/lldb/test/API/tools/lldb-dap/repl-mode/main.cpp 
b/lldb/test/API/tools/lldb-dap/repl-mode/main.cpp
new file mode 100644
index 0..52561d3471abf
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/repl-mode/main.cpp
@@ -0,0 +1,15 @@
+void noop() {}
+
+void fun() {
+  int user_command = 474747;
+  int alias_command = 474747;
+  int alias_command_with_arg = 474747;
+  int platform = 474747; // built-in command
+  noop();// breakpoint 1
+}
+
+int main() {
+  fun();
+  noop(); // breakpoint 2
+  return 0;
+}
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index 55ff1493c1011..c7eb3db4304a9 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -14,6 +14,7 @@
 
 #include "DAP.h"
 #include "LLDBUtils.h"
+#include "lldb/API/SBCommandInterpreter.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/FormatVariadic.h"
 
@@ -405,9 +406,10 @@ ExpressionContext 
DAP::DetectExpressionContext(lldb::SBFrame frame,
 std::pair token =
 llvm::getToken(expression);
 std::string term = token.first.str();
-lldb::SBCommandReturnO

[Lldb-commits] [lldb] [lldb-dap] Correctly detect alias commands with arguments in repl (PR #92137)

2024-05-14 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Pavel Labath (labath)


Changes

ResolveCommand will not succeed for an alias command with arguments, and the 
code wasn't providing any. Replace that with explicit query(ies) for the 
existence of a command with the given name.

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


4 Files Affected:

- (added) lldb/test/API/tools/lldb-dap/repl-mode/Makefile (+3) 
- (added) lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py 
(+56) 
- (added) lldb/test/API/tools/lldb-dap/repl-mode/main.cpp (+15) 
- (modified) lldb/tools/lldb-dap/DAP.cpp (+5-3) 


``diff
diff --git a/lldb/test/API/tools/lldb-dap/repl-mode/Makefile 
b/lldb/test/API/tools/lldb-dap/repl-mode/Makefile
new file mode 100644
index 0..8b20bcb05
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/repl-mode/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules
diff --git 
a/lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py 
b/lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py
new file mode 100644
index 0..8beecac26160e
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py
@@ -0,0 +1,56 @@
+"""
+Test lldb-dap repl mode detection
+"""
+
+import lldbdap_testcase
+import dap_server
+from lldbsuite.test import lldbutil
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TestDAP_repl_mode_detection(lldbdap_testcase.DAPTestCaseBase):
+
+def assertEvaluate(self, expression, regex):
+self.assertRegex(
+self.dap_server.request_evaluate(expression, 
context="repl")["body"][
+"result"
+],
+regex,
+)
+
+def test_completions(self):
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+
+source = "main.cpp"
+breakpoint1_line = line_number(source, "// breakpoint 1")
+breakpoint2_line = line_number(source, "// breakpoint 2")
+
+self.set_source_breakpoints(source, [breakpoint1_line, 
breakpoint2_line])
+
+self.assertEvaluate(
+"`command regex user_command s/^$/platform/", r"\(lldb\) command 
regex"
+)
+self.assertEvaluate(
+"`command alias alias_command platform", r"\(lldb\) command alias"
+)
+self.assertEvaluate(
+"`command alias alias_command_with_arg platform select --sysroot 
%1 remote-linux",
+r"\(lldb\) command alias",
+)
+
+self.continue_to_next_stop()
+self.assertEvaluate("user_command", "474747")
+self.assertEvaluate("alias_command", "474747")
+self.assertEvaluate("alias_command_with_arg", "474747")
+self.assertEvaluate("platform", "474747")
+
+self.continue_to_next_stop()
+platform_help_needle = "Commands to manage and create platforms"
+self.assertEvaluate("user_command", platform_help_needle)
+self.assertEvaluate("alias_command", platform_help_needle)
+self.assertEvaluate(
+"alias_command_with_arg " + self.getBuildDir(), "Platform: 
remote-linux"
+)
+self.assertEvaluate("platform", platform_help_needle)
diff --git a/lldb/test/API/tools/lldb-dap/repl-mode/main.cpp 
b/lldb/test/API/tools/lldb-dap/repl-mode/main.cpp
new file mode 100644
index 0..52561d3471abf
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/repl-mode/main.cpp
@@ -0,0 +1,15 @@
+void noop() {}
+
+void fun() {
+  int user_command = 474747;
+  int alias_command = 474747;
+  int alias_command_with_arg = 474747;
+  int platform = 474747; // built-in command
+  noop();// breakpoint 1
+}
+
+int main() {
+  fun();
+  noop(); // breakpoint 2
+  return 0;
+}
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index 55ff1493c1011..c7eb3db4304a9 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -14,6 +14,7 @@
 
 #include "DAP.h"
 #include "LLDBUtils.h"
+#include "lldb/API/SBCommandInterpreter.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/FormatVariadic.h"
 
@@ -405,9 +406,10 @@ ExpressionContext 
DAP::DetectExpressionContext(lldb::SBFrame frame,
 std::pair token =
 llvm::getToken(expression);
 std::string term = token.first.str();
-lldb::SBCommandReturnObject result;
-debugger.GetCommandInterpreter().ResolveCommand(term.c_str(), result);
-bool term_is_command = result.Succeeded();
+lldb::SBCommandInterpreter interpreter = debugger.GetCommandInterpreter();
+bool term_is_command = interpreter.CommandExists(term.c_str()) ||
+   interpreter.UserCommandExists(term.c_str()) ||
+   interpreter.AliasExists(term.c_str());
 bool term_is_variable = frame.FindVariable(term.c_str()).IsValid();
 
 // If we have both a variable and command, war

[Lldb-commits] [lldb] [lldb-dap] Correctly detect alias commands with arguments in repl (PR #92137)

2024-05-14 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 
2b15c4a62be6ceab124cb2505ae8dc6a98ba6e7d...6d4df820e84e84a871a6d24a196608047470d7d7
 lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py
``





View the diff from darker here.


``diff
--- TestDAP_repl_mode_detection.py  2024-05-14 15:33:00.00 +
+++ TestDAP_repl_mode_detection.py  2024-05-14 15:51:52.864048 +
@@ -8,11 +8,10 @@
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 
 
 class TestDAP_repl_mode_detection(lldbdap_testcase.DAPTestCaseBase):
-
 def assertEvaluate(self, expression, regex):
 self.assertRegex(
 self.dap_server.request_evaluate(expression, 
context="repl")["body"][
 "result"
 ],

``




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


[Lldb-commits] [lldb] [lldb][Windows] Fixed tests TestPty and TestPtyServer (PR #92090)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

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

>From b5b4b996bfa0cdba70f7935e452d6adde6b3cc15 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Tue, 14 May 2024 13:18:42 +0400
Subject: [PATCH 1/2] [lldb][Windows] Fixed tests TestPty and TestPtyServer

The tests TestPty and TestPtyServer use the Unix specific python builtin module 
termios. They are failed in case of Windows host and Linux target. Disable them 
for Windows host too.
---
 lldb/test/API/functionalities/gdb_remote_client/TestPty.py | 1 +
 lldb/test/API/tools/lldb-server/TestPtyServer.py   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/lldb/test/API/functionalities/gdb_remote_client/TestPty.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestPty.py
index 4d4dd489b294a..9e5c780a24b1b 100644
--- a/lldb/test/API/functionalities/gdb_remote_client/TestPty.py
+++ b/lldb/test/API/functionalities/gdb_remote_client/TestPty.py
@@ -6,6 +6,7 @@
 
 
 @skipIfWindows
+@skipIf(hostoslist=["windows"])
 class TestPty(GDBRemoteTestBase):
 server_socket_class = PtyServerSocket
 
diff --git a/lldb/test/API/tools/lldb-server/TestPtyServer.py 
b/lldb/test/API/tools/lldb-server/TestPtyServer.py
index aa5bd635650ac..7d91d762cb3ba 100644
--- a/lldb/test/API/tools/lldb-server/TestPtyServer.py
+++ b/lldb/test/API/tools/lldb-server/TestPtyServer.py
@@ -8,6 +8,7 @@
 
 
 @skipIfWindows
+@skipIf(hostoslist=["windows"])
 class PtyServerTestCase(gdbremote_testcase.GdbRemoteTestCaseBase):
 def setUp(self):
 super().setUp()

>From 56cd7e510ddfd8b14f2e2da819bfe6b4a74e7b05 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Tue, 14 May 2024 20:00:13 +0400
Subject: [PATCH 2/2] Removed @skipIfWindows.

---
 lldb/test/API/functionalities/gdb_remote_client/TestPty.py | 1 -
 lldb/test/API/tools/lldb-server/TestPtyServer.py   | 1 -
 2 files changed, 2 deletions(-)

diff --git a/lldb/test/API/functionalities/gdb_remote_client/TestPty.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestPty.py
index 9e5c780a24b1b..94eeb6e3ba11a 100644
--- a/lldb/test/API/functionalities/gdb_remote_client/TestPty.py
+++ b/lldb/test/API/functionalities/gdb_remote_client/TestPty.py
@@ -5,7 +5,6 @@
 from lldbsuite.test.lldbgdbclient import GDBRemoteTestBase
 
 
-@skipIfWindows
 @skipIf(hostoslist=["windows"])
 class TestPty(GDBRemoteTestBase):
 server_socket_class = PtyServerSocket
diff --git a/lldb/test/API/tools/lldb-server/TestPtyServer.py 
b/lldb/test/API/tools/lldb-server/TestPtyServer.py
index 7d91d762cb3ba..4bfcf70bfa01b 100644
--- a/lldb/test/API/tools/lldb-server/TestPtyServer.py
+++ b/lldb/test/API/tools/lldb-server/TestPtyServer.py
@@ -7,7 +7,6 @@
 import xml.etree.ElementTree as ET
 
 
-@skipIfWindows
 @skipIf(hostoslist=["windows"])
 class PtyServerTestCase(gdbremote_testcase.GdbRemoteTestCaseBase):
 def setUp(self):

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


[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)

2024-05-14 Thread via lldb-commits

jimingham wrote:

Thanks!

Jim

> On May 13, 2024, at 6:39 PM, Zequan Wu ***@***.***> wrote:
> 
> 
> Can you take care of cleaning this up, this seems like a slightly complex 
> patch and not in an area I'm familiar with.
> 
> Yes, will do. Sorry for the mess without reverting it earlier.
> 
> —
> 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/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][Windows] Fixed tests TestPty and TestPtyServer (PR #92090)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

slydiman wrote:

Agreed. I have removed `@skipIfWindows`. @skipIfRemote is too much. These tests 
are still usable for Linux->Linux and such.

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


[Lldb-commits] [lldb] 0f17d9a - [lldb] Fixed the test TestThreadStates when run with a remote target (#92086)

2024-05-14 Thread via lldb-commits

Author: Dmitry Vasilyev
Date: 2024-05-14T20:05:22+04:00
New Revision: 0f17d9a28c40eebd42c83956e2a7b5186c1814d7

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

LOG: [lldb] Fixed the test TestThreadStates when run with a remote target 
(#92086)

self.wait_for_running_event(process) is always called after
self.runCmd("continue"). It is strange to expect eStateConnected here.
This test failed in case of a remote target. The correct state is
eStateRunning. Removed incorrect checking.

Added: 


Modified: 
lldb/test/API/functionalities/thread/state/TestThreadStates.py

Removed: 




diff  --git a/lldb/test/API/functionalities/thread/state/TestThreadStates.py 
b/lldb/test/API/functionalities/thread/state/TestThreadStates.py
index f4c17df523382..4dbe230c0ce85 100644
--- a/lldb/test/API/functionalities/thread/state/TestThreadStates.py
+++ b/lldb/test/API/functionalities/thread/state/TestThreadStates.py
@@ -102,10 +102,6 @@ def thread_state_after_breakpoint_test(self):
 
 def wait_for_running_event(self, process):
 listener = self.dbg.GetListener()
-if lldb.remote_platform:
-lldbutil.expect_state_changes(
-self, listener, process, [lldb.eStateConnected]
-)
 lldbutil.expect_state_changes(self, listener, process, 
[lldb.eStateRunning])
 
 def thread_state_after_continue_test(self):



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


[Lldb-commits] [lldb] [lldb] Fixed the test TestThreadStates when run with a remote target (PR #92086)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

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


[Lldb-commits] [lldb] [lldb][Windows] Fixed the test gdb_remote_client/TestGDBRemotePlatformFile (PR #92088)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

slydiman wrote:

The problem is that fstat() is fake on Windows. File::GetPermissions() returns 
0 always.
The test got 'File permissions of /some/file.txt (remote): 0o' So any 
permissions manipulations are useles on Windows and these tests cannot be 
adapted.

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


[Lldb-commits] [lldb] [lldb][Windows] Fixed the test gdb_remote_client/TestGDBRemotePlatformFile (PR #92088)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

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

>From 7dcfe773b6eef27aabbcc7fc68cd6448bc3c2e88 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Tue, 14 May 2024 13:08:35 +0400
Subject: [PATCH 1/2] [lldb][Windows] Fixed the test
 gdb_remote_client/TestGDBRemotePlatformFile

The tests `test_file_permissions` and `test_file_permissions_fallback` are 
disabled for Windows target. These tests use MockGDBServerResponder and do not 
depend on the real target. These tests failed in case of Windows host and Linux 
target. Disable them for Windows host too.
---
 .../gdb_remote_client/TestGDBRemotePlatformFile.py  | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
index 2be5ae3132038..9ef0954af1fe3 100644
--- 
a/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
+++ 
b/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
@@ -148,6 +148,7 @@ def vFile(self, packet):
 )
 
 @skipIfWindows
+@skipIf(hostoslist=["windows"])
 def test_file_permissions(self):
 """Test 'platform get-permissions'"""
 
@@ -168,6 +169,7 @@ def vFile(self, packet):
 )
 
 @skipIfWindows
+@skipIf(hostoslist=["windows"])
 def test_file_permissions_fallback(self):
 """Test 'platform get-permissions' fallback to fstat"""
 

>From 478d251691d511916cae5fc344d549450222d584 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Tue, 14 May 2024 20:23:56 +0400
Subject: [PATCH 2/2] Removed @skipIfWindows

---
 .../gdb_remote_client/TestGDBRemotePlatformFile.py  | 2 --
 1 file changed, 2 deletions(-)

diff --git 
a/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
index 9ef0954af1fe3..b1c6f0822d1a8 100644
--- 
a/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
+++ 
b/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
@@ -147,7 +147,6 @@ def vFile(self, packet):
 log=server2.responder.packetLog,
 )
 
-@skipIfWindows
 @skipIf(hostoslist=["windows"])
 def test_file_permissions(self):
 """Test 'platform get-permissions'"""
@@ -168,7 +167,6 @@ def vFile(self, packet):
 ]
 )
 
-@skipIfWindows
 @skipIf(hostoslist=["windows"])
 def test_file_permissions_fallback(self):
 """Test 'platform get-permissions' fallback to fstat"""

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


[Lldb-commits] [lldb] [lldb][Windows] Fixed the test gdb_remote_client/TestGDBRemotePlatformFile (PR #92088)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

slydiman wrote:

I have removed @skipIfWindows because these tests are host specific.

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


[Lldb-commits] [lldb] [lldb][Windows] Fixed the test gdb_remote_client/TestGDBRemotePlatformFile (PR #92088)

2024-05-14 Thread Pavel Labath via lldb-commits

labath wrote:

> The problem is that fstat() is fake on Windows. File::GetPermissions() 
> returns 0 always. The test got 'File permissions of /some/file.txt (remote): 
> 0o' So any permissions manipulations are useles on Windows and these 
> tests cannot be adapted.

But who is calling File::GetPermissions? The way I see it, this test is 
checking that `platform get-permissions /some/file.txt` generates the correct 
gdb-remote packet. It does that by having the test talk to a simulated/mock gdb 
server and hardcoding the responses (see line 156, 0x1a4 == 0o664). In theory 
that should work as there are no real files involved (and for all lldb cares, 
the remote platform does actually have a functional permission implementation).

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-14 Thread Greg Clayton via lldb-commits

clayborg wrote:

> > I forgot to ask, what is the motivation behind this change? Is there 
> > something you can't do with the SBAPI right now or that is better expressed 
> > with SBAddressRange and SBAddressRangeList?
> 
> Yes, I want to add the following API:
> 
> lldb::SBError SBProcess::FindInMemory(const SBAddressRangeList &ranges, const 
> void *buf, uint64_t size, SBAddressRangeList &matches, size_t alignment);

Yeah, we have no `SBProcess::FindMemory()` API, but we do have a "memory find" 
command. We want to expose simple memory finds, and complex ones like above:
```
addr_t SBProcess::FindInMemory(SBAddressRange &range, const void *buf, uint64_t 
size, size_t alignment);
SBError SBProcess::FindInMemory(const SBAddressRangeList &ranges, const void 
*buf, uint64_t size, SBAddressRangeList &matches, size_t alignment);
```
We then want to plumb this through to the lldb_private::Process plug-ins so we 
can allow plug-ins to do things more efficiently. Mostly for core files where 
we could parallelize the memory search. 



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


[Lldb-commits] [lldb] [lldb][Windows] Fixed the test gdb_remote_client/TestGDBRemotePlatformFile (PR #92088)

2024-05-14 Thread Dmitry Vasilyev via lldb-commits

slydiman wrote:

The problem is here 
lldb\source\Plugins\Process\gdb-remote\GDBRemoteCommunicationClient.cpp, line 
3235
inside GDBRemoteCommunicationClient::GetFilePermissions()
```
file_permissions = mode & (S_IRWXU | S_IRWXG | S_IRWXO);
```
But S_IRWXU, S_IRWXG and S_IRWXO are 0 on Windows.

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


[Lldb-commits] [clang] [lldb] [llvm] [openmp] [polly] fix(python): fix comparison to True/False (PR #91858)

2024-05-14 Thread Alex Langford via lldb-commits

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

Hmm, actually, I'm not so sure about this change anymore. I went through PEP8 
again and saw this:

```
Don’t compare boolean values to True or False using ==:
# Correct:
if greeting:
# Wrong:
if greeting == True:

Worse:
# Wrong:
if greeting is True:
```

This doesn't seem like the right change then, no?

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits

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


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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -158,6 +160,15 @@ class ProcessElfCore : public 
lldb_private::PostMortemProcess {
   // Returns number of thread contexts stored in the core file
   uint32_t GetNumThreadContexts();
 
+  // Populate gnu uuid for each NT_FILE entry
+  void UpdateBuildIdForNTFileEntries();
+
+  // Returns the UUID of a given NT_FILE entry
+  lldb_private::UUID FindBuildId(const NT_FILE_Entry entry);

clayborg wrote:

return `std::optional`

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -983,6 +995,44 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+  const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4 bytes

clayborg wrote:

We have a ELF.h file you can get the magic bytes from:
```
#include "llvm/BinaryFormat/ELF.h"
```
Then you can use `llvm::ELF::ElfMagic`. They use it here:
```
bool ELFHeader::MagicBytesMatch(const uint8_t *magic) {
  return memcmp(magic, ElfMagic, strlen(ElfMagic)) == 0;
}
```


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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -983,6 +995,44 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+  const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4 bytes
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(entry.start, buf, 4, error);
+  if (byte_read == 4) {
+return memcmp(elf_header, buf, 4) == 0;
+  } else {
+return false;
+  }
+}
+
+UUID ProcessElfCore::FindBuildId(const NT_FILE_Entry entry) {
+  if (!IsElf(entry)) {
+return UUID();
+  }
+  // Build ID is stored in the ELF file as a section named ".note.gnu.build-id"
+  uint8_t gnu_build_id_bytes[8] = {0x03, 0x00, 0x00, 0x00,
+   0x47, 0x4e, 0x55, 0x00};
+  lldb::addr_t gnu_build_id_addr =
+  FastSearch(entry.start, entry.end, gnu_build_id_bytes, 8);
+  if (gnu_build_id_addr == LLDB_INVALID_ADDRESS) {
+return UUID();
+  }
+  uint8_t buf[36];
+  Status error;
+  size_t byte_read = ReadMemory(gnu_build_id_addr - 8, buf, 36, error);
+  // .note.gnu.build-id starts with 04 00 00 00 {id_byte_size} 00 00 00 03 00 
00
+  // 00 47 4e 55 00
+  if (byte_read == 36) {

clayborg wrote:

We should not assume there are always 36 bytes here. We should read the first 8 
bytes to get the `namesz` and `descsz` entries using a DataExtractor. Then do 
the right thing when decoding the UUID bytes by using the `namesz` value + 12 
bytes for the `namesz`, `descsz` and `type` uint32_t fields. We should also 
make sure our length isn't out of control and too big:
```
DataExtractor data(buf, sizeof(buf), GetByteOrder(), GetAddressByteSize());
lldb::offset_t offset = 0; 
const uint32_t namesz = data.GetU32(&offset); // Decode the length of the note 
name
const uint32_t descsz = data.GetU32(&offset); // Decode the UUID length
if (0 < uuid_length && uuid_length <= 20)
  offset = 16; // Set the position to point to the UUID bytes
  return UUID(llvm::ArrayRef(data.GetData(12 + namesz), descsz);
}
```

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -117,6 +117,8 @@ class ProcessElfCore : public 
lldb_private::PostMortemProcess {
 lldb::addr_t end;
 lldb::addr_t file_ofs;
 std::string path;
+lldb_private::UUID
+uuid; // extracted from .note.gnu.build-id section from core file

clayborg wrote:

maybe we should use `std::optional` here

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -983,6 +995,44 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+  const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4 bytes
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(entry.start, buf, 4, error);
+  if (byte_read == 4) {
+return memcmp(elf_header, buf, 4) == 0;
+  } else {
+return false;
+  }
+}
+
+UUID ProcessElfCore::FindBuildId(const NT_FILE_Entry entry) {
+  if (!IsElf(entry)) {
+return UUID();
+  }
+  // Build ID is stored in the ELF file as a section named ".note.gnu.build-id"
+  uint8_t gnu_build_id_bytes[8] = {0x03, 0x00, 0x00, 0x00,
+   0x47, 0x4e, 0x55, 0x00};
+  lldb::addr_t gnu_build_id_addr =
+  FastSearch(entry.start, entry.end, gnu_build_id_bytes, 8);
+  if (gnu_build_id_addr == LLDB_INVALID_ADDRESS) {
+return UUID();
+  }
+  uint8_t buf[36];
+  Status error;
+  size_t byte_read = ReadMemory(gnu_build_id_addr - 8, buf, 36, error);
+  // .note.gnu.build-id starts with 04 00 00 00 {id_byte_size} 00 00 00 03 00 
00
+  // 00 47 4e 55 00
+  if (byte_read == 36) {
+if (buf[0] == 0x04) {
+  return UUID(llvm::ArrayRef(buf + 16, buf[4] /*byte size*/));
+}
+  }

clayborg wrote:

remove braces per llvm coding guidelines for single statement `if`

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -3191,6 +3191,33 @@ Status Process::Halt(bool clear_thread_plans, bool 
use_run_lock) {
   return Status();
 }
 
+lldb::addr_t Process::FastSearch(lldb::addr_t low, lldb::addr_t high,

clayborg wrote:

rename to `FindInMemory`

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -983,6 +995,44 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+  const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4 bytes
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(entry.start, buf, 4, error);
+  if (byte_read == 4) {
+return memcmp(elf_header, buf, 4) == 0;
+  } else {
+return false;
+  }
+}
+
+UUID ProcessElfCore::FindBuildId(const NT_FILE_Entry entry) {
+  if (!IsElf(entry)) {
+return UUID();
+  }

clayborg wrote:

remove braces per llvm coding guidelines for single statement `if`

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -983,6 +995,44 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+  const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4 bytes
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(entry.start, buf, 4, error);
+  if (byte_read == 4) {
+return memcmp(elf_header, buf, 4) == 0;
+  } else {
+return false;
+  }

clayborg wrote:

remove '{}' for single line if/then per llvm coding guidelines:
```
 if (byte_read == 4)
return memcmp(elf_header, buf, 4) == 0;
  else
return false;
```

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -977,35 +977,6 @@ class CommandObjectMemoryFind : public CommandObjectParsed 
{
   Options *GetOptions() override { return &m_option_group; }
 
 protected:
-  class ProcessMemoryIterator {
-  public:
-ProcessMemoryIterator(ProcessSP process_sp, lldb::addr_t base)
-: m_process_sp(process_sp), m_base_addr(base) {
-  lldbassert(process_sp.get() != nullptr);
-}
-
-bool IsValid() { return m_is_valid; }
-
-uint8_t operator[](lldb::addr_t offset) {
-  if (!IsValid())
-return 0;
-
-  uint8_t retval = 0;
-  Status error;
-  if (0 ==
-  m_process_sp->ReadMemory(m_base_addr + offset, &retval, 1, error)) {
-m_is_valid = false;
-return 0;

clayborg wrote:

This is efficient only because our process caches memory on its own... 
Otherwise reading memory 1 byte at a time would be more expensive. Not sure if 
we can get any speed up by reading more than one byte at a time and then using 
our own internal buffer.

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -983,6 +995,44 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+  const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4 bytes
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(entry.start, buf, 4, error);
+  if (byte_read == 4) {
+return memcmp(elf_header, buf, 4) == 0;
+  } else {
+return false;
+  }
+}
+
+UUID ProcessElfCore::FindBuildId(const NT_FILE_Entry entry) {
+  if (!IsElf(entry)) {
+return UUID();
+  }
+  // Build ID is stored in the ELF file as a section named ".note.gnu.build-id"
+  uint8_t gnu_build_id_bytes[8] = {0x03, 0x00, 0x00, 0x00,
+   0x47, 0x4e, 0x55, 0x00};
+  lldb::addr_t gnu_build_id_addr =
+  FastSearch(entry.start, entry.end, gnu_build_id_bytes, 8);

clayborg wrote:

Rename this to `FindInMemory` as suggested in header file inline comments

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -983,6 +995,44 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+  const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4 bytes
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(entry.start, buf, 4, error);
+  if (byte_read == 4) {
+return memcmp(elf_header, buf, 4) == 0;
+  } else {
+return false;
+  }
+}
+
+UUID ProcessElfCore::FindBuildId(const NT_FILE_Entry entry) {
+  if (!IsElf(entry)) {
+return UUID();
+  }
+  // Build ID is stored in the ELF file as a section named ".note.gnu.build-id"
+  uint8_t gnu_build_id_bytes[8] = {0x03, 0x00, 0x00, 0x00,
+   0x47, 0x4e, 0x55, 0x00};
+  lldb::addr_t gnu_build_id_addr =
+  FastSearch(entry.start, entry.end, gnu_build_id_bytes, 8);
+  if (gnu_build_id_addr == LLDB_INVALID_ADDRESS) {
+return UUID();

clayborg wrote:

```
return std::nullopt;
```

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -983,6 +995,44 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+  const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4 bytes
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(entry.start, buf, 4, error);
+  if (byte_read == 4) {
+return memcmp(elf_header, buf, 4) == 0;
+  } else {
+return false;
+  }
+}
+
+UUID ProcessElfCore::FindBuildId(const NT_FILE_Entry entry) {
+  if (!IsElf(entry)) {
+return UUID();
+  }
+  // Build ID is stored in the ELF file as a section named ".note.gnu.build-id"
+  uint8_t gnu_build_id_bytes[8] = {0x03, 0x00, 0x00, 0x00,
+   0x47, 0x4e, 0x55, 0x00};
+  lldb::addr_t gnu_build_id_addr =
+  FastSearch(entry.start, entry.end, gnu_build_id_bytes, 8);
+  if (gnu_build_id_addr == LLDB_INVALID_ADDRESS) {
+return UUID();
+  }

clayborg wrote:

remove braces per llvm coding guidelines for single statement `if`

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -983,6 +995,44 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+  const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4 bytes
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(entry.start, buf, 4, error);
+  if (byte_read == 4) {
+return memcmp(elf_header, buf, 4) == 0;
+  } else {
+return false;
+  }
+}
+
+UUID ProcessElfCore::FindBuildId(const NT_FILE_Entry entry) {
+  if (!IsElf(entry)) {
+return UUID();
+  }
+  // Build ID is stored in the ELF file as a section named ".note.gnu.build-id"
+  uint8_t gnu_build_id_bytes[8] = {0x03, 0x00, 0x00, 0x00,
+   0x47, 0x4e, 0x55, 0x00};
+  lldb::addr_t gnu_build_id_addr =
+  FastSearch(entry.start, entry.end, gnu_build_id_bytes, 8);
+  if (gnu_build_id_addr == LLDB_INVALID_ADDRESS) {
+return UUID();
+  }

clayborg wrote:

remove braces per llvm coding guidelines for single statement `if`

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


[Lldb-commits] [lldb] [llvm] [RFC][LLDB] Telemetry in LLDB (PR #87815)

2024-05-14 Thread Vy Nguyen via lldb-commits

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

>From cdee622a6646ba5c16a3c8156a5a50a938a14b57 Mon Sep 17 00:00:00 2001
From: Vy Nguyen 
Date: Fri, 5 Apr 2024 14:14:30 -0400
Subject: [PATCH 1/3] [lldb]POC implementation for telemetry in LLDB

---
 lldb/include/lldb/API/SBDebugger.h|   4 +
 lldb/include/lldb/Core/Debugger.h |  10 +
 lldb/include/lldb/Core/Telemetry.h| 206 ++
 lldb/include/lldb/Target/Process.h|   3 +
 lldb/source/API/SBDebugger.cpp|   9 +
 lldb/source/Core/CMakeLists.txt   |   1 +
 lldb/source/Core/Debugger.cpp |  32 +-
 lldb/source/Core/Telemetry.cpp| 620 ++
 .../source/Interpreter/CommandInterpreter.cpp |  44 +-
 lldb/source/Target/Process.cpp|   7 +-
 lldb/source/Target/Target.cpp |  17 +-
 lldb/tools/lldb-dap/DAP.cpp   |  18 +-
 12 files changed, 953 insertions(+), 18 deletions(-)
 create mode 100644 lldb/include/lldb/Core/Telemetry.h
 create mode 100644 lldb/source/Core/Telemetry.cpp

diff --git a/lldb/include/lldb/API/SBDebugger.h 
b/lldb/include/lldb/API/SBDebugger.h
index 62b2f91f5076d..c4b51fc925f09 100644
--- a/lldb/include/lldb/API/SBDebugger.h
+++ b/lldb/include/lldb/API/SBDebugger.h
@@ -9,10 +9,12 @@
 #ifndef LLDB_API_SBDEBUGGER_H
 #define LLDB_API_SBDEBUGGER_H
 
+#include 
 #include 
 
 #include "lldb/API/SBDefines.h"
 #include "lldb/API/SBPlatform.h"
+#include 
"third_party/llvm/llvm-project/lldb/include/lldb/API/SBStructuredData.h"
 
 namespace lldb_private {
 class CommandPluginInterfaceImplementation;
@@ -243,6 +245,8 @@ class LLDB_API SBDebugger {
 
   lldb::SBTarget GetDummyTarget();
 
+  void SendTelemetry(SBStructuredData *entry);
+
   // Return true if target is deleted from the target list of the debugger.
   bool DeleteTarget(lldb::SBTarget &target);
 
diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 418c2403d020f..a3ecb7e472437 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -19,6 +19,7 @@
 #include "lldb/Core/FormatEntity.h"
 #include "lldb/Core/IOHandler.h"
 #include "lldb/Core/SourceManager.h"
+#include "lldb/Core/Telemetry.h"
 #include "lldb/Core/UserSettingsController.h"
 #include "lldb/Host/HostThread.h"
 #include "lldb/Host/StreamFile.h"
@@ -38,6 +39,7 @@
 #include "lldb/lldb-private-enumerations.h"
 #include "lldb/lldb-private-types.h"
 #include "lldb/lldb-types.h"
+#include 
"third_party/llvm/llvm-project/lldb/include/lldb/Utility/StructuredData.h"
 
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/StringMap.h"
@@ -145,6 +147,12 @@ class Debugger : public 
std::enable_shared_from_this,
 
   lldb::StreamFileSP GetErrorStreamSP() { return m_error_stream_sp; }
 
+  std::shared_ptr GetTelemetryLogger() {
+return m_telemetry_logger;
+  }
+
+  void SendClientTelemetry(lldb_private::StructuredData::Object *entry);
+
   File &GetInputFile() { return *m_input_file_sp; }
 
   File &GetOutputFile() { return m_output_stream_sp->GetFile(); }
@@ -737,6 +745,7 @@ class Debugger : public 
std::enable_shared_from_this,
   uint32_t m_interrupt_requested = 0; ///< Tracks interrupt requests
   std::mutex m_interrupt_mutex;
 
+  std::shared_ptr m_telemetry_logger;
   // Events for m_sync_broadcaster
   enum {
 eBroadcastBitEventThreadIsListening = (1 << 0),
@@ -749,6 +758,7 @@ class Debugger : public 
std::enable_shared_from_this,
 
   Debugger(const Debugger &) = delete;
   const Debugger &operator=(const Debugger &) = delete;
+  TelemetryEventStats stats;
 };
 
 } // namespace lldb_private
diff --git a/lldb/include/lldb/Core/Telemetry.h 
b/lldb/include/lldb/Core/Telemetry.h
new file mode 100644
index 0..1c7b030bb2a49
--- /dev/null
+++ b/lldb/include/lldb/Core/Telemetry.h
@@ -0,0 +1,206 @@
+#ifndef LLDB_CORE_TELEMETRY_H
+#define LLDB_CORE_TELEMETRY_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Utility/StructuredData.h"
+#include "lldb/lldb-forward.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+
+namespace lldb_private {
+
+using SteadyTimePoint = std::chrono::time_point;
+
+struct TelemetryEventStats {
+  // REQUIRED: Start time of event
+  SteadyTimePoint m_start;
+  // OPTIONAL: End time of event - may be empty if not meaningful.
+  std::optional m_end;
+
+  // TBD: could add some memory stats here too?
+
+  TelemetryEventStats() = default;
+  TelemetryEventStats(SteadyTimePoint start) : m_start(start) {}
+  TelemetryEventStats(SteadyTimePoint start, SteadyTimePoint end)
+  : m_start(start), m_end(end) {}
+
+  std::optional Duration() const {
+if (m_end.has_value())
+  return *m_end - m_start;
+else
+  return std::nullopt;
+  }
+};
+
+struct LoggerConfig {
+  // If true, loggings will be enabled.
+  bool enable_logging;
+
+  // Additi

[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,13 @@
+%extend lldb::SBAddressRangeList {
+#ifdef SWIGPYTHON
+%pythoncode%{
+def __len__(self):
+  '''Return the number of address ranges in a lldb.SBAddressRangeList 
object.'''
+  return self.GetSize()
+
+def __iter__(self):
+  '''Iterate over all the address ranges in a lldb.SBAddressRangeList 
object.'''
+  return lldb_iter(self, 'GetSize', 'GetAddressRangeAtIndex')
+%}

clayborg wrote:

We should add the ability to subscript a `SBAddressRangeList` object, and also 
use it as an iterable. So something like this should work in python:
```
function = ...; # Get a lldb.SBFunction somehow
ranges = function.GetRanges()
for range in ranges: # Implement iterable for this object
  print(range)
for i in ranges.GetSize():
  range = ranges[i] # Implement the subscripting extension
```
Other classes do this, we should copy that kind of code into this .i file

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-14 Thread Greg Clayton via lldb-commits

https://github.com/clayborg commented:

We might want SBAddressRange and SBAddressRangeList to have methods:
```
  bool GetDescription(lldb::SBStream &description);
```
Then make sure we add stuff to the .i files so python `str()` calls this. 
We do this in many other classes.

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,13 @@
+%extend lldb::SBAddressRangeList {

clayborg wrote:

If we add a method to SBAddressRangeList:
```
  bool GetDescription(lldb::SBStream &description);
```
Then we can add this to this file:
```
STRING_EXTENSION_OUTSIDE(SBAddressRangeList)
```
And then we can print the SBAddressRangeList objects as user readable strings.

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,13 @@
+%extend lldb::SBAddressRangeList {
+#ifdef SWIGPYTHON
+%pythoncode%{
+def __len__(self):
+  '''Return the number of address ranges in a lldb.SBAddressRangeList 
object.'''
+  return self.GetSize()
+
+def __iter__(self):
+  '''Iterate over all the address ranges in a lldb.SBAddressRangeList 
object.'''
+  return lldb_iter(self, 'GetSize', 'GetAddressRangeAtIndex')
+%}

clayborg wrote:

Sorry, missed that you had the iterable already, just need the __getitem__ for 
array access

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


[Lldb-commits] [lldb] [lldb] Allow env override for LLDB_ARGDUMPER_PATH (PR #91688)

2024-05-14 Thread Keith Smiley via lldb-commits

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


[Lldb-commits] [lldb] f918c05 - [lldb] Allow env override for LLDB_ARGDUMPER_PATH (#91688)

2024-05-14 Thread via lldb-commits

Author: Keith Smiley
Date: 2024-05-14T13:43:04-07:00
New Revision: f918c056f06968763870bc3e6b9f9d7074e1f867

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

LOG: [lldb] Allow env override for LLDB_ARGDUMPER_PATH (#91688)

This mirrors the LLDB_DEBUGSERVER_PATH environment variable and allows
you to have lldb-argdumper in a non-standard location and still use it
at runtime.

Added: 


Modified: 
lldb/source/Host/macosx/objcxx/Host.mm

Removed: 




diff  --git a/lldb/source/Host/macosx/objcxx/Host.mm 
b/lldb/source/Host/macosx/objcxx/Host.mm
index 4fba5550ba10a..e6f1c0ea3d295 100644
--- a/lldb/source/Host/macosx/objcxx/Host.mm
+++ b/lldb/source/Host/macosx/objcxx/Host.mm
@@ -1387,18 +1387,31 @@ static bool ShouldLaunchUsingXPC(ProcessLaunchInfo 
&launch_info) {
 Status Host::ShellExpandArguments(ProcessLaunchInfo &launch_info) {
   Status error;
   if (launch_info.GetFlags().Test(eLaunchFlagShellExpandArguments)) {
-FileSpec expand_tool_spec = HostInfo::GetSupportExeDir();
-if (!expand_tool_spec) {
-  error.SetErrorString(
-  "could not get support executable directory for lldb-argdumper 
tool");
-  return error;
+FileSpec expand_tool_spec;
+Environment host_env = Host::GetEnvironment();
+std::string env_argdumper_path = host_env.lookup("LLDB_ARGDUMPER_PATH");
+if (!env_argdumper_path.empty()) {
+  expand_tool_spec.SetFile(env_argdumper_path, FileSpec::Style::native);
+  Log *log(GetLog(LLDBLog::Host | LLDBLog::Process));
+  LLDB_LOGF(log,
+"lldb-argdumper exe path set from environment variable: %s",
+env_argdumper_path.c_str());
 }
-expand_tool_spec.AppendPathComponent("lldb-argdumper");
-if (!FileSystem::Instance().Exists(expand_tool_spec)) {
-  error.SetErrorStringWithFormat(
-  "could not find the lldb-argdumper tool: %s",
-  expand_tool_spec.GetPath().c_str());
-  return error;
+bool argdumper_exists = FileSystem::Instance().Exists(env_argdumper_path);
+if (!argdumper_exists) {
+  expand_tool_spec = HostInfo::GetSupportExeDir();
+  if (!expand_tool_spec) {
+error.SetErrorString("could not get support executable directory for "
+ "lldb-argdumper tool");
+return error;
+  }
+  expand_tool_spec.AppendPathComponent("lldb-argdumper");
+  if (!FileSystem::Instance().Exists(expand_tool_spec)) {
+error.SetErrorStringWithFormat(
+"could not find the lldb-argdumper tool: %s",
+expand_tool_spec.GetPath().c_str());
+return error;
+  }
 }
 
 StreamString expand_tool_spec_stream;



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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,58 @@
+//===-- SBAddressRangeList.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_API_SBADDRESSRANGELIST_H
+#define LLDB_API_SBADDRESSRANGELIST_H
+
+#include 
+
+#include "lldb/API/SBDefines.h"
+
+class AddressRangeListImpl;
+
+namespace lldb {
+
+class LLDB_API SBAddressRangeList {
+public:
+  SBAddressRangeList();
+
+  SBAddressRangeList(const lldb::SBAddressRangeList &rhs);
+
+  ~SBAddressRangeList();
+
+  const lldb::SBAddressRangeList &
+  operator=(const lldb::SBAddressRangeList &rhs);
+
+  uint32_t GetSize() const;
+
+  void Clear();
+
+  bool GetAddressRangeAtIndex(uint64_t idx, SBAddressRange &addr_range);
+
+  void Append(const lldb::SBAddressRange &addr_range);
+
+  void Append(const lldb::SBAddressRangeList &addr_range_list);
+
+protected:
+  const AddressRangeListImpl *operator->() const;
+
+  const AddressRangeListImpl &operator*() const;
+
+private:
+  friend class SBProcess;
+
+  lldb_private::AddressRanges &ref();
+
+  const lldb_private::AddressRanges &ref() const;

clayborg wrote:

We need to keep `AddressRangeListImpl` in the .cpp file only, and other APIs 
will end up needing a reference to the contained address ranges, so this is ok 
as it stands.

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


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-14 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,78 @@
+//===-- SBAddressRange.cpp 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRange.h"
+#include "Utils.h"
+#include "lldb/API/SBAddress.h"
+#include "lldb/Core/AddressRange.h"
+#include "lldb/Utility/Instrumentation.h"
+#include 
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRange::SBAddressRange()
+: m_opaque_up(std::make_unique()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRange::SBAddressRange(const SBAddressRange &rhs) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  m_opaque_up = clone(rhs.m_opaque_up);
+}
+
+SBAddressRange::SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size)
+: m_opaque_up(std::make_unique(file_addr, byte_size)) {
+  LLDB_INSTRUMENT_VA(this, file_addr, byte_size);
+}

clayborg wrote:

```
SBAddressRange::SBAddressRange(SBAddress addr, lldb::addr_t byte_size)
: m_opaque_up(std::make_unique(addr.ref(), byte_size)) {
  LLDB_INSTRUMENT_VA(this, file_addr, byte_size);
}
```

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


[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92078)

2024-05-14 Thread via lldb-commits

GeorgeHuyubo wrote:

> Can we make this less brute force? I believe searching for the Build ID Note 
> should be a completely deterministic process, without the need for 
> heuristics. You start with the elf header, find the program headers, iterate 
> to find the PT_NOTE segment (there could be more of them), and iterate over 
> the notes until you find NT_GNU_BUILD_ID. All of these things should be in 
> the memory (=> also in the core file) and within the first 4k of the mapping. 
> There should be no need to search through a potentially huge file mapping 
> just to see if it contains the build id.

Here is a real life binary:
0x7f2e7b6a5000+0x4000 b3bd5db2152ddae68640e781e1a6c039@0x7f2e7b6a7280 - - 
/tmp/hhvm_member_reflection_0d17d1c87f353d813d3e6b43e6db1d59e428c014_HFrPOT

so the .note.gnu.build-id is found at 0x7f2e7b6a7280 which is the file start 
address 0x7f2e7b6a5000 plus 0x2280(8832 bytes in decimal).
I don't know what is the precise search range limit which can guarantee us to 
find the NT_GNU_BUILD_ID. Open for suggestion.

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


  1   2   >