[Lldb-commits] [lldb] Reapply LLDB-Telemetry TargetInfo branch (pr/127834) (PR #132043)
https://github.com/oontvoo updated
https://github.com/llvm/llvm-project/pull/132043
>From 9f0a47af2b7fdb90e4fa4cc7f8f97c840af1d2bc Mon Sep 17 00:00:00 2001
From: Vy Nguyen
Date: Wed, 19 Mar 2025 10:44:12 -0400
Subject: [PATCH 1/7] Reapply "[LLDB][Telemetry]Define TargetInfo for
collecting data about a target (#127834)"
This reverts commit 7dbcdd578cd4d37b1f4094dbd17556be6382f1cc.
---
lldb/include/lldb/Core/Telemetry.h| 74 +--
lldb/source/Core/Telemetry.cpp| 25 ++-
.../source/Interpreter/CommandInterpreter.cpp | 2 +-
lldb/source/Target/Process.cpp| 21 ++
lldb/source/Target/Target.cpp | 21 ++
5 files changed, 134 insertions(+), 9 deletions(-)
diff --git a/lldb/include/lldb/Core/Telemetry.h
b/lldb/include/lldb/Core/Telemetry.h
index 29ec36b2d64d1..28897f283dc55 100644
--- a/lldb/include/lldb/Core/Telemetry.h
+++ b/lldb/include/lldb/Core/Telemetry.h
@@ -23,9 +23,12 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
+#include
namespace lldb_private {
namespace telemetry {
@@ -46,12 +49,18 @@ struct LLDBConfig : public ::llvm::telemetry::Config {
// Specifically:
// - Length: 8 bits
// - First two bits (MSB) must be 11 - the common prefix
+// - Last two bits (LSB) are reserved for grand-children of LLDBTelemetryInfo
// If any of the subclass has descendents, those descendents
-// must have their LLDBEntryKind in the similar form (ie., share common prefix)
+// must have their LLDBEntryKind in the similar form (ie., share common prefix
+// and differ by the last two bits)
struct LLDBEntryKind : public ::llvm::telemetry::EntryKind {
- static const llvm::telemetry::KindType BaseInfo = 0b1100;
- static const llvm::telemetry::KindType CommandInfo = 0b1101;
- static const llvm::telemetry::KindType DebuggerInfo = 0b11000100;
+ // clang-format off
+ static const llvm::telemetry::KindType BaseInfo= 0b1100;
+ static const llvm::telemetry::KindType CommandInfo = 0b1101;
+ static const llvm::telemetry::KindType DebuggerInfo= 0b11001000;
+ static const llvm::telemetry::KindType ExecModuleInfo = 0b11000100;
+ static const llvm::telemetry::KindType ProcessExitInfo = 0b11001100;
+ // clang-format on
};
/// Defines a convenient type for timestamp of various events.
@@ -89,7 +98,7 @@ struct CommandInfo : public LLDBBaseTelemetryInfo {
/// session. Necessary because we'd send off an entry right before a
command's
/// execution and another right after. This is to avoid losing telemetry if
/// the command does not execute successfully.
- uint64_t command_id;
+ uint64_t command_id = 0;
/// The command name(eg., "breakpoint set")
std::string command_name;
/// These two fields are not collected by default due to PII risks.
@@ -116,7 +125,7 @@ struct CommandInfo : public LLDBBaseTelemetryInfo {
void serialize(llvm::telemetry::Serializer &serializer) const override;
- static uint64_t GetNextId();
+ static uint64_t GetNextID();
private:
// We assign each command (in the same session) a unique id so that their
@@ -146,6 +155,59 @@ struct DebuggerInfo : public LLDBBaseTelemetryInfo {
void serialize(llvm::telemetry::Serializer &serializer) const override;
};
+struct ExecutableModuleInfo : public LLDBBaseTelemetryInfo {
+ lldb::ModuleSP exec_mod;
+ /// The same as the executable-module's UUID.
+ UUID uuid;
+ /// PID of the process owned by this target.
+ lldb::pid_t pid = LLDB_INVALID_PROCESS_ID;
+ /// The triple of this executable module.
+ std::string triple;
+
+ /// If true, this entry was emitted at the beginning of an event (eg., before
+ /// the executable is set). Otherwise, it was emitted at the end of an
+ /// event (eg., after the module and any dependency were loaded.)
+ bool is_start_entry = false;
+
+ ExecutableModuleInfo() = default;
+
+ llvm::telemetry::KindType getKind() const override {
+return LLDBEntryKind::ExecModuleInfo;
+ }
+
+ static bool classof(const TelemetryInfo *T) {
+// Subclasses of this is also acceptable
+return (T->getKind() & LLDBEntryKind::ExecModuleInfo) ==
+ LLDBEntryKind::ExecModuleInfo;
+ }
+ void serialize(llvm::telemetry::Serializer &serializer) const override;
+};
+
+/// Describes an exit status.
+struct ExitDescription {
+ int exit_code;
+ std::string description;
+};
+
+struct ProcessExitInfo : public LLDBBaseTelemetryInfo {
+ // The executable-module's UUID.
+ UUID module_uuid;
+ lldb::pid_t pid = LLDB_INVALID_PROCESS_ID;
+ bool is_start_entry = false;
+ std::optional exit_desc;
+
+ llvm::telemetry::KindType getKind() const override {
+return LLDBEntryKind::ProcessExitInfo;
+ }
+
+ static bool classof(const TelemetryInfo *T) {
+// Subclasses of this is also acceptable
+return (T->getKind() & LLDBEntryKind::ProcessExitInfo) ==
+ LLDBEntryKind::ProcessExitInfo;
+ }
+ void serialize(llvm::t
[Lldb-commits] [lldb] [lldb] Change test paths to resolve symlinks (PR #132053)
https://github.com/dmpots updated https://github.com/llvm/llvm-project/pull/132053 >From efde68cf06da2f668f4d2ecd638b826c7f4c5b70 Mon Sep 17 00:00:00 2001 From: David Peixotto Date: Wed, 19 Mar 2025 08:44:59 -0700 Subject: [PATCH 1/3] [lldb] Change test paths to resolve symlinks This commit modifes the `getSourceDir()` and `getBuildDir()` functions to use os.path.realpath to resolve symlinks in the Base test class used for API tests. A few tests were failing when the build and source directories were located under a path that contained a symlink. These failures were because of cases where the symlink would be resolve to its real path in the source code, but the test code would try to match against the path with the symbolic link. Two failing tests were TestProcessLaunch.test_target_launch_working_dir_prop TestSourceManager.test_source_cache_dump_and_clear The inferior used `TestProcessLaunch` prints out its working directory using the `getcwd` function, which is not allowed to return symbolic links in the path components. When testing against the output from `getcwd` we should resolve the full path to match the expected output. The `TestSourceManager` test sets a breakpoint on a main-copy.c file that is copied into the build output directory. The source manager resolves this file to its real location. When testing the output from the source cache we need to resolve the expected path to remove symlinks. --- lldb/packages/Python/lldbsuite/test/lldbtest.py | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py b/lldb/packages/Python/lldbsuite/test/lldbtest.py index 570c36b5f9622..7ac7aa368cc01 100644 --- a/lldb/packages/Python/lldbsuite/test/lldbtest.py +++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py @@ -722,15 +722,17 @@ def clean_working_directory(): def getSourceDir(self): """Return the full path to the current test.""" -return os.path.join(configuration.test_src_root, self.mydir) +return os.path.realpath(os.path.join(configuration.test_src_root, self.mydir)) def getBuildDirBasename(self): return self.__class__.__module__ + "." + self.testMethodName def getBuildDir(self): """Return the full path to the current test.""" -return os.path.join( -configuration.test_build_dir, self.mydir, self.getBuildDirBasename() +return os.path.realpath( +os.path.join( +configuration.test_build_dir, self.mydir, self.getBuildDirBasename() +) ) def makeBuildDir(self): >From 36c6e195c0143c664c275cf5b549c8548c7293ac Mon Sep 17 00:00:00 2001 From: David Peixotto Date: Thu, 20 Mar 2025 12:46:09 -0700 Subject: [PATCH 2/3] Revert "[lldb] Change test paths to resolve symlinks" This reverts commit efde68cf06da2f668f4d2ecd638b826c7f4c5b70. --- lldb/packages/Python/lldbsuite/test/lldbtest.py | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py b/lldb/packages/Python/lldbsuite/test/lldbtest.py index 7ac7aa368cc01..570c36b5f9622 100644 --- a/lldb/packages/Python/lldbsuite/test/lldbtest.py +++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py @@ -722,17 +722,15 @@ def clean_working_directory(): def getSourceDir(self): """Return the full path to the current test.""" -return os.path.realpath(os.path.join(configuration.test_src_root, self.mydir)) +return os.path.join(configuration.test_src_root, self.mydir) def getBuildDirBasename(self): return self.__class__.__module__ + "." + self.testMethodName def getBuildDir(self): """Return the full path to the current test.""" -return os.path.realpath( -os.path.join( -configuration.test_build_dir, self.mydir, self.getBuildDirBasename() -) +return os.path.join( +configuration.test_build_dir, self.mydir, self.getBuildDirBasename() ) def makeBuildDir(self): >From 76c925847ab24b2cd5e32eadf94e96215e2c306f Mon Sep 17 00:00:00 2001 From: David Peixotto Date: Tue, 18 Mar 2025 22:21:39 -0700 Subject: [PATCH 3/3] [lldb] Fix tests to resolve symlinks when checking paths The inferior used in the process launch test prints out its working directory using the `getcwd` function, which is not allowed to return symbolic links in the path components. When testing against the output from `getcwd` we should resolve the full path to match the expected output. The source manager test sets a breakpoint on a main-copy.c file that is copied into the build output directory. The source manager resolves this path to its real location. When testing the output from the source cache we need to resolve the expected path in the test to remove symlinks. --- lldb/test/API/commands/process/launch/TestProcessLaunch.py | 2 +- lldb/test/API/source-manager/TestSourceManager.p
[Lldb-commits] [lldb] [lldb] Fix tests to resolve symlinks when checking paths (PR #132053)
https://github.com/dmpots edited https://github.com/llvm/llvm-project/pull/132053 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adding a DAPError for showing users error messages. (PR #132255)
https://github.com/ashgti edited https://github.com/llvm/llvm-project/pull/132255 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adding support for cancelling a request. (PR #130169)
ashgti wrote:
> Anyway, what I had in mind when I read your RFC and was doing the
> RequestHandler work, triggered by a question from @labath, is that instead of
> having one RequestHandler instance per command (which is what we have today),
> we could instantiate a RequestHandler per incoming command (or a new object
> that has a reference to the request hander and stores the arguments).
>
> The read thread could decode its arguments and store away the protocol in the
> RequestHandler/new object and add it to the queue. Beyond that, things work
> pretty much how you've implemented them here, but with the logic that checks
> if the request has been cancelled in the RequestHandler. More concretely the
> operator doesn't take arguments anymore, and it's implemented something like
> this:
>
> ```
> void operator() {
> if (IsCancelled()) // Check if our request ID is in the cancelled request
> set.
> RespondCancelled();
>
> llvm::Expected body = Run();
> if (!body)
> // Handle error
>
> if (IsInterrupted()) // Check if the SBDebugger was interrupted.
> RespondCancelled();
> }
> ```
>
> If we go with the new object (`PendingRequest`?) the request handlers can
> remain what they are today, or if we want to store the data in them we'll
> need to find a way to dispatch to them (similar to my comment in yesterday's
> PR).
>
> Anyway, like I said, not sure if this is actually better, just sharing my
> thoughts.
I do think this is an interesting approach. I can take a look at this as trying
to wrap some of this into some helpers or maybe making the RequestHandler
allocate a new instance per request.
My logic behind the `lldb_dap::protocol` types was to keep them as POD data and
to not have much (if any) logic in them so that if we need to move the data
between threads or queues we can be relatively confident that we're not dealing
data races. In swift terms (I'm more familiar with swift than c++), the
`lldb_dap::protocol` types would be `struct`'s that are all `Sendable`.
That may not be as idiomatic in c++ though.
I do like the more simplified `operator()` idea to help deal with the cancelled
/ interrupted, my existing solution was done to support the
LegacyRequestHandlers since they're sending the responses as raw
`json::Value`'s still, but with the more unified approach we could handle the
cancellation in the `operator()` body.
I'll try to see if I can come up with a `PendingRequest` or maybe take a look
at allocating the `RequestHandler`'s in the queue.
https://github.com/llvm/llvm-project/pull/130169
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix tests to resolve symlinks when checking paths (PR #132053)
dmpots wrote: > Resolving the symlink is not the right thing to do in some cases (such as > when you symlinks define the actual/expected layout of the directory tree and > the real paths are meaningless (e.g. nodes in some CAS storage). I would very > much like to see solution that applies the fixes locally, where they are > needed. I updated the PR to only apply the fix locally. I had done it this way initially, but thought I would try the general fix first to avoid problems in the future. Please take a look. Thanks! https://github.com/llvm/llvm-project/pull/132053 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] ad5cac3 - [lldb][debugserver] remove g/G packet handling from debugserver (#132127)
Author: Jason Molenda
Date: 2025-03-20T13:32:52-07:00
New Revision: ad5cac3b06c3cb41397acc1fc96beae9b460f20c
URL:
https://github.com/llvm/llvm-project/commit/ad5cac3b06c3cb41397acc1fc96beae9b460f20c
DIFF:
https://github.com/llvm/llvm-project/commit/ad5cac3b06c3cb41397acc1fc96beae9b460f20c.diff
LOG: [lldb][debugserver] remove g/G packet handling from debugserver (#132127)
In 2013 we added the QSaveRegisterState and QRestoreRegisterState
packets to checkpoint a thread's register state while executing an
inferior function call, instead of using the g packet to read all
registers into lldb, then the G packet to set them again after the func
call.
Since then, lldb has not sent g/G (except as a bug) - it either asks for
registers individually (p/P) or or asks debugserver to save and restore
the entire register set with these lldb extensions.
Felipe recently had a codepath that fell back to using g/G and found
that it does not work with the modern signed fp/sp/pc/lr registers that
we can get -- it sidesteps around the clearing of the non-addressable
bits that we do when reading/writing them, and results in a crash. (
https://github.com/llvm/llvm-project/pull/132079 )
Instead of fixing that issue, I am removing g/G from debugserver because
it's not needed by lldb, and it will would be easy for future bugs to
creep in to this packet that lldb should not use, but it can
accidentally fall back to and result in subtle bugs.
This does mean that a debugger using debugserver on darwin which doesn't
use QSaveRegisterState/QRestoreRegisterState will need to fall back to
reading & writing each register individually. I'm open to re-evaluating
this decision if this proves to be needed, and supporting these lldb
extensions is onerous.
Added:
Modified:
lldb/test/API/tools/lldb-server/register-reading/TestGdbRemoteGPacket.py
lldb/tools/debugserver/source/RNBRemote.cpp
lldb/tools/debugserver/source/RNBRemote.h
Removed:
diff --git
a/lldb/test/API/tools/lldb-server/register-reading/TestGdbRemoteGPacket.py
b/lldb/test/API/tools/lldb-server/register-reading/TestGdbRemoteGPacket.py
index 5bae98d326762..4c2d23f02ba3c 100644
--- a/lldb/test/API/tools/lldb-server/register-reading/TestGdbRemoteGPacket.py
+++ b/lldb/test/API/tools/lldb-server/register-reading/TestGdbRemoteGPacket.py
@@ -25,39 +25,6 @@ def _extract_register_value(reg_info, reg_bank, byte_order,
bytes_per_entry=8):
class TestGdbRemoteGPacket(gdbremote_testcase.GdbRemoteTestCaseBase):
-@skipUnlessDarwin # G packet not supported
-def test_g_packet(self):
-self.build()
-self.prep_debug_monitor_and_inferior()
-self.test_sequence.add_log_lines(
-[
-"read packet: $g#67",
-{
-"direction": "send",
-"regex": r"^\$(.+)#[0-9a-fA-F]{2}$",
-"capture": {1: "register_bank"},
-},
-],
-True,
-)
-context = self.expect_gdbremote_sequence()
-register_bank = context.get("register_bank")
-self.assertNotEqual(register_bank[0], "E")
-
-self.test_sequence.add_log_lines(
-[
-"read packet: $G" + register_bank + "#00",
-{
-"direction": "send",
-"regex": r"^\$(.+)#[0-9a-fA-F]{2}$",
-"capture": {1: "G_reply"},
-},
-],
-True,
-)
-context = self.expect_gdbremote_sequence()
-self.assertNotEqual(context.get("G_reply")[0], "E")
-
@skipIf(archs=no_match(["x86_64"]))
def g_returns_correct_data(self, with_suffix):
procs = self.prep_debug_monitor_and_inferior()
diff --git a/lldb/tools/debugserver/source/RNBRemote.cpp
b/lldb/tools/debugserver/source/RNBRemote.cpp
index c225ac1667b54..eb7c5ca32c02a 100644
--- a/lldb/tools/debugserver/source/RNBRemote.cpp
+++ b/lldb/tools/debugserver/source/RNBRemote.cpp
@@ -243,14 +243,10 @@ void RNBRemote::CreatePacketTable() {
"Read memory"));
t.push_back(Packet(read_register, &RNBRemote::HandlePacket_p, NULL, "p",
"Read one register"));
- t.push_back(Packet(read_general_regs, &RNBRemote::HandlePacket_g, NULL, "g",
- "Read registers"));
t.push_back(Packet(write_memory, &RNBRemote::HandlePacket_M, NULL, "M",
"Write memory"));
t.push_back(Packet(write_register, &RNBRemote::HandlePacket_P, NULL, "P",
"Write one register"));
- t.push_back(Packet(write_general_regs, &RNBRemote::HandlePacket_G, NULL, "G",
- "Write registers"));
t.push_back(Packet(insert_mem_bp, &RNBRemote::HandlePacket_z, NULL, "Z0",
"Insert memory breakpoint"));
t.push_back(Packet(remove_mem_bp, &RNBRemote::HandlePacket_z, NULL
[Lldb-commits] [compiler-rt] [libcxx] [libcxxabi] [libunwind] [lldb] [llvm] [compiler-rt] Disable LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON on AIX. (PR #131200)
@@ -223,6 +223,13 @@ endif()
# This can be used to detect whether we're in the runtimes build.
set(LLVM_RUNTIMES_BUILD ON)
+if (LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND UNIX AND ${CMAKE_SYSTEM_NAME}
MATCHES "AIX")
+ # Set LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF as AIX doesn't support it
+ message(WARNING
+ "LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON is not supported on AIX.
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is set to OFF.")
+ set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR OFF CACHE BOOL "" FORCE)
+endif()
DanielCChen wrote:
We consider it as recoverable mis-config. Because the driver and the cmake are
consistent regarding where to search and output the library, users shouldn't be
surprised as the compile/linking/execution should be all working. The only
thing that may surprise users is that if they search for the library and find
out it is not in the `lib/${triple}` path when they have the option ON. For
that, we have the warning message in the build.log to explain why.
My first attempt actually followed what APPLE does: check `if
(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)` at a few places to neglect
the option. I later adopted @arichardson suggestion to put the check at one
central place.
https://github.com/llvm/llvm-project/pull/131200
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose the Target API lock through the SB API (PR #131404)
JDevlieghere wrote: I'm not sure I can work around this with the version of SWIG installed on the bots. I've created an RFC about bumping the SWIG version: https://discourse.llvm.org/t/rfc-bumping-the-minimum-swig-version-to-4-1-0/85377 https://github.com/llvm/llvm-project/pull/131404 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] Revert "Reland: [clang] preserve class type sugar when taking pointer to member" (PR #132280)
https://github.com/mizvekov closed https://github.com/llvm/llvm-project/pull/132280 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] Revert "Reland: [clang] preserve class type sugar when taking pointer to member" (PR #132280)
llvm-ci wrote: LLVM Buildbot has detected a new failure on builder `openmp-offload-amdgpu-runtime` running on `omp-vega20-0` while building `clang-tools-extra,clang,lldb` at step 7 "Add check check-offload". Full details are available at: https://lab.llvm.org/buildbot/#/builders/30/builds/18071 Here is the relevant piece of the build log for the reference ``` Step 7 (Add check check-offload) failure: test (failure) TEST 'libomptarget :: amdgcn-amd-amdhsa :: offloading/gpupgo/pgo2.c' FAILED Exit Code: 1 Command Output (stdout): -- # RUN: at line 1 /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./bin/clang -fopenmp-I /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test -I /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -L /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload -L /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./lib -L /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -nogpulib -Wl,-rpath,/home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload -Wl,-rpath,/home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -Wl,-rpath,/home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./lib -fopenmp-targets=amdgcn-amd-amdhsa /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test/offloading/gpupgo/pgo2.c -o /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload/test/amdgcn-amd-amdhsa/offloading/gpupgo/Output/pgo2.c.tmp /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./lib/libomptarget.devicertl.a -fprofile-generate # executed command: /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./bin/clang -fopenmp -I /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test -I /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -L /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload -L /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./lib -L /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -nogpulib -Wl,-rpath,/home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload -Wl,-rpath,/home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -Wl,-rpath,/home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./lib -fopenmp-targets=amdgcn-amd-amdhsa /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test/offloading/gpupgo/pgo2.c -o /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload/test/amdgcn-amd-amdhsa/offloading/gpupgo/Output/pgo2.c.tmp /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./lib/libomptarget.devicertl.a -fprofile-generate # note: command had no output on stdout or stderr # RUN: at line 2 env LLVM_PROFILE_FILE=pgo2.c.llvm.profraw /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload/test/amdgcn-amd-amdhsa/offloading/gpupgo/Output/pgo2.c.tmp 2>&1 # executed command: env LLVM_PROFILE_FILE=pgo2.c.llvm.profraw /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload/test/amdgcn-amd-amdhsa/offloading/gpupgo/Output/pgo2.c.tmp # note: command had no output on stdout or stderr # RUN: at line 4 llvm-profdata show --all-functions --counts pgo2.c.llvm.profraw | /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./bin/FileCheck /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test/offloading/gpupgo/pgo2.c --check-prefix="LLVM-HOST" # executed command: llvm-profdata show --all-functions --counts pgo2.c.llvm.profraw # note: command had no output on stdout or stderr # executed command: /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./bin/FileCheck /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test/offloading/gpupgo/pgo2.c --check-prefix=LLVM-HOST # note: command had no output on stdout or stderr # RUN: at line 7 llvm-profdata show --all-functions --counts amdgcn-amd-amdhsa.pgo2.c.llvm.profraw | /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./bin/FileCheck /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test/offloading/gpupgo/pgo2.c --check-prefix="LLVM-DEVICE" # executed command: llvm-profdata show --all-functions --counts amdgcn-amd-amdhsa.pgo2.c.llvm.profraw # note: command had no output on stdout or stderr # executed command: /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./bin/FileCheck /home/ompworke
[Lldb-commits] [compiler-rt] [libcxx] [libcxxabi] [libunwind] [lldb] [llvm] [compiler-rt] Disable LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON on AIX. (PR #131200)
@@ -223,6 +223,13 @@ endif()
# This can be used to detect whether we're in the runtimes build.
set(LLVM_RUNTIMES_BUILD ON)
+if (LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND UNIX AND ${CMAKE_SYSTEM_NAME}
MATCHES "AIX")
+ # Set LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF as AIX doesn't support it
+ message(WARNING
+ "LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON is not supported on AIX.
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is set to OFF.")
+ set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR OFF CACHE BOOL "" FORCE)
+endif()
ldionne wrote:
What we do for Apple is also bad, and we should fix that. In fact we want to
make it work on Apple platforms but we haven't gotten to it yet.
The reason for my push back is that we don't want to have configuration logic,
especially when it's imperative, in the CMake files. We're working really hard
to get away from that and that's why I care so strongly about it.
https://github.com/llvm/llvm-project/pull/131200
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Minidump]Update MinidumpFileBuilder to read and write in chunks (PR #129307)
@@ -142,6 +142,13 @@ class MinidumpFileBuilder {
lldb_private::Status AddDirectory(llvm::minidump::StreamType type,
uint64_t stream_size);
lldb::offset_t GetCurrentDataEndOffset() const;
+
+ // Read a memory region from the process and write it to the file
+ // in fixed size chunks.
+ lldb_private::Status ReadWriteMemoryInChunks(
+ const std::unique_ptr &data_up,
+ const lldb_private::CoreFileMemoryRange &range, uint64_t *bytes_read);
+
Jlalond wrote:
Talked with Greg offline, I want to add this to process, but the effort to unit
test it will delay this patch more than I would like, so I'll follow up this
patch with a refactor of this beahvior into `Process`
https://github.com/llvm/llvm-project/pull/129307
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adding support for cancelling a request. (PR #130169)
JDevlieghere wrote: > My logic behind the `lldb_dap::protocol` types was to keep them as POD data > and to not have much (if any) logic in them so that if we need to move the > data between threads or queues we can be relatively confident that we're not > dealing data races. In swift terms (I'm more familiar with swift than c++), > the `lldb_dap::protocol` types would be `struct`'s that are all `Sendable`. Totally, and I think that's a great design, and not something that would change in my suggestion, right? > I do like the more simplified `operator()` idea to help deal with the > cancelled / interrupted, my existing solution was done to support the > LegacyRequestHandlers since they're sending the responses as raw > `json::Value`'s still, but with the more unified approach we could handle the > cancellation in the `operator()` body. If we want to support cancellation before moving all the request over to the protocol class, can we *temporarily* store both the JSON and the Protocol in the class we instantiate per request (whether that's the RequestHandler itself, or a class wrapping it) and use whichever one we need for that given request? https://github.com/llvm/llvm-project/pull/130169 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Interrupt should reset outstanding SIGSTOP (PR #132128)
https://github.com/JDevlieghere approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/132128 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adding a DAPError for showing users error messages. (PR #132255)
https://github.com/ashgti created
https://github.com/llvm/llvm-project/pull/132255
The `DAPError` can be used to craft an error message that is displayed to a
user (with showUser=true).
Any request handler implementation using subclassing `RequestHandler<>` should
be able to use this.
I updated SourceRequestHandler to report DAPError's specifically.
>From a696c1c3ce5cf0f652e0a016c5d5d422b2ae24d3 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Thu, 20 Mar 2025 10:08:53 -0700
Subject: [PATCH] [lldb-dap] Adding a DAPError for showing users error
messages.
The `DAPError` can be used to craft an error message that is displayed to a
user (with showUser=true).
Any request handler implementation using subclassing `RequestHandler<>` should
be able to use this.
I updated SourceRequestHandler to report DAPError's specifically.
---
lldb/tools/lldb-dap/CMakeLists.txt| 1 +
lldb/tools/lldb-dap/DAPError.cpp | 26 +++
lldb/tools/lldb-dap/DAPError.h| 33 +++
lldb/tools/lldb-dap/Handler/RequestHandler.h | 28
.../lldb-dap/Handler/SourceRequestHandler.cpp | 4 +--
5 files changed, 83 insertions(+), 9 deletions(-)
create mode 100644 lldb/tools/lldb-dap/DAPError.cpp
create mode 100644 lldb/tools/lldb-dap/DAPError.h
diff --git a/lldb/tools/lldb-dap/CMakeLists.txt
b/lldb/tools/lldb-dap/CMakeLists.txt
index 93c5ee4426783..e9773db7586e6 100644
--- a/lldb/tools/lldb-dap/CMakeLists.txt
+++ b/lldb/tools/lldb-dap/CMakeLists.txt
@@ -18,6 +18,7 @@ add_lldb_tool(lldb-dap
Breakpoint.cpp
BreakpointBase.cpp
DAP.cpp
+ DAPError.cpp
DAPLog.cpp
EventHelper.cpp
ExceptionBreakpoint.cpp
diff --git a/lldb/tools/lldb-dap/DAPError.cpp b/lldb/tools/lldb-dap/DAPError.cpp
new file mode 100644
index 0..044c9b48d61c6
--- /dev/null
+++ b/lldb/tools/lldb-dap/DAPError.cpp
@@ -0,0 +1,26 @@
+//===-- DAPError.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 "DAPError.h"
+#include "llvm/Support/Error.h"
+#include
+
+namespace lldb_dap {
+
+char DAPError::ID;
+
+DAPError::DAPError(std::string message, bool show_user)
+: m_message(message), m_show_user(show_user) {}
+
+void DAPError::log(llvm::raw_ostream &OS) const { OS << m_message; }
+
+std::error_code DAPError::convertToErrorCode() const {
+ return llvm::inconvertibleErrorCode();
+}
+
+} // namespace lldb_dap
diff --git a/lldb/tools/lldb-dap/DAPError.h b/lldb/tools/lldb-dap/DAPError.h
new file mode 100644
index 0..b990bcdb5ceb0
--- /dev/null
+++ b/lldb/tools/lldb-dap/DAPError.h
@@ -0,0 +1,33 @@
+//===-- DAPError.h
===//
+//
+// 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 "llvm/Support/Error.h"
+#include
+
+namespace lldb_dap {
+
+/// An Error that is reported as a DAP Error Message, which may be presented to
+/// the user.
+class DAPError : public llvm::ErrorInfo {
+public:
+ static char ID;
+
+ DAPError(std::string message, bool show_user = false);
+
+ void log(llvm::raw_ostream &OS) const override;
+ std::error_code convertToErrorCode() const override;
+
+ const std::string &getMessage() const { return m_message; }
+ bool getShowUser() const { return m_show_user; }
+
+private:
+ std::string m_message;
+ bool m_show_user;
+};
+
+} // namespace lldb_dap
diff --git a/lldb/tools/lldb-dap/Handler/RequestHandler.h
b/lldb/tools/lldb-dap/Handler/RequestHandler.h
index d327820224a30..01eaf3a6cfe65 100644
--- a/lldb/tools/lldb-dap/Handler/RequestHandler.h
+++ b/lldb/tools/lldb-dap/Handler/RequestHandler.h
@@ -10,11 +10,13 @@
#define LLDB_TOOLS_LLDB_DAP_HANDLER_HANDLER_H
#include "DAP.h"
+#include "DAPError.h"
#include "DAPLog.h"
#include "Protocol/ProtocolBase.h"
#include "Protocol/ProtocolRequests.h"
#include "lldb/API/SBError.h"
#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Error.h"
#include "llvm/Support/JSON.h"
#include
#include
@@ -118,20 +120,32 @@ class RequestHandler : public BaseRequestHandler {
std::string parse_failure;
llvm::raw_string_ostream OS(parse_failure);
root.printErrorContext(request.arguments, OS);
+
+ protocol::ErrorMessage error;
+ error.format = parse_failure;
+
response.success = false;
- response.message = parse_failure;
+ response.body = std::move(error);
+
dap.Send(response);
return;
}
-auto body = Run(a
[Lldb-commits] [lldb] [lldb-dap] Adding a DAPError for showing users error messages. (PR #132255)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: John Harrison (ashgti)
Changes
The `DAPError` can be used to craft an error message that is displayed to a
user (with showUser=true).
Any request handler implementation using subclassing `RequestHandler<>`
should be able to use this.
I updated SourceRequestHandler to report DAPError's specifically.
---
Full diff: https://github.com/llvm/llvm-project/pull/132255.diff
5 Files Affected:
- (modified) lldb/tools/lldb-dap/CMakeLists.txt (+1)
- (added) lldb/tools/lldb-dap/DAPError.cpp (+26)
- (added) lldb/tools/lldb-dap/DAPError.h (+33)
- (modified) lldb/tools/lldb-dap/Handler/RequestHandler.h (+21-7)
- (modified) lldb/tools/lldb-dap/Handler/SourceRequestHandler.cpp (+2-2)
``diff
diff --git a/lldb/tools/lldb-dap/CMakeLists.txt
b/lldb/tools/lldb-dap/CMakeLists.txt
index 93c5ee4426783..e9773db7586e6 100644
--- a/lldb/tools/lldb-dap/CMakeLists.txt
+++ b/lldb/tools/lldb-dap/CMakeLists.txt
@@ -18,6 +18,7 @@ add_lldb_tool(lldb-dap
Breakpoint.cpp
BreakpointBase.cpp
DAP.cpp
+ DAPError.cpp
DAPLog.cpp
EventHelper.cpp
ExceptionBreakpoint.cpp
diff --git a/lldb/tools/lldb-dap/DAPError.cpp b/lldb/tools/lldb-dap/DAPError.cpp
new file mode 100644
index 0..044c9b48d61c6
--- /dev/null
+++ b/lldb/tools/lldb-dap/DAPError.cpp
@@ -0,0 +1,26 @@
+//===-- DAPError.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 "DAPError.h"
+#include "llvm/Support/Error.h"
+#include
+
+namespace lldb_dap {
+
+char DAPError::ID;
+
+DAPError::DAPError(std::string message, bool show_user)
+: m_message(message), m_show_user(show_user) {}
+
+void DAPError::log(llvm::raw_ostream &OS) const { OS << m_message; }
+
+std::error_code DAPError::convertToErrorCode() const {
+ return llvm::inconvertibleErrorCode();
+}
+
+} // namespace lldb_dap
diff --git a/lldb/tools/lldb-dap/DAPError.h b/lldb/tools/lldb-dap/DAPError.h
new file mode 100644
index 0..b990bcdb5ceb0
--- /dev/null
+++ b/lldb/tools/lldb-dap/DAPError.h
@@ -0,0 +1,33 @@
+//===-- DAPError.h
===//
+//
+// 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 "llvm/Support/Error.h"
+#include
+
+namespace lldb_dap {
+
+/// An Error that is reported as a DAP Error Message, which may be presented to
+/// the user.
+class DAPError : public llvm::ErrorInfo {
+public:
+ static char ID;
+
+ DAPError(std::string message, bool show_user = false);
+
+ void log(llvm::raw_ostream &OS) const override;
+ std::error_code convertToErrorCode() const override;
+
+ const std::string &getMessage() const { return m_message; }
+ bool getShowUser() const { return m_show_user; }
+
+private:
+ std::string m_message;
+ bool m_show_user;
+};
+
+} // namespace lldb_dap
diff --git a/lldb/tools/lldb-dap/Handler/RequestHandler.h
b/lldb/tools/lldb-dap/Handler/RequestHandler.h
index d327820224a30..01eaf3a6cfe65 100644
--- a/lldb/tools/lldb-dap/Handler/RequestHandler.h
+++ b/lldb/tools/lldb-dap/Handler/RequestHandler.h
@@ -10,11 +10,13 @@
#define LLDB_TOOLS_LLDB_DAP_HANDLER_HANDLER_H
#include "DAP.h"
+#include "DAPError.h"
#include "DAPLog.h"
#include "Protocol/ProtocolBase.h"
#include "Protocol/ProtocolRequests.h"
#include "lldb/API/SBError.h"
#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Error.h"
#include "llvm/Support/JSON.h"
#include
#include
@@ -118,20 +120,32 @@ class RequestHandler : public BaseRequestHandler {
std::string parse_failure;
llvm::raw_string_ostream OS(parse_failure);
root.printErrorContext(request.arguments, OS);
+
+ protocol::ErrorMessage error;
+ error.format = parse_failure;
+
response.success = false;
- response.message = parse_failure;
+ response.body = std::move(error);
+
dap.Send(response);
return;
}
-auto body = Run(arguments);
-// FIXME: Add a dedicated DAPError for enhanced errors that are
-// user-visibile.
+llvm::Expected body = Run(arguments);
if (auto Err = body.takeError()) {
+ protocol::ErrorMessage error;
+ if (llvm::Error unhandled = llvm::handleErrors(
+ std::move(Err), [&](const DAPError &E) -> llvm::Error {
+error.format = E.getMessage();
+error.showUser = E.getShowUser();
+error.id = E.convertToErrorCode().value();
+// TODO: We could add url/urlLabel to
[Lldb-commits] [lldb] [lldb-dap] Adding support for cancelling a request. (PR #130169)
@@ -96,7 +115,7 @@ Expected> Transport::Read() {
return createStringError(
formatv("invalid content length {0}", *raw_length).str());
- Expected raw_json = ReadFull(*input, length);
ashgti wrote:
> I don't know if this helps you (since you still have to use a dedicated API
> instead of `select(2)`), but `lldb_private::Pipe` works around this by
> creating a named pipe with an random name (from what I've read, that's
> actually how windows implements anonymous pipes internally).
The trouble is that when we run the debugger as an
[DebugAdapterExecutable](https://code.visualstudio.com/api/references/vscode-api#DebugAdapterExecutable)
the input stream is `stdin`. Unless we want to make Windows always use a local
socket
[DebugAdapterServer](https://code.visualstudio.com/api/references/vscode-api#DebugAdapterServer)
or named pipes
[DebugAdapterNamedPipeServer](https://code.visualstudio.com/api/references/vscode-api#DebugAdapterNamedPipeServer)
we'd need to have some other mechanism for supporting reading with a timeout
on Windows.
But I'm also not sure if that actually matters. VSCode never closes stdin, so
it never gets an EOF. When the debug session ends, it sends a `kill -15`
https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/debug/node/debugAdapter.ts#L290-L303
so I'm not sure if we need to ensure the Transport returns, but we do have
an existing test that we shutdown after the `disconnect` request is sent.
https://github.com/llvm/llvm-project/pull/130169
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adding a DAPError for showing users error messages. (PR #132255)
https://github.com/JDevlieghere approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/132255 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Reapply LLDB-Telemetry TargetInfo branch (pr/127834) (PR #132043)
https://github.com/oontvoo updated
https://github.com/llvm/llvm-project/pull/132043
>From 9f0a47af2b7fdb90e4fa4cc7f8f97c840af1d2bc Mon Sep 17 00:00:00 2001
From: Vy Nguyen
Date: Wed, 19 Mar 2025 10:44:12 -0400
Subject: [PATCH 1/7] Reapply "[LLDB][Telemetry]Define TargetInfo for
collecting data about a target (#127834)"
This reverts commit 7dbcdd578cd4d37b1f4094dbd17556be6382f1cc.
---
lldb/include/lldb/Core/Telemetry.h| 74 +--
lldb/source/Core/Telemetry.cpp| 25 ++-
.../source/Interpreter/CommandInterpreter.cpp | 2 +-
lldb/source/Target/Process.cpp| 21 ++
lldb/source/Target/Target.cpp | 21 ++
5 files changed, 134 insertions(+), 9 deletions(-)
diff --git a/lldb/include/lldb/Core/Telemetry.h
b/lldb/include/lldb/Core/Telemetry.h
index 29ec36b2d64d1..28897f283dc55 100644
--- a/lldb/include/lldb/Core/Telemetry.h
+++ b/lldb/include/lldb/Core/Telemetry.h
@@ -23,9 +23,12 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
+#include
namespace lldb_private {
namespace telemetry {
@@ -46,12 +49,18 @@ struct LLDBConfig : public ::llvm::telemetry::Config {
// Specifically:
// - Length: 8 bits
// - First two bits (MSB) must be 11 - the common prefix
+// - Last two bits (LSB) are reserved for grand-children of LLDBTelemetryInfo
// If any of the subclass has descendents, those descendents
-// must have their LLDBEntryKind in the similar form (ie., share common prefix)
+// must have their LLDBEntryKind in the similar form (ie., share common prefix
+// and differ by the last two bits)
struct LLDBEntryKind : public ::llvm::telemetry::EntryKind {
- static const llvm::telemetry::KindType BaseInfo = 0b1100;
- static const llvm::telemetry::KindType CommandInfo = 0b1101;
- static const llvm::telemetry::KindType DebuggerInfo = 0b11000100;
+ // clang-format off
+ static const llvm::telemetry::KindType BaseInfo= 0b1100;
+ static const llvm::telemetry::KindType CommandInfo = 0b1101;
+ static const llvm::telemetry::KindType DebuggerInfo= 0b11001000;
+ static const llvm::telemetry::KindType ExecModuleInfo = 0b11000100;
+ static const llvm::telemetry::KindType ProcessExitInfo = 0b11001100;
+ // clang-format on
};
/// Defines a convenient type for timestamp of various events.
@@ -89,7 +98,7 @@ struct CommandInfo : public LLDBBaseTelemetryInfo {
/// session. Necessary because we'd send off an entry right before a
command's
/// execution and another right after. This is to avoid losing telemetry if
/// the command does not execute successfully.
- uint64_t command_id;
+ uint64_t command_id = 0;
/// The command name(eg., "breakpoint set")
std::string command_name;
/// These two fields are not collected by default due to PII risks.
@@ -116,7 +125,7 @@ struct CommandInfo : public LLDBBaseTelemetryInfo {
void serialize(llvm::telemetry::Serializer &serializer) const override;
- static uint64_t GetNextId();
+ static uint64_t GetNextID();
private:
// We assign each command (in the same session) a unique id so that their
@@ -146,6 +155,59 @@ struct DebuggerInfo : public LLDBBaseTelemetryInfo {
void serialize(llvm::telemetry::Serializer &serializer) const override;
};
+struct ExecutableModuleInfo : public LLDBBaseTelemetryInfo {
+ lldb::ModuleSP exec_mod;
+ /// The same as the executable-module's UUID.
+ UUID uuid;
+ /// PID of the process owned by this target.
+ lldb::pid_t pid = LLDB_INVALID_PROCESS_ID;
+ /// The triple of this executable module.
+ std::string triple;
+
+ /// If true, this entry was emitted at the beginning of an event (eg., before
+ /// the executable is set). Otherwise, it was emitted at the end of an
+ /// event (eg., after the module and any dependency were loaded.)
+ bool is_start_entry = false;
+
+ ExecutableModuleInfo() = default;
+
+ llvm::telemetry::KindType getKind() const override {
+return LLDBEntryKind::ExecModuleInfo;
+ }
+
+ static bool classof(const TelemetryInfo *T) {
+// Subclasses of this is also acceptable
+return (T->getKind() & LLDBEntryKind::ExecModuleInfo) ==
+ LLDBEntryKind::ExecModuleInfo;
+ }
+ void serialize(llvm::telemetry::Serializer &serializer) const override;
+};
+
+/// Describes an exit status.
+struct ExitDescription {
+ int exit_code;
+ std::string description;
+};
+
+struct ProcessExitInfo : public LLDBBaseTelemetryInfo {
+ // The executable-module's UUID.
+ UUID module_uuid;
+ lldb::pid_t pid = LLDB_INVALID_PROCESS_ID;
+ bool is_start_entry = false;
+ std::optional exit_desc;
+
+ llvm::telemetry::KindType getKind() const override {
+return LLDBEntryKind::ProcessExitInfo;
+ }
+
+ static bool classof(const TelemetryInfo *T) {
+// Subclasses of this is also acceptable
+return (T->getKind() & LLDBEntryKind::ProcessExitInfo) ==
+ LLDBEntryKind::ProcessExitInfo;
+ }
+ void serialize(llvm::t
[Lldb-commits] [lldb] [lldb-dap] Adding support for cancelling a request. (PR #130169)
@@ -0,0 +1,55 @@
+//===-- CancelRequestHandler.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 "Handler/RequestHandler.h"
+#include "Protocol/ProtocolRequests.h"
+#include "llvm/Support/Error.h"
+
+using namespace lldb_dap;
+using namespace lldb_dap::protocol;
+
+namespace lldb_dap {
+
+/// The `cancel` request is used by the client in two situations:
+///
+/// - to indicate that it is no longer interested in the result produced by a
+/// specific request issued earlier
+/// - to cancel a progress sequence.
+///
+/// Clients should only call this request if the corresponding capability
JDevlieghere wrote:
The documentation contains some wording with recommendations (i.e. "should").
Do we expect clients to read this? Is this coming from the DAP documentation?
Otherwise it seems like this should be aimed at us, server implementers.
https://github.com/llvm/llvm-project/pull/130169
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adding support for cancelling a request. (PR #130169)
@@ -0,0 +1,55 @@
+//===-- CancelRequestHandler.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 "Handler/RequestHandler.h"
+#include "Protocol/ProtocolRequests.h"
+#include "llvm/Support/Error.h"
+
+using namespace lldb_dap;
+using namespace lldb_dap::protocol;
+
+namespace lldb_dap {
+
+/// The `cancel` request is used by the client in two situations:
+///
+/// - to indicate that it is no longer interested in the result produced by a
+/// specific request issued earlier
+/// - to cancel a progress sequence.
+///
+/// Clients should only call this request if the corresponding capability
+/// `supportsCancelRequest` is true.
+///
+/// This request has a hint characteristic: a debug adapter can only be
+/// expected to make a 'best effort' in honoring this request but there are no
+/// guarantees.
+///
+/// The `cancel` request may return an error if it could not cancel
+/// an operation but a client should refrain from presenting this error to end
+/// users.
+///
+/// The request that got cancelled still needs to send a response back.
+/// This can either be a normal result (`success` attribute true) or an error
+/// response (`success` attribute false and the `message` set to `cancelled`).
+///
+/// Returning partial results from a cancelled request is possible but please
+/// note that a client has no generic way for detecting that a response is
+/// partial or not.
+///
+/// The progress that got cancelled still needs to send a `progressEnd` event
+/// back.
+///
+/// A client should not assume that progress just got cancelled after sending
+/// the `cancel` request.
JDevlieghere wrote:
For example, could this be written as follows?
```suggestion
/// A client cannot assume that progress just got cancelled after sending
/// the `cancel` request.
```
https://github.com/llvm/llvm-project/pull/130169
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adding support for cancelling a request. (PR #130169)
@@ -777,28 +798,134 @@ llvm::Error DAP::Disconnect(bool terminateDebuggee) {
return ToError(error);
}
+template
+static std::optional getArgumentsIfRequest(const protocol::Message &pm,
+ llvm::StringLiteral command) {
+ auto *const req = std::get_if(&pm);
+ if (!req || req->command != command)
+return std::nullopt;
+
+ T args;
+ llvm::json::Path::Root root;
+ if (!fromJSON(req->arguments, args, root)) {
+return std::nullopt;
+ }
+
+ return std::move(args);
+}
+
llvm::Error DAP::Loop() {
- auto cleanup = llvm::make_scope_exit([this]() {
+ std::deque queue;
+ std::condition_variable queue_cv;
+ std::mutex queue_mutex;
+ std::future queue_reader = std::async([&]() -> llvm::Error {
+llvm::set_thread_name(transport.GetClientName() + ".transport_handler");
+auto cleanup = llvm::make_scope_exit([&]() {
+ // Ensure we're marked as disconnecting when the reader exits.
+ disconnecting = true;
+ queue_cv.notify_all();
+});
+
+while (!disconnecting) {
+ llvm::Expected> next =
+ transport.Read(std::chrono::seconds(1));
+ bool timeout = false;
+ if (llvm::Error Err = llvm::handleErrors(
+ next.takeError(),
+ [&](std::unique_ptr Err) -> llvm::Error {
JDevlieghere wrote:
Do we only want to handle StringError?
```suggestion
[&](std::unique_ptr Err) -> llvm::Error {
```
https://github.com/llvm/llvm-project/pull/130169
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adding support for cancelling a request. (PR #130169)
https://github.com/JDevlieghere commented: (looks like I didn't submit my comments yesterday) https://github.com/llvm/llvm-project/pull/130169 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
cmtice wrote: I've fixed all the style/format requests. I ran into some difficulties with the structured error handling requests: - DiagnosticError has only one constructor, which only takes an error code. On examning how it's called/used in other places, it doesn't look like it's designed to be used as you have suggested. - Based on the way DiagnosticError is use, I've created a new error class, DILDiagnosticError, patterned after the OptionParserError clas, which DOES make use of DiagnosticError. - I have not been able to discover any way of converting DILDiagnosticError or DiagnosticDetail into an llvm::Error at all. - The only way I could find to convert a DILDiagnosticError into an LLDB::Status, was to extract the DiagnosticDetail message and create the LLDB::Status around that. - We currently still have to leave the errors as LLDB::Status errors, because the calls into & out of GetVariableValueForExpressionPath have no way (at the moment) of handling structured errors (i.e. DiagnosticDetails or DILDiagnosticErrors). We should probably change that in the future, but I would prefer to do that in a different PR. So I've done the best I can to honor your error handling request, but it doesn't feel very satisfactory. https://github.com/llvm/llvm-project/pull/120971 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver][MacOSX] Work around sanitizer misaligned address errors when reading exception data (PR #132193)
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 17b4be8f63a9a2c17290c8540d84f17a370b1915
223d85c6b2f5509f704d598bae974a98e5bf6bcb --extensions cpp,h --
lldb/tools/debugserver/source/MacOSX/MachException.cpp
lldb/tools/debugserver/source/MacOSX/MachException.h
``
View the diff from clang-format here.
``diff
diff --git a/lldb/tools/debugserver/source/MacOSX/MachException.cpp
b/lldb/tools/debugserver/source/MacOSX/MachException.cpp
index d05b47cd9b..5a652d9339 100644
--- a/lldb/tools/debugserver/source/MacOSX/MachException.cpp
+++ b/lldb/tools/debugserver/source/MacOSX/MachException.cpp
@@ -18,21 +18,21 @@
#include "PThreadMutex.h"
#include "SysSignal.h"
#include
+#include
#include
#include
-#include
-static void AppendExceptionData(
-std::vector &out,
-mach_exception_data_t Data, mach_msg_type_number_t Count) {
+static void AppendExceptionData(std::vector &out,
+mach_exception_data_t Data,
+mach_msg_type_number_t Count) {
mach_exception_data_type_t Buf;
for (mach_msg_type_number_t i = 0; i < Count; ++i) {
// The input Data we receive need not be aligned correctly.
// Perform an unaligned copy by pretending we're dealing with
// a char* buffer. This is required to work around UBSAN/ASAN
// "misaligned address" errors.
-auto * src = reinterpret_cast(&Buf);
-auto * dst = reinterpret_cast(Data + i);
+auto *src = reinterpret_cast(&Buf);
+auto *dst = reinterpret_cast(Data + i);
memcpy(dst, src, sizeof(mach_exception_data_type_t));
out.push_back(Buf);
}
@@ -115,7 +115,8 @@ catch_mach_exception_raise(mach_port_t exc_port,
mach_port_t thread_port,
std::vector exc_datas;
AppendExceptionData(exc_datas, exc_data, exc_data_count);
DNBLogThreaded("::%s ( exc_port = 0x%4.4x, thd_port = 0x%4.4x, tsk_port = "
- "0x%4.4x, exc_type = %d ( %s ), exc_data[%d] = { 0x%"
PRIx64 ", "
+ "0x%4.4x, exc_type = %d ( %s ), exc_data[%d] = { 0x%" PRIx64
+ ", "
"0x%" PRIx64 " })",
__FUNCTION__, exc_port, thread_port, task_port, exc_type,
MachException::Name(exc_type), exc_data_count,
``
https://github.com/llvm/llvm-project/pull/132193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][lldb-dap] Added support for "WriteMemory" request. (PR #131820)
@@ -0,0 +1,147 @@
+//===-- WriteMemoryRequestHandler.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 "DAP.h"
+#include "EventHelper.h"
+#include "JSONUtils.h"
+#include "RequestHandler.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/Support/Base64.h"
+
+namespace lldb_dap {
+
+// "WriteMemoryRequest": {
+// "allOf": [ { "$ref": "#/definitions/Request" }, {
+// "type": "object",
+// "description": "Writes bytes to memory at the provided location.\n
+// Clients should only call this request if the corresponding
+// capability `supportsWriteMemoryRequest` is true.",
+// "properties": {
+// "command": {
+// "type": "string",
+// "enum": [ "writeMemory" ]
+// },
+// "arguments": {
+// "$ref": "#/definitions/WriteMemoryArguments"
+// }
+// },
+// "required": [ "command", "arguments" ]
+// }]
+// },
+// "WriteMemoryArguments": {
+// "type": "object",
+// "description": "Arguments for `writeMemory` request.",
+// "properties": {
+// "memoryReference": {
+// "type": "string",
+// "description": "Memory reference to the base location to which
+// data should be written."
+// },
+// "offset": {
+// "type": "integer",
+// "description": "Offset (in bytes) to be applied to the reference
+// location before writing data. Can be negative."
+// },
+// "allowPartial": {
+// "type": "boolean",
+// "description": "Property to control partial writes. If true, the
+// debug adapter should attempt to write memory even if the entire
+// memory region is not writable. In such a case the debug adapter
+// should stop after hitting the first byte of memory that cannot be
+// written and return the number of bytes written in the response
+// via the `offset` and `bytesWritten` properties.\nIf false or
+// missing, a debug adapter should attempt to verify the region is
+// writable before writing, and fail the response if it is not."
+// },
+// "data": {
+// "type": "string",
+// "description": "Bytes to write, encoded using base64."
+// }
+// },
+// "required": [ "memoryReference", "data" ]
+// },
+// "WriteMemoryResponse": {
+// "allOf": [ { "$ref": "#/definitions/Response" }, {
+// "type": "object",
+// "description": "Response to `writeMemory` request.",
+// "properties": {
+// "body": {
+// "type": "object",
+// "properties": {
+// "offset": {
+// "type": "integer",
+// "description": "Property that should be returned when
+// `allowPartial` is true to indicate the offset of the first
+// byte of data successfully written. Can be negative."
+// },
+// "bytesWritten": {
+// "type": "integer",
+// "description": "Property that should be returned when
+// `allowPartial` is true to indicate the number of bytes
+// starting from address that were successfully written."
+// }
+// }
+// }
+// }
+// }]
+// },
+void WriteMemoryRequestHandler::operator()(
+const llvm::json::Object &request) const {
+ llvm::json::Object response;
+ llvm::json::Array response_writeMemory;
+ llvm::json::Object body;
+ FillResponse(request, response);
+
+ auto arguments = request.getObject("arguments");
+ llvm::StringRef memoryReference =
+ GetString(arguments, "memoryReference").value_or("");
+
+ auto addr_opt = DecodeMemoryReference(memoryReference);
+ if (!addr_opt.has_value()) {
+response["success"] = false;
+response["message"] =
+"Malformed memory reference: " + memoryReference.str();
+dap.SendJSON(llvm::json::Value(std::move(response)));
+return;
+ }
+
+ lldb::addr_t address = *addr_opt;
+ lldb::addr_t address_offset =
+ address + GetInteger(arguments, "offset").value_or(0);
+
+ llvm::StringRef data64 = GetString(arguments, "data").value_or("");
+
+ std::string output;
+ lldb::SBError writeError;
+ int64_t countWrite = 0;
+
+ output = llvm::encodeBase64(data64);
+
+ // write the memory
+ if (!output.empty()) {
vogelsgesang wrote:
> [...] how I'm supposed to set something to null or empty or nil.
Not sure I understand the question. But maybe this is whe
[Lldb-commits] [lldb] [llvm] [lldb][lldb-dap] Implement jump to cursor (PR #130503)
https://github.com/vogelsgesang edited https://github.com/llvm/llvm-project/pull/130503 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [lldb][lldb-dap] Implement jump to cursor (PR #130503)
@@ -0,0 +1,118 @@
+//===-- GoToRequestHandler.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 "DAP.h"
+#include "EventHelper.h"
+#include "JSONUtils.h"
+
+namespace lldb_dap {
+
+/// Creates an \p StoppedEvent with the reason \a goto
+static void SendThreadGotoEvent(DAP &dap, lldb::tid_t thread_id) {
+ llvm::json::Object event(CreateEventObject("stopped"));
+ llvm::json::Object body;
+ body.try_emplace("reason", "goto");
+ body.try_emplace("description", "Paused on Jump To Cursor");
+ body.try_emplace("threadId", thread_id);
+ body.try_emplace("preserveFocusHint", false);
+ body.try_emplace("allThreadsStopped", true);
+
+ event.try_emplace("body", std::move(body));
+ dap.SendJSON(llvm::json::Value(std::move(event)));
+}
+
+// "GotoRequest": {
+// "allOf": [ { "$ref": "#/definitions/Request" }, {
+// "type": "object",
+// "description": "The request sets the location where the debuggee will
+// continue to run.\nThis makes it possible to skip the execution of code
or
+// to execute code again.\nThe code between the current location and the
+// goto target is not executed but skipped.\nThe debug adapter first sends
+// the response and then a `stopped` event with reason `goto`.\nClients
+// should only call this request if the corresponding capability
+// `supportsGotoTargetsRequest` is true (because only then goto targets
+// exist that can be passed as arguments).",
+//."properties": {
+// "command": {
+// "type": "string",
+// "enum": [ "goto" ]
+// },
+// "arguments": {
+// "$ref": "#/definitions/GotoArguments"
+// }
+// },
+// "required": [ "command", "arguments" ]
+// }]
+// }
+// "GotoArguments": {
+// "type": "object",
+// "description": "Arguments for `goto` request.",
+// "properties": {
+// "threadId": {
+// "type": "integer",
+// "description": "Set the goto target for this thread."
+// },
+// "targetId": {
+// "type": "integer",
+// "description": "The location where the debuggee will continue to run."
+// }
+// },
+// "required": [ "threadId", "targetId" ]
+// }
+// "GotoResponse": {
+// "allOf": [ { "$ref": "#/definitions/Response" }, {
+// "type": "object",
+// "description": "Response to `goto` request. This is just an
+// acknowledgement, so no body field is required."
+// }]
+// }
+void GoToRequestHandler::operator()(const llvm::json::Object &request) const {
+ llvm::json::Object response;
+ FillResponse(request, response);
+
+ auto SendError = [&](auto &&message) {
+response["success"] = false;
+response["message"] = message;
+dap.SendJSON(llvm::json::Value(std::move(response)));
+ };
vogelsgesang wrote:
IMO, we should not factor out this helper, because:
1. We already have a better abstraction.
2. This helper is encouraging to violate the debug adapter protocol.
**Better abstraction**: In #129155, @ashgti already introduced the
`protocol::Response` class, which also provides the `message` header. In
#130090, those messages got integrated with our request handlers. IMO, we
should change this PR to use the new mechanism introduced in #130090, instead
of using the legacy mechanism.
**Violation of the debug adapter protocol specification**: This helper sets the
message to an arbitrary string, such as `"Arguments is empty"`. However, this
is not the correct usage of DAP.
The `message` field of the
[Response](https://microsoft.github.io/debug-adapter-protocol/specification#Base_Protocol_Response)
should be a machine-readable enum (`cancelled`, `notStopped`, ...). It should
not contain the human-readable the error message and will not be displayed to
users.
Instead, the user-readable message should use the
[ErrorResponse](https://microsoft.github.io/debug-adapter-protocol/specification#Base_Protocol_ErrorResponse),
i.e. the user-readable message should be in `body. format`, and
`body.showUser` should probably be set to true.
This is currently done incorrectly by lldb-dap everywhere. This is also, why
users currently get no feedback if, e.g., setting a variable failed. The new
mechanism introduced in #130090 still does not handle this correctly. But if we
consistently adopt the new mechanism, we at least only need to fix a single
place to become standard-compliant
(That being said, I would not block this PR on using `RequestHandler` instead
of `LegacyRequestHandler,` in case @da-viper does not want to invest the time
to update his code to the newer `RequestHandler` mechanism)
https://github.com/llvm/llvm-project/pull/130503
___
[Lldb-commits] [lldb] [llvm] [lldb][lldb-dap] Implement jump to cursor (PR #130503)
@@ -113,6 +113,20 @@ class ExceptionInfoRequestHandler : public RequestHandler {
void operator()(const llvm::json::Object &request) const override;
};
+class GoToRequestHandler : public RequestHandler {
vogelsgesang wrote:
Good point.
Currently, we are using the naming from the [Debug Adapter Protocol
spec](https://github.com/microsoft/debug-adapter-protocol/blob/main/debugAdapterProtocol.json)
directly (That's also where we copied all the comments from).
As such, we also copied over the camelCase style from the DAP spec. Not sure if
we want to stick to the DAP style or LLDB style here. Afaik, this is not a
discussion we had so far.
@ashgti @JDevlieghere WDYT?
https://github.com/llvm/llvm-project/pull/130503
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [lldb][lldb-dap] Implement jump to cursor (PR #130503)
@@ -113,6 +113,20 @@ class ExceptionInfoRequestHandler : public RequestHandler {
void operator()(const llvm::json::Object &request) const override;
};
+class GoToRequestHandler : public RequestHandler {
da-viper wrote:
are the protocol types meant to follow the normal snake_case for variables or
use camelCase ?
https://github.com/llvm/llvm-project/blob/7dc550473c5239399707804c9466519d165aa7fd/lldb/tools/lldb-dap/Protocol/ProtocolTypes.h#L50-L55
https://github.com/llvm/llvm-project/pull/130503
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose the Target API lock through the SB API (PR #131404)
@@ -0,0 +1,11 @@
+%extend lldb::SBLock {
+#ifdef SWIGPYTHON
+%pythoncode %{
+def __enter__(self):
+return self
+
+def __exit__(self, exc_type, exc_value, traceback):
+self.Unlock()
JDevlieghere wrote:
Can you think of a way to make this work in Python, without giving up on the
RAII property on the C++ side? I my opinion the `SBLock` is a lot more
important in C++ than it is in Python (where the GIL means you don't truly have
multithreading anyway, though I know in the future there might be a mode
without the GIL).
https://github.com/llvm/llvm-project/pull/131404
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Use correct path for lldb-server executable (PR #131519)
https://github.com/yuvald-sweet-security updated
https://github.com/llvm/llvm-project/pull/131519
>From ea0a08e60f472c518c98db0acf7e32ec328146d1 Mon Sep 17 00:00:00 2001
From: Yuval Deutscher
Date: Sun, 16 Mar 2025 14:08:57 +
Subject: [PATCH] [lldb] Use correct path for lldb-server executable
---
lldb/tools/lldb-server/lldb-platform.cpp | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/lldb/tools/lldb-server/lldb-platform.cpp
b/lldb/tools/lldb-server/lldb-platform.cpp
index 880b45b989b9c..51174a0f443c3 100644
--- a/lldb/tools/lldb-server/lldb-platform.cpp
+++ b/lldb/tools/lldb-server/lldb-platform.cpp
@@ -31,6 +31,7 @@
#include "Plugins/Process/gdb-remote/ProcessGDBRemoteLog.h"
#include "lldb/Host/ConnectionFileDescriptor.h"
#include "lldb/Host/HostGetOpt.h"
+#include "lldb/Host/HostInfo.h"
#include "lldb/Host/MainLoop.h"
#include "lldb/Host/OptionParser.h"
#include "lldb/Host/Socket.h"
@@ -256,8 +257,9 @@ static void
client_handle(GDBRemoteCommunicationServerPlatform &platform,
printf("Disconnected.\n");
}
-static Status spawn_process(const char *progname, const Socket *conn_socket,
-uint16_t gdb_port, const lldb_private::Args &args,
+static Status spawn_process(const char *progname, const FileSpec &prog,
+const Socket *conn_socket, uint16_t gdb_port,
+const lldb_private::Args &args,
const std::string &log_file,
const StringRef log_channels, MainLoop &main_loop)
{
Status error;
@@ -267,9 +269,10 @@ static Status spawn_process(const char *progname, const
Socket *conn_socket,
ProcessLaunchInfo launch_info;
- FileSpec self_spec(progname, FileSpec::Style::native);
- launch_info.SetExecutableFile(self_spec, true);
+ launch_info.SetExecutableFile(prog, false);
+ launch_info.SetArg0(progname);
Args &self_args = launch_info.GetArguments();
+ self_args.AppendArgument(progname);
self_args.AppendArgument(llvm::StringRef("platform"));
self_args.AppendArgument(llvm::StringRef("--child-platform-fd"));
self_args.AppendArgument(llvm::to_string(shared_socket.GetSendableFD()));
@@ -551,9 +554,10 @@ int main_platform(int argc, char *argv[]) {
log_channels, &main_loop,
&platform_handles](std::unique_ptr sock_up) {
printf("Connection established.\n");
- Status error = spawn_process(progname, sock_up.get(),
- gdbserver_port, inferior_arguments,
- log_file, log_channels, main_loop);
+ Status error = spawn_process(
+ progname, HostInfo::GetProgramFileSpec(), sock_up.get(),
+ gdbserver_port, inferior_arguments, log_file, log_channels,
+ main_loop);
if (error.Fail()) {
Log *log = GetLog(LLDBLog::Platform);
LLDB_LOGF(log, "spawn_process failed: %s", error.AsCString());
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose the Target API lock through the SB API (PR #131404)
@@ -0,0 +1,46 @@
+//===-- SBLock.h
--===//
+//
+// 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_SBLOCK_H
+#define LLDB_API_SBLOCK_H
+
+#include "lldb/API/SBDefines.h"
+#include "lldb/lldb-forward.h"
+#include
+
+namespace lldb_private {
+class APILock;
+}
+
+namespace lldb {
+
+class LLDB_API SBLock {
+public:
+ SBLock();
+ SBLock(SBLock &&rhs);
+ SBLock &operator=(SBLock &&rhs);
+ ~SBLock();
+
+ bool IsValid() const;
+
+ void Unlock() const;
JDevlieghere wrote:
I can document the class, the methods themselves seem pretty self-explanatory.
https://github.com/llvm/llvm-project/pull/131404
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Reapply LLDB-Telemetry TargetInfo branch (pr/127834) (PR #132043)
https://github.com/oontvoo updated
https://github.com/llvm/llvm-project/pull/132043
>From 9f0a47af2b7fdb90e4fa4cc7f8f97c840af1d2bc Mon Sep 17 00:00:00 2001
From: Vy Nguyen
Date: Wed, 19 Mar 2025 10:44:12 -0400
Subject: [PATCH 1/6] Reapply "[LLDB][Telemetry]Define TargetInfo for
collecting data about a target (#127834)"
This reverts commit 7dbcdd578cd4d37b1f4094dbd17556be6382f1cc.
---
lldb/include/lldb/Core/Telemetry.h| 74 +--
lldb/source/Core/Telemetry.cpp| 25 ++-
.../source/Interpreter/CommandInterpreter.cpp | 2 +-
lldb/source/Target/Process.cpp| 21 ++
lldb/source/Target/Target.cpp | 21 ++
5 files changed, 134 insertions(+), 9 deletions(-)
diff --git a/lldb/include/lldb/Core/Telemetry.h
b/lldb/include/lldb/Core/Telemetry.h
index 29ec36b2d64d1..28897f283dc55 100644
--- a/lldb/include/lldb/Core/Telemetry.h
+++ b/lldb/include/lldb/Core/Telemetry.h
@@ -23,9 +23,12 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
+#include
namespace lldb_private {
namespace telemetry {
@@ -46,12 +49,18 @@ struct LLDBConfig : public ::llvm::telemetry::Config {
// Specifically:
// - Length: 8 bits
// - First two bits (MSB) must be 11 - the common prefix
+// - Last two bits (LSB) are reserved for grand-children of LLDBTelemetryInfo
// If any of the subclass has descendents, those descendents
-// must have their LLDBEntryKind in the similar form (ie., share common prefix)
+// must have their LLDBEntryKind in the similar form (ie., share common prefix
+// and differ by the last two bits)
struct LLDBEntryKind : public ::llvm::telemetry::EntryKind {
- static const llvm::telemetry::KindType BaseInfo = 0b1100;
- static const llvm::telemetry::KindType CommandInfo = 0b1101;
- static const llvm::telemetry::KindType DebuggerInfo = 0b11000100;
+ // clang-format off
+ static const llvm::telemetry::KindType BaseInfo= 0b1100;
+ static const llvm::telemetry::KindType CommandInfo = 0b1101;
+ static const llvm::telemetry::KindType DebuggerInfo= 0b11001000;
+ static const llvm::telemetry::KindType ExecModuleInfo = 0b11000100;
+ static const llvm::telemetry::KindType ProcessExitInfo = 0b11001100;
+ // clang-format on
};
/// Defines a convenient type for timestamp of various events.
@@ -89,7 +98,7 @@ struct CommandInfo : public LLDBBaseTelemetryInfo {
/// session. Necessary because we'd send off an entry right before a
command's
/// execution and another right after. This is to avoid losing telemetry if
/// the command does not execute successfully.
- uint64_t command_id;
+ uint64_t command_id = 0;
/// The command name(eg., "breakpoint set")
std::string command_name;
/// These two fields are not collected by default due to PII risks.
@@ -116,7 +125,7 @@ struct CommandInfo : public LLDBBaseTelemetryInfo {
void serialize(llvm::telemetry::Serializer &serializer) const override;
- static uint64_t GetNextId();
+ static uint64_t GetNextID();
private:
// We assign each command (in the same session) a unique id so that their
@@ -146,6 +155,59 @@ struct DebuggerInfo : public LLDBBaseTelemetryInfo {
void serialize(llvm::telemetry::Serializer &serializer) const override;
};
+struct ExecutableModuleInfo : public LLDBBaseTelemetryInfo {
+ lldb::ModuleSP exec_mod;
+ /// The same as the executable-module's UUID.
+ UUID uuid;
+ /// PID of the process owned by this target.
+ lldb::pid_t pid = LLDB_INVALID_PROCESS_ID;
+ /// The triple of this executable module.
+ std::string triple;
+
+ /// If true, this entry was emitted at the beginning of an event (eg., before
+ /// the executable is set). Otherwise, it was emitted at the end of an
+ /// event (eg., after the module and any dependency were loaded.)
+ bool is_start_entry = false;
+
+ ExecutableModuleInfo() = default;
+
+ llvm::telemetry::KindType getKind() const override {
+return LLDBEntryKind::ExecModuleInfo;
+ }
+
+ static bool classof(const TelemetryInfo *T) {
+// Subclasses of this is also acceptable
+return (T->getKind() & LLDBEntryKind::ExecModuleInfo) ==
+ LLDBEntryKind::ExecModuleInfo;
+ }
+ void serialize(llvm::telemetry::Serializer &serializer) const override;
+};
+
+/// Describes an exit status.
+struct ExitDescription {
+ int exit_code;
+ std::string description;
+};
+
+struct ProcessExitInfo : public LLDBBaseTelemetryInfo {
+ // The executable-module's UUID.
+ UUID module_uuid;
+ lldb::pid_t pid = LLDB_INVALID_PROCESS_ID;
+ bool is_start_entry = false;
+ std::optional exit_desc;
+
+ llvm::telemetry::KindType getKind() const override {
+return LLDBEntryKind::ProcessExitInfo;
+ }
+
+ static bool classof(const TelemetryInfo *T) {
+// Subclasses of this is also acceptable
+return (T->getKind() & LLDBEntryKind::ProcessExitInfo) ==
+ LLDBEntryKind::ProcessExitInfo;
+ }
+ void serialize(llvm::t
[Lldb-commits] [lldb] [lldb][debugserver] remove g/G packet handling from debugserver (PR #132127)
https://github.com/kastiglione approved this pull request. https://github.com/llvm/llvm-project/pull/132127 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Change test paths to resolve symlinks (PR #132053)
labath wrote: Resolving the symlink is not the right thing to do in some cases (such as when you symlinks define the actual/expected layout of the directory tree and the real paths are meaningless (e.g. nodes in some CAS storage). I would very much like to see solution that applies the fixes locally, where they are needed. https://github.com/llvm/llvm-project/pull/132053 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
@@ -0,0 +1,273 @@
+//===-- DILParser.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
+//
+// This implements the recursive descent parser for the Data Inspection
+// Language (DIL), and its helper functions, which will eventually underlie the
+// 'frame variable' command. The language that this parser recognizes is
+// described in lldb/docs/dil-expr-lang.ebnf
+//
+//===--===//
+
+#include "lldb/ValueObject/DILParser.h"
+#include "lldb/Target/ExecutionContextScope.h"
+#include "lldb/Utility/DiagnosticsRendering.h"
+#include "lldb/ValueObject/DILAST.h"
+#include "lldb/ValueObject/DILEval.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/FormatAdapters.h"
+#include
+#include
+#include
+#include
+#include
+
+namespace lldb_private::dil {
+
+std::string FormatDiagnostics(llvm::StringRef text, const std::string &message,
+ uint32_t loc, uint16_t err_len) {
+ DiagnosticDetail::SourceLocation sloc = {
+ FileSpec{}, /*line=*/1, static_cast(loc + 1),
+ err_len,false, /*in_user_input=*/true};
+ std::string arrow_str = "^";
+ std::string rendered_msg =
+ llvm::formatv(":1:{0}: {1}\n1 | {2}\n | ^",
+loc + 1, message, text);
+ DiagnosticDetail detail;
+ detail.source_location = sloc;
+ detail.severity = lldb::eSeverityError;
+ detail.message = message;
+ detail.rendered = rendered_msg;
+ std::vector diagnostics;
+ diagnostics.push_back(detail);
+ StreamString diag_stream(true);
+ RenderDiagnosticDetails(diag_stream, 7, true, diagnostics);
+ std::string ret_str = text.str() + "\n" + diag_stream.GetString().str();
+ return ret_str;
+}
+
+llvm::Expected
+DILParser::Parse(llvm::StringRef dil_input_expr, DILLexer lexer,
+ std::shared_ptr frame_sp,
+ lldb::DynamicValueType use_dynamic, bool use_synthetic,
+ bool fragile_ivar, bool check_ptr_vs_member) {
+ Status error;
+ DILParser parser(dil_input_expr, lexer, frame_sp, use_dynamic, use_synthetic,
+ fragile_ivar, check_ptr_vs_member, error);
+ return parser.Run();
+}
+
+DILParser::DILParser(llvm::StringRef dil_input_expr, DILLexer lexer,
+ std::shared_ptr frame_sp,
+ lldb::DynamicValueType use_dynamic, bool use_synthetic,
+ bool fragile_ivar, bool check_ptr_vs_member, Status
&error)
+: m_ctx_scope(frame_sp), m_input_expr(dil_input_expr), m_dil_lexer(lexer),
+ m_error(error), m_use_dynamic(use_dynamic),
+ m_use_synthetic(use_synthetic), m_fragile_ivar(fragile_ivar),
+ m_check_ptr_vs_member(check_ptr_vs_member) {}
+
+llvm::Expected DILParser::Run() {
+ ASTNodeUP expr = ParseExpression();
+
+ Expect(Token::Kind::eof);
+
+ if (m_error.Fail())
+return m_error.ToError();
+
+ return expr;
+}
+
+// Parse an expression.
+//
+// expression:
+//primary_expression
+//
+ASTNodeUP DILParser::ParseExpression() { return ParsePrimaryExpression(); }
+
+// Parse a primary_expression.
+//
+// primary_expression:
+//id_expression
+//"(" expression ")"
+//
+ASTNodeUP DILParser::ParsePrimaryExpression() {
+ if (CurToken().IsOneOf({Token::coloncolon, Token::identifier})) {
+// Save the source location for the diagnostics message.
+uint32_t loc = CurToken().GetLocation();
+auto identifier = ParseIdExpression();
+
+return std::make_unique(loc, identifier, m_use_dynamic,
+m_ctx_scope);
+ } else if (CurToken().Is(Token::l_paren)) {
labath wrote:
https://llvm.org/docs/CodingStandards.html#don-t-use-else-after-a-return
https://github.com/llvm/llvm-project/pull/120971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
@@ -0,0 +1,104 @@
+//===-- DILParser.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_VALUEOBJECT_DILPARSER_H
+#define LLDB_VALUEOBJECT_DILPARSER_H
+
+#include "lldb/Target/ExecutionContextScope.h"
+#include "lldb/Utility/Status.h"
+#include "lldb/ValueObject/DILAST.h"
+#include "lldb/ValueObject/DILLexer.h"
+#include
+#include
+#include
+#include
+#include
+
+namespace lldb_private::dil {
+
+enum class ErrorCode : unsigned char {
+ kOk = 0,
+ kInvalidExpressionSyntax,
+ kUndeclaredIdentifier,
+ kUnknown,
+};
+
+std::string FormatDiagnostics(llvm::StringRef input_expr,
+ const std::string &message, uint32_t loc,
+ uint16_t err_len);
+
+/// Pure recursive descent parser for C++ like expressions.
+/// EBNF grammar for the parser is described in lldb/docs/dil-expr-lang.ebnf
+class DILParser {
+public:
+ static llvm::Expected Parse(llvm::StringRef dil_input_expr,
+ DILLexer lexer,
+ std::shared_ptr frame_sp,
+ lldb::DynamicValueType use_dynamic,
+ bool use_synthetic, bool fragile_ivar,
+ bool check_ptr_vs_member);
+
+ ~DILParser() = default;
+
+ bool UseSynthetic() { return m_use_synthetic; }
+
+ lldb::DynamicValueType UseDynamic() { return m_use_dynamic; }
+
+ using PtrOperator = std::tuple;
labath wrote:
unused?
https://github.com/llvm/llvm-project/pull/120971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/120971 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
@@ -0,0 +1,273 @@
+//===-- DILParser.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
+//
+// This implements the recursive descent parser for the Data Inspection
+// Language (DIL), and its helper functions, which will eventually underlie the
+// 'frame variable' command. The language that this parser recognizes is
+// described in lldb/docs/dil-expr-lang.ebnf
+//
+//===--===//
+
+#include "lldb/ValueObject/DILParser.h"
+#include "lldb/Target/ExecutionContextScope.h"
+#include "lldb/Utility/DiagnosticsRendering.h"
+#include "lldb/ValueObject/DILAST.h"
+#include "lldb/ValueObject/DILEval.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/FormatAdapters.h"
+#include
+#include
+#include
+#include
+#include
+
+namespace lldb_private::dil {
+
+std::string FormatDiagnostics(llvm::StringRef text, const std::string &message,
+ uint32_t loc, uint16_t err_len) {
+ DiagnosticDetail::SourceLocation sloc = {
+ FileSpec{}, /*line=*/1, static_cast(loc + 1),
+ err_len,false, /*in_user_input=*/true};
+ std::string arrow_str = "^";
+ std::string rendered_msg =
+ llvm::formatv(":1:{0}: {1}\n1 | {2}\n | ^",
+loc + 1, message, text);
+ DiagnosticDetail detail;
+ detail.source_location = sloc;
+ detail.severity = lldb::eSeverityError;
+ detail.message = message;
+ detail.rendered = rendered_msg;
+ std::vector diagnostics;
+ diagnostics.push_back(detail);
+ StreamString diag_stream(true);
+ RenderDiagnosticDetails(diag_stream, 7, true, diagnostics);
+ std::string ret_str = text.str() + "\n" + diag_stream.GetString().str();
+ return ret_str;
+}
+
+llvm::Expected
+DILParser::Parse(llvm::StringRef dil_input_expr, DILLexer lexer,
+ std::shared_ptr frame_sp,
+ lldb::DynamicValueType use_dynamic, bool use_synthetic,
+ bool fragile_ivar, bool check_ptr_vs_member) {
+ Status error;
+ DILParser parser(dil_input_expr, lexer, frame_sp, use_dynamic, use_synthetic,
+ fragile_ivar, check_ptr_vs_member, error);
+ return parser.Run();
+}
+
+DILParser::DILParser(llvm::StringRef dil_input_expr, DILLexer lexer,
+ std::shared_ptr frame_sp,
+ lldb::DynamicValueType use_dynamic, bool use_synthetic,
+ bool fragile_ivar, bool check_ptr_vs_member, Status
&error)
+: m_ctx_scope(frame_sp), m_input_expr(dil_input_expr), m_dil_lexer(lexer),
+ m_error(error), m_use_dynamic(use_dynamic),
+ m_use_synthetic(use_synthetic), m_fragile_ivar(fragile_ivar),
+ m_check_ptr_vs_member(check_ptr_vs_member) {}
+
+llvm::Expected DILParser::Run() {
+ ASTNodeUP expr = ParseExpression();
+
+ Expect(Token::Kind::eof);
+
+ if (m_error.Fail())
+return m_error.ToError();
+
+ return expr;
+}
labath wrote:
```suggestion
ASTNodeUP DILParser::Run() {
ASTNodeUP expr = ParseExpression();
Expect(Token::Kind::eof);
return expr;
}
```
https://github.com/llvm/llvm-project/pull/120971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
https://github.com/labath commented: Okay, at this I don't think I have any more comments about functionality. The remaining comments are either stylistic (which should be self-explanatory) or about error handling (which I'm going to write about here). For the error handling, I missed the fact that your new implementation throws away the structured diagnostic info after using it to construct the error string. That kinda misses the point, which is to provide the rest of lldb with a structured representation of the error. It looks like the base DiagnosticError is abstract, so for that we need to create our own error subclass of that. I tried to sketch it out in the inline comments (by combining the existing `ExpressionError` class and your code), but this is only a rough sketch -- you'll certainly need to adjust it to make it work. You can tell whether you've succeded by looking at how the new "frame var" error messages are formatted. They should come out in the same was as in the snippet that [Jim posted](https://github.com/llvm/llvm-project/pull/120971#issuecomment-2722987750). The other set of suggested changes is about changing the error representation from Status to llvm::Error. We're basically already using the error object as if it was an llvm::Error, so I think we should just complete the transition and use it throughout the DIL. https://github.com/llvm/llvm-project/pull/120971 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
@@ -0,0 +1,248 @@
+//===-- DILEval.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/ValueObject/DILEval.h"
+#include "lldb/Symbol/VariableList.h"
+#include "lldb/Target/RegisterContext.h"
+#include "lldb/ValueObject/DILAST.h"
+#include "lldb/ValueObject/ValueObject.h"
+#include "lldb/ValueObject/ValueObjectRegister.h"
+#include "lldb/ValueObject/ValueObjectVariable.h"
+#include "llvm/Support/FormatAdapters.h"
+#include
+
+namespace lldb_private::dil {
+
+static lldb::ValueObjectSP LookupStaticIdentifier(
+VariableList &variable_list, std::shared_ptr exe_scope,
+llvm::StringRef name_ref, llvm::StringRef unqualified_name) {
+ // First look for an exact match to the (possibly) qualified name.
+ for (const lldb::VariableSP &var_sp : variable_list) {
+lldb::ValueObjectSP valobj_sp(
+ValueObjectVariable::Create(exe_scope.get(), var_sp));
+if (valobj_sp && valobj_sp->GetVariable() &&
+(valobj_sp->GetVariable()->NameMatches(ConstString(name_ref
+ return valobj_sp;
+ }
+
+ // If the qualified name is the same as the unqualfied name, there's nothing
+ // more to be done.
+ if (name_ref == unqualified_name)
+return nullptr;
+
+ // We didn't match the qualified name; try to match the unqualified name.
+ for (const lldb::VariableSP &var_sp : variable_list) {
+lldb::ValueObjectSP valobj_sp(
+ValueObjectVariable::Create(exe_scope.get(), var_sp));
+if (valobj_sp && valobj_sp->GetVariable() &&
+(valobj_sp->GetVariable()->NameMatches(ConstString(unqualified_name
+ return valobj_sp;
+ }
+
+ return nullptr;
+}
+
+static lldb::VariableSP DILFindVariable(ConstString name,
+lldb::VariableListSP variable_list) {
+ lldb::VariableSP exact_match;
+ std::vector possible_matches;
+
+ for (lldb::VariableSP var_sp : *variable_list) {
+llvm::StringRef str_ref_name = var_sp->GetName().GetStringRef();
+// Check for global vars, which might start with '::'.
+str_ref_name.consume_front("::");
+
+if (str_ref_name == name.GetStringRef())
+ possible_matches.push_back(var_sp);
+else if (var_sp->NameMatches(name))
+ possible_matches.push_back(var_sp);
+ }
+
+ // Look for exact matches (favors local vars over global vars)
+ auto exact_match_it =
+ llvm::find_if(possible_matches, [&](lldb::VariableSP var_sp) {
+return var_sp->GetName() == name;
+ });
+
+ if (exact_match_it != possible_matches.end())
+return *exact_match_it;
+
+ // Look for a global var exact match.
+ for (auto var_sp : possible_matches) {
+llvm::StringRef str_ref_name = var_sp->GetName().GetStringRef();
+str_ref_name.consume_front("::");
+if (str_ref_name == name.GetStringRef())
+ return var_sp;
+ }
+
+ // If there's a single non-exact match, take it.
+ if (possible_matches.size() == 1)
+return possible_matches[0];
+
+ return nullptr;
+}
+
+lldb::ValueObjectSP LookupGlobalIdentifier(
+llvm::StringRef name_ref, std::shared_ptr stack_frame,
+lldb::TargetSP target_sp, lldb::DynamicValueType use_dynamic,
+CompilerType *scope_ptr) {
+ // First look for match in "local" global variables.
+ lldb::VariableListSP
variable_list(stack_frame->GetInScopeVariableList(true));
+ name_ref.consume_front("::");
+
+ lldb::ValueObjectSP value_sp;
+ if (variable_list) {
+lldb::VariableSP var_sp =
+DILFindVariable(ConstString(name_ref), variable_list);
+if (var_sp)
+ value_sp =
+ stack_frame->GetValueObjectForFrameVariable(var_sp, use_dynamic);
+ }
+
+ if (value_sp)
+return value_sp;
+
+ // Also check for static global vars.
+ if (variable_list) {
+const char *type_name = "";
+if (scope_ptr)
+ type_name = scope_ptr->GetCanonicalType().GetTypeName().AsCString();
+std::string name_with_type_prefix =
+llvm::formatv("{0}::{1}", type_name, name_ref).str();
+value_sp = LookupStaticIdentifier(*variable_list, stack_frame,
+ name_with_type_prefix, name_ref);
+if (!value_sp)
+ value_sp = LookupStaticIdentifier(*variable_list, stack_frame, name_ref,
+name_ref);
+ }
+
+ if (value_sp)
+return value_sp;
+
+ // Check for match in modules global variables.
+ VariableList modules_var_list;
+ target_sp->GetImages().FindGlobalVariables(
+ ConstString(name_ref), std::numeric_limits::max(),
+ modules_var_list);
+ if (modules_var_list.Empty())
+return nullptr;
+
+ for (const lldb::VariableSP &var_sp : modules_var_list) {
+std::string qualified_name = llvm::formatv("::{0}", name
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
@@ -0,0 +1,273 @@
+//===-- DILParser.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
+//
+// This implements the recursive descent parser for the Data Inspection
+// Language (DIL), and its helper functions, which will eventually underlie the
+// 'frame variable' command. The language that this parser recognizes is
+// described in lldb/docs/dil-expr-lang.ebnf
+//
+//===--===//
+
+#include "lldb/ValueObject/DILParser.h"
+#include "lldb/Target/ExecutionContextScope.h"
+#include "lldb/Utility/DiagnosticsRendering.h"
+#include "lldb/ValueObject/DILAST.h"
+#include "lldb/ValueObject/DILEval.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/FormatAdapters.h"
+#include
+#include
+#include
+#include
+#include
+
+namespace lldb_private::dil {
+
+std::string FormatDiagnostics(llvm::StringRef text, const std::string &message,
+ uint32_t loc, uint16_t err_len) {
+ DiagnosticDetail::SourceLocation sloc = {
+ FileSpec{}, /*line=*/1, static_cast(loc + 1),
+ err_len,false, /*in_user_input=*/true};
+ std::string arrow_str = "^";
+ std::string rendered_msg =
+ llvm::formatv(":1:{0}: {1}\n1 | {2}\n | ^",
+loc + 1, message, text);
+ DiagnosticDetail detail;
+ detail.source_location = sloc;
+ detail.severity = lldb::eSeverityError;
+ detail.message = message;
+ detail.rendered = rendered_msg;
+ std::vector diagnostics;
+ diagnostics.push_back(detail);
+ StreamString diag_stream(true);
+ RenderDiagnosticDetails(diag_stream, 7, true, diagnostics);
+ std::string ret_str = text.str() + "\n" + diag_stream.GetString().str();
+ return ret_str;
+}
+
+llvm::Expected
+DILParser::Parse(llvm::StringRef dil_input_expr, DILLexer lexer,
+ std::shared_ptr frame_sp,
+ lldb::DynamicValueType use_dynamic, bool use_synthetic,
+ bool fragile_ivar, bool check_ptr_vs_member) {
+ Status error;
+ DILParser parser(dil_input_expr, lexer, frame_sp, use_dynamic, use_synthetic,
+ fragile_ivar, check_ptr_vs_member, error);
+ return parser.Run();
+}
+
+DILParser::DILParser(llvm::StringRef dil_input_expr, DILLexer lexer,
+ std::shared_ptr frame_sp,
+ lldb::DynamicValueType use_dynamic, bool use_synthetic,
+ bool fragile_ivar, bool check_ptr_vs_member, Status
&error)
+: m_ctx_scope(frame_sp), m_input_expr(dil_input_expr), m_dil_lexer(lexer),
labath wrote:
```suggestion
: m_ctx_scope(frame_sp), m_input_expr(dil_input_expr),
m_dil_lexer(std::move(lexer)),
```
https://github.com/llvm/llvm-project/pull/120971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
@@ -0,0 +1,104 @@
+//===-- DILParser.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_VALUEOBJECT_DILPARSER_H
+#define LLDB_VALUEOBJECT_DILPARSER_H
+
+#include "lldb/Target/ExecutionContextScope.h"
+#include "lldb/Utility/Status.h"
+#include "lldb/ValueObject/DILAST.h"
+#include "lldb/ValueObject/DILLexer.h"
+#include
+#include
+#include
+#include
+#include
+
+namespace lldb_private::dil {
+
+enum class ErrorCode : unsigned char {
+ kOk = 0,
+ kInvalidExpressionSyntax,
+ kUndeclaredIdentifier,
+ kUnknown,
+};
+
+std::string FormatDiagnostics(llvm::StringRef input_expr,
+ const std::string &message, uint32_t loc,
+ uint16_t err_len);
+
+/// Pure recursive descent parser for C++ like expressions.
+/// EBNF grammar for the parser is described in lldb/docs/dil-expr-lang.ebnf
+class DILParser {
+public:
+ static llvm::Expected Parse(llvm::StringRef dil_input_expr,
+ DILLexer lexer,
+ std::shared_ptr frame_sp,
+ lldb::DynamicValueType use_dynamic,
+ bool use_synthetic, bool fragile_ivar,
+ bool check_ptr_vs_member);
+
+ ~DILParser() = default;
+
+ bool UseSynthetic() { return m_use_synthetic; }
+
+ lldb::DynamicValueType UseDynamic() { return m_use_dynamic; }
+
+ using PtrOperator = std::tuple;
+
+private:
+ explicit DILParser(llvm::StringRef dil_input_expr, DILLexer lexer,
+ std::shared_ptr frame_sp,
+ lldb::DynamicValueType use_dynamic, bool use_synthetic,
+ bool fragile_ivar, bool check_ptr_vs_member,
+ Status &error);
+
+ llvm::Expected Run();
+
+ ASTNodeUP ParseExpression();
+ ASTNodeUP ParsePrimaryExpression();
+
+ std::string ParseNestedNameSpecifier();
+
+ std::string ParseIdExpression();
+ std::string ParseUnqualifiedId();
+
+ void BailOut(ErrorCode error_code, const std::string &error, uint32_t loc);
+
+ void BailOut(Status error);
+
+ void Expect(Token::Kind kind);
+
+ void TentativeParsingRollback(uint32_t saved_idx) {
+m_error.Clear();
+m_dil_lexer.ResetTokenIdx(saved_idx);
+ }
+
+ Token CurToken() { return m_dil_lexer.GetCurrentToken(); }
+
+ // Parser doesn't own the evaluation context. The produced AST may depend on
+ // it (for example, for source locations), so it's expected that expression
+ // context will outlive the parser.
+ std::shared_ptr m_ctx_scope;
+
+ llvm::StringRef m_input_expr;
+
+ DILLexer m_dil_lexer;
+
+ // Holds an error if it occures during parsing.
+ Status &m_error;
labath wrote:
```suggestion
llvm::Error &m_error;
```
https://github.com/llvm/llvm-project/pull/120971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
@@ -0,0 +1,31 @@
+"""
+Make sure 'frame var' using DIL parser/evaultor works for local variables.
+"""
+
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+from lldbsuite.test import lldbutil
+
+import os
+import shutil
+import time
+
+
+class TestFrameVarDILLocalVars(TestBase):
+# If your test case doesn't stress debug info, then
+# set this to true. That way it won't be run once for
+# each debug info format.
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_frame_var(self):
+self.build()
+lldbutil.run_to_source_breakpoint(
+self, "Set a breakpoint here", lldb.SBFileSpec("main.cpp")
+)
+
+self.expect("settings set target.experimental.use-DIL true",
substrs=[""])
labath wrote:
```suggestion
self.runCmd("settings set target.experimental.use-DIL true")
```
https://github.com/llvm/llvm-project/pull/120971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
@@ -0,0 +1,273 @@
+//===-- DILParser.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
+//
+// This implements the recursive descent parser for the Data Inspection
+// Language (DIL), and its helper functions, which will eventually underlie the
+// 'frame variable' command. The language that this parser recognizes is
+// described in lldb/docs/dil-expr-lang.ebnf
+//
+//===--===//
+
+#include "lldb/ValueObject/DILParser.h"
+#include "lldb/Target/ExecutionContextScope.h"
+#include "lldb/Utility/DiagnosticsRendering.h"
+#include "lldb/ValueObject/DILAST.h"
+#include "lldb/ValueObject/DILEval.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/FormatAdapters.h"
+#include
+#include
+#include
+#include
+#include
+
+namespace lldb_private::dil {
+
+std::string FormatDiagnostics(llvm::StringRef text, const std::string &message,
+ uint32_t loc, uint16_t err_len) {
labath wrote:
This should actually return an instance of DILError. Something like:
```suggestion
llvm::Error CreateDiagnosticError(DILError::ErrorCode code, llvm::StringRef
text, const std::string &message,
uint32_t loc, uint16_t err_len) {
DiagnosticDetail detail = /*the same as before*/;
return llvm::make_error(code, detail, ???);
```
https://github.com/llvm/llvm-project/pull/120971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
@@ -0,0 +1,29 @@
+"""
+Make sure 'frame var' using DIL parser/evaultor works for local variables.
+"""
+
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+from lldbsuite.test import lldbutil
+
+import os
+import shutil
+import time
+
+
+class TestFrameVarDILInstanceVariables(TestBase):
+# If your test case doesn't stress debug info, then
+# set this to true. That way it won't be run once for
+# each debug info format.
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_frame_var(self):
+self.build()
+lldbutil.run_to_source_breakpoint(
+self, "Set a breakpoint here", lldb.SBFileSpec("main.cpp")
+)
+
+self.expect("settings set target.experimental.use-DIL true",
substrs=[""])
+self.expect_var_path("this", type="TestMethods *")
+self.expect("frame variable 'c'", substrs=["(field_ = -1)"])
labath wrote:
```suggestion
self.expect_var_path("c", children=[ValueCheck(name="field_", value =
"-1")])
```
https://github.com/llvm/llvm-project/pull/120971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Use correct path for lldb-server executable (PR #131519)
yuvald-sweet-security wrote: > Not exactly. I my use case, `lldb-server` would be a symlink to something > like `/cas/dead/beef/baadf00d`. The symlink value is supposed to be an > implementation detail of the CAS system. While the user could execute that > directly, it wouldn't be totally surprising that it does not work. Then maybe we should just execute the path given by `GetProgramFileSpec` but pass our argv[0] into execve's argv[0] (I don't know if the current process execution abstraction allows that) https://github.com/llvm/llvm-project/pull/131519 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver][MacOSX] Work around sanitizer misaligned address errors when reading exception data (PR #132193)
https://github.com/Michael137 edited https://github.com/llvm/llvm-project/pull/132193 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver][MacOSX] Work around sanitizer misaligned address … (PR #132193)
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/132193
…errors when reading exception data
We've been dealing with UBSAN issues around this code for some time now (see
`9c36859b33b386fbfa9599646de1e2ae01158180` and
`1a2122e9e9d1d495fdf337a4a9445b61ca56df6f`). On recent macOS versions, a
UBSAN-enabled debugserver will crash when performing a `memcpy` of the input
`mach_exception_data_t`. The pointer to the beginning of the exception data may
not be aligned on a doubleword boundary, leading to UBSAN failures such as:
```
$ ./bin/debugserver 0.0.0.0:
/Volumes/SSD/llvm-builds/llvm-worktrees/clang-work/build-sanitized-release/tools/lldb/test/Shell/Recognizer/Output/verbose_trap.test.tmp.out
/Volumes/SSD/llvm-builds/llvm-worktrees/clang-work/lldb/tools/debugserver/source/MacOSX/MachException.cpp:35:12:
runtime error: store to misaligned address 0x00016ddfa634 for type
'mach_exception_data_type_t *' (aka 'long long *'), which requires 8 byte
alignment
0x00016ddfa634: note: pointer points here
02 00 00 00 03 00 01 00 00 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00 08
00 00 00 00 00 00 00
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/Volumes/SSD/llvm-builds/llvm-worktrees/clang-work/lldb/tools/debugserver/source/MacOSX/MachException.cpp:35:12
```
Work around these failures by pretending the input data is a `char*` buffer.
Drive-by changes:
* I factored out some duplicated code into a static `AppendExceptionData` and
made the types consistent
>From 223d85c6b2f5509f704d598bae974a98e5bf6bcb Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Thu, 20 Mar 2025 11:46:45 +
Subject: [PATCH] [lldb][debugserver][MacOSX] Work around sanitizer misaligned
address errors when reading exception data
We've been dealing with UBSAN issues around this code for some time now
(see `9c36859b33b386fbfa9599646de1e2ae01158180` and
`1a2122e9e9d1d495fdf337a4a9445b61ca56df6f`). On recent macOS versions, a
UBSAN-enabled debugserver will crash when performing a `memcpy` of the
input `mach_exception_data_t`. The pointer to the beginning of the
exception data may not be aligned on a doubleword boundary, leading to
UBSAN failures such as:
```
$ ./bin/debugserver 0.0.0.0:
/Volumes/SSD/llvm-builds/llvm-worktrees/clang-work/build-sanitized-release/tools/lldb/test/Shell/Recognizer/Output/verbose_trap.test.tmp.out
/Volumes/SSD/llvm-builds/llvm-worktrees/clang-work/lldb/tools/debugserver/source/MacOSX/MachException.cpp:35:12:
runtime error: store to misaligned address 0x00016ddfa634 for type
'mach_exception_data_type_t *' (aka 'long long *'), which requires 8 byte
alignment
0x00016ddfa634: note: pointer points here
02 00 00 00 03 00 01 00 00 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00 08
00 00 00 00 00 00 00
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/Volumes/SSD/llvm-builds/llvm-worktrees/clang-work/lldb/tools/debugserver/source/MacOSX/MachException.cpp:35:12
```
Work around these failures by pretending the input data is a `char*` buffer.
Drive-by changes:
* I factored out some duplicated code into a static `AppendExceptionData` and
made the types consistent
---
.../source/MacOSX/MachException.cpp | 38 ---
.../debugserver/source/MacOSX/MachException.h | 9 -
2 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/lldb/tools/debugserver/source/MacOSX/MachException.cpp
b/lldb/tools/debugserver/source/MacOSX/MachException.cpp
index 659fb2ff8186d..d05b47cd9b590 100644
--- a/lldb/tools/debugserver/source/MacOSX/MachException.cpp
+++ b/lldb/tools/debugserver/source/MacOSX/MachException.cpp
@@ -20,6 +20,23 @@
#include
#include
#include
+#include
+
+static void AppendExceptionData(
+std::vector &out,
+mach_exception_data_t Data, mach_msg_type_number_t Count) {
+ mach_exception_data_type_t Buf;
+ for (mach_msg_type_number_t i = 0; i < Count; ++i) {
+// The input Data we receive need not be aligned correctly.
+// Perform an unaligned copy by pretending we're dealing with
+// a char* buffer. This is required to work around UBSAN/ASAN
+// "misaligned address" errors.
+auto * src = reinterpret_cast(&Buf);
+auto * dst = reinterpret_cast(Data + i);
+memcpy(dst, src, sizeof(mach_exception_data_type_t));
+out.push_back(Buf);
+ }
+}
// Routine mach_exception_raise
extern "C" kern_return_t
@@ -95,20 +112,15 @@ catch_mach_exception_raise(mach_port_t exc_port,
mach_port_t thread_port,
mach_exception_data_t exc_data,
mach_msg_type_number_t exc_data_count) {
if (DNBLogCheckLogBit(LOG_EXCEPTIONS)) {
-std::vector exc_datas;
-uint64_t tmp;
-for (unsigned i = 0; i < exc_data_count; ++i) {
- // Perform an unaligned copy.
- memcpy(&tmp, &exc_data[i], sizeof(uint64_t));
- exc_datas.push_back(tmp);
-}
+std::vector exc_datas;
+AppendExceptionData
[Lldb-commits] [lldb] [lldb][debugserver][MacOSX] Work around sanitizer misaligned address errors when reading exception data (PR #132193)
https://github.com/Michael137 edited https://github.com/llvm/llvm-project/pull/132193 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [lldb][lldb-dap] Implement jump to cursor (PR #130503)
@@ -113,6 +113,20 @@ class ExceptionInfoRequestHandler : public RequestHandler {
void operator()(const llvm::json::Object &request) const override;
};
+class GoToRequestHandler : public RequestHandler {
vogelsgesang wrote:
please rebase on `main`, and make sure to use the new, non-legacy mechanism for
those new request handlers introduced in #130090
https://github.com/llvm/llvm-project/pull/130503
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adding support for cancelling a request. (PR #130169)
https://github.com/labath commented: I think there's a race in the cancellation handling: 1. request handling thread sets active_seq (but doesn't start executing the request yet) 2. cancellation request comes in, queue_reader sets the interrupt flag 3. request handling thread begins handling the request, starts by clearing the flag 4. request is not cancelled I think this would be easier to guarantee correctness (and review) if `active_seq` was *not* an atomic and its modification, as well as the acts of setting and clearing the interrupt flag were done under a mutex https://github.com/llvm/llvm-project/pull/130169 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
@@ -0,0 +1,51 @@
+"""
+Make sure 'frame var' using DIL parser/evaultor works for local variables.
+"""
+
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+from lldbsuite.test import lldbutil
+
+import os
+import shutil
+import time
+
+
+class TestFrameVarDILGlobalVariableLookup(TestBase):
+# If your test case doesn't stress debug info, then
+# set this to true. That way it won't be run once for
+# each debug info format.
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_frame_var(self):
+self.build()
+lldbutil.run_to_source_breakpoint(
+self, "Set a breakpoint here", lldb.SBFileSpec("main.cpp")
+)
+
+self.expect("settings set target.experimental.use-DIL true",
substrs=[""])
labath wrote:
```suggestion
self.runCmd("settings set target.experimental.use-DIL true")
```
https://github.com/llvm/llvm-project/pull/120971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Interrupt should reset outstanding SIGSTOP (PR #132128)
https://github.com/jasonmolenda closed https://github.com/llvm/llvm-project/pull/132128 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Allow providing debug adapter arguments in the extension (PR #129262)
https://github.com/matthewbastien updated
https://github.com/llvm/llvm-project/pull/129262
>From 7ab3d3ac41e3aadda9c96dc5c5ea2551be7113c4 Mon Sep 17 00:00:00 2001
From: Matthew Bastien
Date: Fri, 28 Feb 2025 11:08:25 -0500
Subject: [PATCH 01/13] allow providing debug adapter arguments
---
lldb/tools/lldb-dap/package.json | 29 +--
.../lldb-dap/src-ts/debug-adapter-factory.ts | 78 ---
2 files changed, 76 insertions(+), 31 deletions(-)
diff --git a/lldb/tools/lldb-dap/package.json b/lldb/tools/lldb-dap/package.json
index 428624f46feba..05e9540df17cf 100644
--- a/lldb/tools/lldb-dap/package.json
+++ b/lldb/tools/lldb-dap/package.json
@@ -76,6 +76,15 @@
"type": "string",
"description": "The path to the lldb-dap binary."
},
+"lldb-dap.arguments": {
+ "scope": "resource",
+ "type": "array",
+ "default": [],
+ "items": {
+"type": "string"
+ },
+ "description": "The arguments provided to the lldb-dap process."
+},
"lldb-dap.log-path": {
"scope": "resource",
"type": "string",
@@ -149,10 +158,6 @@
{
"type": "lldb-dap",
"label": "LLDB DAP Debugger",
-"program": "./bin/lldb-dap",
-"windows": {
- "program": "./bin/lldb-dap.exe"
-},
"configurationAttributes": {
"launch": {
"required": [
@@ -163,6 +168,13 @@
"type": "string",
"markdownDescription": "The absolute path to the LLDB debug
adapter executable to use."
},
+ "debugAdapterArgs": {
+"type": "array",
+"items": {
+ "type": "string"
+},
+"markdownDescription": "The list of arguments used to launch
the debug adapter executable."
+ },
"program": {
"type": "string",
"description": "Path to the program to debug."
@@ -353,6 +365,13 @@
"type": "string",
"markdownDescription": "The absolute path to the LLDB debug
adapter executable to use."
},
+ "debugAdapterArgs": {
+"type": "array",
+"items": {
+ "type": "string"
+},
+"markdownDescription": "The list of arguments used to launch
the debug adapter executable."
+ },
"program": {
"type": "string",
"description": "Path to the program to attach to."
@@ -550,4 +569,4 @@
}
]
}
-}
\ No newline at end of file
+}
diff --git a/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts
b/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts
index c2244dcbde8f2..85c34b773e047 100644
--- a/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts
+++ b/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts
@@ -25,7 +25,7 @@ async function findWithXcrun(executable: string):
Promise {
if (stdout) {
return stdout.toString().trimEnd();
}
-} catch (error) { }
+} catch (error) {}
}
return undefined;
}
@@ -93,8 +93,23 @@ async function getDAPExecutable(
return undefined;
}
+function getDAPArguments(session: vscode.DebugSession): string[] {
+ // Check the debug configuration for arguments first
+ const debugConfigArgs = session.configuration.debugAdapterArgs;
+ if (
+Array.isArray(debugConfigArgs) &&
+debugConfigArgs.findIndex((entry) => typeof entry !== "string") === -1
+ ) {
+return debugConfigArgs;
+ }
+ // Fall back on the workspace configuration
+ return vscode.workspace
+.getConfiguration("lldb-dap")
+.get("arguments", []);
+}
+
async function isServerModeSupported(exe: string): Promise {
- const { stdout } = await exec(exe, ['--help']);
+ const { stdout } = await exec(exe, ["--help"]);
return /--connection/.test(stdout);
}
@@ -103,8 +118,13 @@ async function isServerModeSupported(exe: string):
Promise {
* depending on the session configuration.
*/
export class LLDBDapDescriptorFactory
- implements vscode.DebugAdapterDescriptorFactory, vscode.Disposable {
- private server?: Promise<{ process: child_process.ChildProcess, host:
string, port: number }>;
+ implements vscode.DebugAdapterDescriptorFactory, vscode.Disposable
+{
+ private server?: Promise<{
+process: child_process.ChildProcess;
+host: string;
+port: number;
+ }>;
dispose() {
this.server?.then(({ process }) => {
@@ -114,7 +134,7 @@ export class LLDBDapDescriptorFactory
async createDebugAdapterDescriptor(
session: vscode.DebugSession,
-executable: vscode.DebugAdapterExecutable | undefined,
+_executable: vscode.DebugAdapterExecutable | undefined,
): Promise {
const config = vscode.workspace.getConfiguration(
"lldb-dap",
@@ -128,7 +148,7 @@ export class LLDBDapDe
[Lldb-commits] [lldb] [lldb] Expose the Target API lock through the SB API (PR #131404)
@@ -0,0 +1,11 @@
+%extend lldb::SBLock {
+#ifdef SWIGPYTHON
+%pythoncode %{
+def __enter__(self):
+return self
+
+def __exit__(self, exc_type, exc_value, traceback):
+self.Unlock()
vogelsgesang wrote:
Sounds good. If we would have an additional `GetLock` (beides `AcquireLock`)
which returns the non-locked Lock, then I think we would have a full idiomatoc
interface, also in Python
https://github.com/llvm/llvm-project/pull/131404
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Allow providing debug adapter arguments in the extension (PR #129262)
@@ -0,0 +1,103 @@
+import * as vscode from "vscode";
+import * as child_process from "child_process";
+import * as util from "util";
+import { LLDBDapServer } from "./lldb-dap-server";
+import { createDebugAdapterExecutable } from "./debug-adapter-factory";
+import { ConfigureButton, showErrorMessage } from "./ui/show-error-message";
+import { ErrorWithNotification } from "./ui/error-with-notification";
+
+const exec = util.promisify(child_process.execFile);
+
+/**
+ * Determines whether or not the given lldb-dap executable supports executing
+ * in server mode.
+ *
+ * @param exe the path to the lldb-dap executable
+ * @returns a boolean indicating whether or not lldb-dap supports server mode
+ */
+async function isServerModeSupported(exe: string): Promise {
+ const { stdout } = await exec(exe, ["--help"]);
+ return /--connection/.test(stdout);
+}
+
+export class LLDBDapConfigurationProvider
+ implements vscode.DebugConfigurationProvider
+{
+ constructor(private readonly server: LLDBDapServer) {}
+
+ async resolveDebugConfiguration(
+folder: vscode.WorkspaceFolder | undefined,
+debugConfiguration: vscode.DebugConfiguration,
+_token?: vscode.CancellationToken,
+ ): Promise {
matthewbastien wrote:
Done.
https://github.com/llvm/llvm-project/pull/129262
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Interrupt should reset outstanding SIGSTOP (PR #132128)
@@ -1594,6 +1594,10 @@ static uint64_t bits(uint64_t value, uint32_t msbit,
uint32_t lsbit) {
m_sent_interrupt_signo);
}
} else {
+ // We've requested that the process stop anew; if we had recorded this
+ // requested stop as being in place when we resumed (& therefore would
+ // throw it away), clear that.
+ m_auto_resume_signo = 0;
JDevlieghere wrote:
Ok, and this is protected by the `m_exception_and_signal_mutex`. 👍
https://github.com/llvm/llvm-project/pull/132128
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adding support for cancelling a request. (PR #130169)
ashgti wrote: > If we want to support cancellation before moving all the request over to the > protocol class, can we _temporarily_ store both the JSON and the Protocol in > the class we instantiate per request (whether that's the RequestHandler > itself, or a class wrapping it) and use whichever one we need for that given > request? For the `LegacyRequestHandler`, its more to do with the response than the request. We can store the request as a `protocol::Message` and in the `LegacyRequestHandler` we convert it back into a `json::Value` before we pass it to the handler. But the `LegacyRequestHandler`'s all tend to call `dap.SendJSON` directly with a `json::Value`. In my current impl of the cancel request, I check for the cancelled requests prior to sending them https://github.com/llvm/llvm-project/blob/1c2d19b901390c6080c1367341115150661a6a14/lldb/tools/lldb-dap/DAP.cpp#L245-L258 https://github.com/llvm/llvm-project/pull/130169 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Allow providing debug adapter arguments in the extension (PR #129262)
@@ -90,117 +99,119 @@ async function getDAPExecutable(
return foundPath;
}
- return undefined;
+ throw new ErrorWithNotification(
+"Unable to find the path to the LLDB debug adapter executable.",
+new OpenSettingsButton("lldb-dap.executable-path"),
+ );
}
-async function isServerModeSupported(exe: string): Promise {
- const { stdout } = await exec(exe, ['--help']);
- return /--connection/.test(stdout);
+/**
+ * Retrieves the arguments that will be provided to lldb-dap either from
settings or the provided
+ * {@link vscode.DebugConfiguration}.
+ *
+ * @param workspaceFolder The {@link vscode.WorkspaceFolder} that the debug
session will be launched within
+ * @param configuration The {@link vscode.DebugConfiguration} that will be
launched
+ * @throws An {@link ErrorWithNotification} if something went wrong
+ * @returns The arguments that will be provided to lldb-dap
+ */
+async function getDAPArguments(
+ workspaceFolder: vscode.WorkspaceFolder | undefined,
+ configuration: vscode.DebugConfiguration,
+): Promise {
+ // Check the debug configuration for arguments first.
+ const debugConfigArgs = configuration.debugAdapterArgs;
+ if (debugConfigArgs) {
+if (
+ !Array.isArray(debugConfigArgs) ||
+ debugConfigArgs.findIndex((entry) => typeof entry !== "string") !== -1
+) {
+ throw new ErrorWithNotification(
+"The debugAdapterArgs property must be an array of string values.
Please update your launch configuration",
+new ConfigureButton(),
+ );
+}
+return debugConfigArgs;
+ }
+ // Fall back on the workspace configuration.
+ return vscode.workspace
+.getConfiguration("lldb-dap", workspaceFolder)
+.get("arguments", []);
+}
+
+/**
+ * Creates a new {@link vscode.DebugAdapterExecutable} based on the provided
workspace folder and
+ * debug configuration. Assumes that the given debug configuration is for a
local launch of lldb-dap.
+ *
+ * @param workspaceFolder The {@link vscode.WorkspaceFolder} that the debug
session will be launched within
+ * @param configuration The {@link vscode.DebugConfiguration} that will be
launched
+ * @throws An {@link ErrorWithNotification} if something went wrong
+ * @returns The {@link vscode.DebugAdapterExecutable} that can be used to
launch lldb-dap
+ */
+export async function createDebugAdapterExecutable(
+ workspaceFolder: vscode.WorkspaceFolder | undefined,
+ configuration: vscode.DebugConfiguration,
+): Promise {
+ const config = vscode.workspace.getConfiguration("lldb-dap",
workspaceFolder);
+ const log_path = config.get("log-path");
+ let env: { [key: string]: string } = {};
+ if (log_path) {
+env["LLDBDAP_LOG"] = log_path;
+ }
+ const configEnvironment =
+config.get<{ [key: string]: string }>("environment") || {};
+ const dapPath = await getDAPExecutable(workspaceFolder, configuration);
+
+ if (!(await isExecutable(dapPath))) {
+let message = `Debug adapter path "${dapPath}" is not a valid file.`;
+let buttons: (OpenSettingsButton | ConfigureButton)[] = [
+ new OpenSettingsButton("lldb-dap.executable-path"),
+];
+if ("debugAdapterPath" in configuration) {
+ message += " The path comes from your launch configuration.";
+ buttons = [new ConfigureButton()];
+}
+throw new ErrorWithNotification(message, ...buttons);
+ }
matthewbastien wrote:
Good point. I've moved this logic into `getDAPExecutable()`.
https://github.com/llvm/llvm-project/pull/129262
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adding a DAPError for showing users error messages. (PR #132255)
@@ -0,0 +1,33 @@
+//===-- DAPError.h
===//
+//
+// 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 "llvm/Support/Error.h"
+#include
+
+namespace lldb_dap {
+
+/// An Error that is reported as a DAP Error Message, which may be presented to
+/// the user.
+class DAPError : public llvm::ErrorInfo {
+public:
+ static char ID;
+
+ DAPError(std::string message, bool show_user = false);
Jlalond wrote:
Why the default to false for show_user? I can't think of an example of an error
that I wouldn't want to surface (off the top of my head).
Additionally, I think this should probably not have a default and every
construction should set it explicitly, but again I can't think of a scenario
where I wouldn't want to show it
https://github.com/llvm/llvm-project/pull/132255
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] remove g/G packet handling from debugserver (PR #132127)
https://github.com/jasonmolenda closed https://github.com/llvm/llvm-project/pull/132127 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] b3b5527 - [lldb] Use UnwindPlan::Row as values, part 2 (#132008)
Author: Pavel Labath
Date: 2025-03-20T09:18:40+01:00
New Revision: b3b5527baaeceb923e9bb698f52883a1506f1b25
URL:
https://github.com/llvm/llvm-project/commit/b3b5527baaeceb923e9bb698f52883a1506f1b25
DIFF:
https://github.com/llvm/llvm-project/commit/b3b5527baaeceb923e9bb698f52883a1506f1b25.diff
LOG: [lldb] Use UnwindPlan::Row as values, part 2 (#132008)
This is the mechanical part of #131150.
I'm also removing the interfaces taking a RowSP.
Added:
Modified:
lldb/include/lldb/Symbol/UnwindPlan.h
lldb/source/Plugins/ABI/AArch64/ABIMacOSX_arm64.cpp
lldb/source/Plugins/ABI/AArch64/ABISysV_arm64.cpp
lldb/source/Plugins/ABI/ARC/ABISysV_arc.cpp
lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
lldb/source/Plugins/ABI/ARM/ABISysV_arm.cpp
lldb/source/Plugins/ABI/Hexagon/ABISysV_hexagon.cpp
lldb/source/Plugins/ABI/LoongArch/ABISysV_loongarch.cpp
lldb/source/Plugins/ABI/MSP430/ABISysV_msp430.cpp
lldb/source/Plugins/ABI/Mips/ABISysV_mips.cpp
lldb/source/Plugins/ABI/Mips/ABISysV_mips64.cpp
lldb/source/Plugins/ABI/PowerPC/ABISysV_ppc.cpp
lldb/source/Plugins/ABI/PowerPC/ABISysV_ppc64.cpp
lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
lldb/source/Plugins/ABI/SystemZ/ABISysV_s390x.cpp
lldb/source/Plugins/ABI/X86/ABIMacOSX_i386.cpp
lldb/source/Plugins/ABI/X86/ABISysV_i386.cpp
lldb/source/Plugins/ABI/X86/ABISysV_x86_64.cpp
lldb/source/Plugins/ABI/X86/ABIWindows_x86_64.cpp
lldb/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
lldb/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
lldb/source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
lldb/source/Plugins/Instruction/PPC64/EmulateInstructionPPC64.cpp
lldb/source/Symbol/UnwindPlan.cpp
Removed:
diff --git a/lldb/include/lldb/Symbol/UnwindPlan.h
b/lldb/include/lldb/Symbol/UnwindPlan.h
index e4199d5677035..7c361bc08bcfe 100644
--- a/lldb/include/lldb/Symbol/UnwindPlan.h
+++ b/lldb/include/lldb/Symbol/UnwindPlan.h
@@ -462,13 +462,9 @@ class UnwindPlan {
void Dump(Stream &s, Thread *thread, lldb::addr_t base_addr) const;
- void AppendRow(const RowSP &row_sp);
- void AppendRow(Row row) { AppendRow(std::make_shared(std::move(row))); }
+ void AppendRow(Row row);
- void InsertRow(const RowSP &row_sp, bool replace_existing = false);
- void InsertRow(Row row, bool replace_existing = false) {
-InsertRow(std::make_shared(std::move(row)), replace_existing);
- }
+ void InsertRow(Row row, bool replace_existing = false);
// Returns a pointer to the best row for the given offset into the function's
// instructions. If offset is -1 it indicates that the function start is
diff --git a/lldb/source/Plugins/ABI/AArch64/ABIMacOSX_arm64.cpp
b/lldb/source/Plugins/ABI/AArch64/ABIMacOSX_arm64.cpp
index 4b3018bb40a49..f86ab8cbb1195 100644
--- a/lldb/source/Plugins/ABI/AArch64/ABIMacOSX_arm64.cpp
+++ b/lldb/source/Plugins/ABI/AArch64/ABIMacOSX_arm64.cpp
@@ -349,16 +349,16 @@ UnwindPlanSP
ABIMacOSX_arm64::CreateFunctionEntryUnwindPlan() {
uint32_t sp_reg_num = arm64_dwarf::sp;
uint32_t pc_reg_num = arm64_dwarf::pc;
- UnwindPlan::RowSP row(new UnwindPlan::Row);
+ UnwindPlan::Row row;
// Our previous Call Frame Address is the stack pointer
- row->GetCFAValue().SetIsRegisterPlusOffset(sp_reg_num, 0);
+ row.GetCFAValue().SetIsRegisterPlusOffset(sp_reg_num, 0);
// Our previous PC is in the LR, all other registers are the same.
- row->SetRegisterLocationToRegister(pc_reg_num, lr_reg_num, true);
+ row.SetRegisterLocationToRegister(pc_reg_num, lr_reg_num, true);
auto plan_sp = std::make_shared(eRegisterKindDWARF);
- plan_sp->AppendRow(row);
+ plan_sp->AppendRow(std::move(row));
plan_sp->SetSourceName("arm64 at-func-entry default");
plan_sp->SetSourcedFromCompiler(eLazyBoolNo);
return plan_sp;
@@ -368,18 +368,17 @@ UnwindPlanSP ABIMacOSX_arm64::CreateDefaultUnwindPlan() {
uint32_t fp_reg_num = arm64_dwarf::fp;
uint32_t pc_reg_num = arm64_dwarf::pc;
- UnwindPlan::RowSP row(new UnwindPlan::Row);
+ UnwindPlan::Row row;
const int32_t ptr_size = 8;
- row->GetCFAValue().SetIsRegisterPlusOffset(fp_reg_num, 2 * ptr_size);
- row->SetOffset(0);
- row->SetUnspecifiedRegistersAreUndefined(true);
+ row.GetCFAValue().SetIsRegisterPlusOffset(fp_reg_num, 2 * ptr_size);
+ row.SetUnspecifiedRegistersAreUndefined(true);
- row->SetRegisterLocationToAtCFAPlusOffset(fp_reg_num, ptr_size * -2, true);
- row->SetRegisterLocationToAtCFAPlusOffset(pc_reg_num, ptr_size * -1, true);
+ row.SetRegisterLocationToAtCFAPlusOffset(fp_reg_num, ptr_size * -2, true);
+ row.SetRegisterLocationToAtCFAPlusOffset(pc_reg_num, ptr_size * -1, true);
auto plan_sp = std::make_shared(eRegisterKindDWARF);
- plan_sp->AppendRow(row);
+ plan_sp->AppendRow(std::move(row));
[Lldb-commits] [lldb] [LLDB][NFC] Fix typo in docs (PR #131388)
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/131388 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Telemetry]Define TargetInfo for collecting data about a target (PR #127834)
@@ -1064,6 +1065,29 @@ const char *Process::GetExitDescription() {
bool Process::SetExitStatus(int status, llvm::StringRef exit_string) {
// Use a mutex to protect setting the exit status.
std::lock_guard guard(m_exit_status_mutex);
+ telemetry::ScopedDispatcher helper;
+
+ // Find the executable-module's UUID, if available.
+ UUID exec_uuid;
+ // Check if there is (still) a valid target and get the debugger and
exec_uuid
+ // from it.
+ TargetSP target_sp(Debugger::FindTargetWithProcessID(m_pid));
+ if (target_sp) {
+helper.SetDebugger(&(target_sp->GetDebugger()));
+exec_uuid = target_sp->GetExecModuleUUID();
labath wrote:
That sort of makes sense. The target would not be available if it was already
being destroyed. However, `Debugger::FindTargetWithProcessID` is still a very
roundabout way to check for target validity. You should be able to achieve the
same thing with:
```
if (TargetSP target_sp = m_target_wp.lock()) {
...
}
```
https://github.com/llvm/llvm-project/pull/127834
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Use correct path for lldb-server executable (PR #131519)
yuvald-sweet-security wrote: > > Ah, turns out there's a HostInfo::GetProgramFileSpec() function which > > solves both these issues. > > I am aware of that function. The reason I did not suggest it is because > `GetProgramFileSpec` (on linux) returns the canonical path (with all symlinks > resolved). That's something I am generally trying to avoid because it can > break some instalation types -- where the installation consists of a symlink > farm and the expected installation layout is given by the symlink tree. (It > can also fix some installations which expect exactly the opposite -- the > debian use case in one of them). I understand, but I think that for lldb-server this isn't much of an issue as it seems relatively stand-alone. I'd be more worried if this code attempted to execute a binary that isn't `lldb-server` from the LLVM binary directory; however, since this code is strictly used for lldb-server to re-execute itself with different arguments, I don't think relying on `GetProgramFileSpec` is an issue - and it is definitely better than using argv[0], which might as well be the canonical path, depending on how the user executed it. > Whatever we do, I think it is better to resolve the symlink as late as > possible as that gives us more options down the line. What I don't understand > is why doesn't this work for your use case already -- > `GetModuleFileSpecForHostAddress` calls `FileSystem::Resolve`, which should > give you the canonical path for the library. Does that fail for some reason? > It is it because the (relative) path returned by > `GetModuleFileSpecForHostAddress` is resolved relative to CWD (but in reality > we've executed it by finding the executable on the path)? I'm assuming this is referring to the other issue, which I discuss in https://github.com/llvm/llvm-project/pull/131609? Because the issue in the current PR is not related to `GetModuleFileSpecForHostAddress` - `argv[0]` is piped directly into `spawn_process` without any canonicalization of paths. https://github.com/llvm/llvm-project/pull/131519 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix TestGdbRemoteForkNonStop.py test (PR #131293)
https://github.com/labath approved this pull request. Thanks. https://github.com/llvm/llvm-project/pull/131293 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Use correct path for lldb-server executable (PR #131519)
labath wrote: > > > Ah, turns out there's a HostInfo::GetProgramFileSpec() function which > > > solves both these issues. > > > > > > I am aware of that function. The reason I did not suggest it is because > > `GetProgramFileSpec` (on linux) returns the canonical path (with all > > symlinks resolved). That's something I am generally trying to avoid because > > it can break some instalation types -- where the installation consists of a > > symlink farm and the expected installation layout is given by the symlink > > tree. (It can also fix some installations which expect exactly the opposite > > -- the debian use case in one of them). > > I understand, but I think that for lldb-server this isn't much of an issue as > it seems relatively stand-alone. I'd be more worried if this code attempted > to execute a binary that isn't `lldb-server` from the LLVM binary directory; > however, since this code is strictly used for lldb-server to re-execute > itself with different arguments, I don't think relying on > `GetProgramFileSpec` is an issue - and it is definitely better than using > argv[0], which might as well be the canonical path, depending on how the user > executed it. Not exactly. I my use case, `lldb-server` would be a symlink to something like `/cas/dead/beef/baadf00d`. The symlink value is supposed to be an implementation detail of the CAS system. While the user could execute that directly, it wouldn't be totally surprising that it does not work. And the lldb-server binary is not completely standalone as it needs to execute the gdbserver binary (which on linux is actually still the same binary, but the code kind of doesn't know that), which is why you have #131609. In this scenario, there's no way to find the lldb-server binary (or anything else) because the CAS tree contains only a bunch of hex files. That said, I'm slightly warming up towards using GetProgramFileSpec because I realized it is (mostly) possible (I'm not saying you have to do that) to implement it to return a non-canonical path by looking at auxiliary vector (AT_EXECFN). One tricky aspect of that is that if you execute the binary using a relative path (`./lldb-server`) then the auxiliary vector will contain a relative path, which means one would have to fetch it and make it absolute sufficiently early so that the CWD doesn't change. > > > Whatever we do, I think it is better to resolve the symlink as late as > > possible as that gives us more options down the line. What I don't > > understand is why doesn't this work for your use case already -- > > `GetModuleFileSpecForHostAddress` calls `FileSystem::Resolve`, which should > > give you the canonical path for the library. Does that fail for some > > reason? It is it because the (relative) path returned by > > `GetModuleFileSpecForHostAddress` is resolved relative to CWD (but in > > reality we've executed it by finding the executable on the path)? > > I'm assuming this is referring to the other issue, which I discuss in > #131609? Because the issue in the current PR is not related to > `GetModuleFileSpecForHostAddress` - `argv[0]` is piped directly into > `spawn_process` without any canonicalization of paths. Kind of yes, but the two issues are related. The issue with symlinks is that once you resolve them, there's no way to go back. I'm asking why (in the scenario you describe in that PR) does `GetModuleFileSpecForHostAddress` return "lldb-server-19" (instead of "/usr/bin/lldb-server-19" or "/usr/lib/llvm-19/bin/lldb-server") https://github.com/llvm/llvm-project/pull/131519 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose the Target API lock through the SB API (PR #131404)
@@ -1692,6 +1692,21 @@ class Target : public
std::enable_shared_from_this,
}
};
+/// The private implementation backing SBLock.
+class APILock {
+public:
+ APILock(std::shared_ptr mutex_sp)
+ : m_mutex(std::move(mutex_sp)), m_lock(*m_mutex) {}
+
+ void Unlock() { m_lock.unlock(); }
+
+ operator bool() const { return static_cast(m_lock); }
+
labath wrote:
What would you say to removing these, and having SBLock::Unlock do its work by
clearing the unique_ptr ?
https://github.com/llvm/llvm-project/pull/131404
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose the Target API lock through the SB API (PR #131404)
https://github.com/labath approved this pull request. https://github.com/llvm/llvm-project/pull/131404 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Do not bump memory modificator ID when "internal" debugger memory is updated (PR #129092)
labath wrote: > So having a way to indicate you need the faster vrs. the more bullet-proof > behavior might be an acceptable solution. You might even argue that the > setting should be "bullet-proof behavior" by default. If you are shipping a > data formatter that benefits from this setting, you can also set the setting > in the module that installs the data formatters... Or make it an expression flag that can be set (in SBExpressionOptions) on expressions that you know are safe. (But generally yes, it's better (and faster) to avoid expression evaluation altogether. I don't know how many data formatters are you dealing with, but I would recommend changing them to not do that.) https://github.com/llvm/llvm-project/pull/129092 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
@@ -0,0 +1,273 @@
+//===-- DILParser.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
+//
+// This implements the recursive descent parser for the Data Inspection
+// Language (DIL), and its helper functions, which will eventually underlie the
+// 'frame variable' command. The language that this parser recognizes is
+// described in lldb/docs/dil-expr-lang.ebnf
+//
+//===--===//
+
+#include "lldb/ValueObject/DILParser.h"
+#include "lldb/Target/ExecutionContextScope.h"
+#include "lldb/Utility/DiagnosticsRendering.h"
+#include "lldb/ValueObject/DILAST.h"
+#include "lldb/ValueObject/DILEval.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/FormatAdapters.h"
+#include
+#include
+#include
+#include
+#include
+
+namespace lldb_private::dil {
+
+std::string FormatDiagnostics(llvm::StringRef text, const std::string &message,
+ uint32_t loc, uint16_t err_len) {
+ DiagnosticDetail::SourceLocation sloc = {
+ FileSpec{}, /*line=*/1, static_cast(loc + 1),
+ err_len,false, /*in_user_input=*/true};
+ std::string arrow_str = "^";
+ std::string rendered_msg =
+ llvm::formatv(":1:{0}: {1}\n1 | {2}\n | ^",
+loc + 1, message, text);
+ DiagnosticDetail detail;
+ detail.source_location = sloc;
+ detail.severity = lldb::eSeverityError;
+ detail.message = message;
+ detail.rendered = rendered_msg;
+ std::vector diagnostics;
+ diagnostics.push_back(detail);
+ StreamString diag_stream(true);
+ RenderDiagnosticDetails(diag_stream, 7, true, diagnostics);
+ std::string ret_str = text.str() + "\n" + diag_stream.GetString().str();
+ return ret_str;
+}
+
+llvm::Expected
+DILParser::Parse(llvm::StringRef dil_input_expr, DILLexer lexer,
+ std::shared_ptr frame_sp,
+ lldb::DynamicValueType use_dynamic, bool use_synthetic,
+ bool fragile_ivar, bool check_ptr_vs_member) {
+ Status error;
+ DILParser parser(dil_input_expr, lexer, frame_sp, use_dynamic, use_synthetic,
+ fragile_ivar, check_ptr_vs_member, error);
+ return parser.Run();
labath wrote:
Let's check the error here, as that's where the object is declared.
```suggestion
llvm::Error error;
DILParser parser(dil_input_expr, std::move(lexer), frame_sp, use_dynamic,
use_synthetic,
fragile_ivar, check_ptr_vs_member, error);
ASTNodeUP node_up = parser.Run();
if (error)
return error;
return node_up;
```
https://github.com/llvm/llvm-project/pull/120971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose the Target API lock through the SB API (PR #131404)
@@ -0,0 +1,46 @@
+//===-- SBLock.h
--===//
+//
+// 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_SBLOCK_H
+#define LLDB_API_SBLOCK_H
+
+#include "lldb/API/SBDefines.h"
+#include "lldb/lldb-forward.h"
+#include
+
+namespace lldb_private {
+class APILock;
+}
+
+namespace lldb {
+
+class LLDB_API SBLock {
+public:
+ SBLock();
+ SBLock(SBLock &&rhs);
+ SBLock &operator=(SBLock &&rhs);
+ ~SBLock();
+
+ bool IsValid() const;
+
+ void Unlock() const;
vogelsgesang wrote:
should we add documentation for this class?
I assume we would want to have this documented in
https://lldb.llvm.org/python_api/ ?
https://github.com/llvm/llvm-project/pull/131404
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose the Target API lock through the SB API (PR #131404)
@@ -0,0 +1,11 @@
+%extend lldb::SBLock {
+#ifdef SWIGPYTHON
+%pythoncode %{
+def __enter__(self):
+return self
+
+def __exit__(self, exc_type, exc_value, traceback):
+self.Unlock()
vogelsgesang wrote:
It's a bit unfortunate, that
```
lock = target.AcquireLock();
with lock:
# we are correctly locked here
with lock:
# we are no longer locked here :/
```
does not work as expected.
In Python, the convention seems to be that locks can be locked or unlocked, and
entering a `with` scope` acquires the lock. We might want to model this after
the Python's
[Lock](https://docs.python.org/3/library/threading.html#lock-objects) or
[RLock](std::unique_lock) objects, i.e. closer to a `std::unique_lock` than a
`std::lock_guard`
WDYT?
https://github.com/llvm/llvm-project/pull/131404
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [lldb][lldb-dap] Implement jump to cursor (PR #130503)
@@ -113,6 +113,20 @@ class ExceptionInfoRequestHandler : public RequestHandler {
void operator()(const llvm::json::Object &request) const override;
};
+class GoToRequestHandler : public RequestHandler {
vogelsgesang wrote:
@da-viper for your Pull Request, I would recommend sticking to the existing
practice, i.e. use the DAP style (camelCase) for all classes which model the
DAP protocol.
In case we do indeed decide to go with the LLDB snake_case code style, we can
later on apply the snake_casing globally, across all protocol classes, also
independently of your PR
https://github.com/llvm/llvm-project/pull/130503
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Telemetry]Define TargetInfo for collecting data about a target (PR #127834)
@@ -1064,6 +1065,29 @@ const char *Process::GetExitDescription() {
bool Process::SetExitStatus(int status, llvm::StringRef exit_string) {
// Use a mutex to protect setting the exit status.
std::lock_guard guard(m_exit_status_mutex);
+ telemetry::ScopedDispatcher helper;
+
+ // Find the executable-module's UUID, if available.
+ UUID exec_uuid;
+ // Check if there is (still) a valid target and get the debugger and
exec_uuid
+ // from it.
+ TargetSP target_sp(Debugger::FindTargetWithProcessID(m_pid));
+ if (target_sp) {
+helper.SetDebugger(&(target_sp->GetDebugger()));
+exec_uuid = target_sp->GetExecModuleUUID();
oontvoo wrote:
Oh, ok - thanks! will apply this in the rollforward patch.
https://github.com/llvm/llvm-project/pull/127834
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Use correct path for lldb-server executable (PR #131519)
labath wrote: > > Kind of yes, but the two issues are related. The issue with symlinks is > > that once you resolve them, there's no way to go back. I'm asking why (in > > the scenario you describe in that PR) does > > `GetModuleFileSpecForHostAddress` return "lldb-server-19" (instead of > > "/usr/bin/lldb-server-19" or "/usr/lib/llvm-19/bin/lldb-server") > > So, regarding that issue - first of all, `GetModuleFileSpecForHostAddress` > doesn't follow symlinks. I'm not sure if that's a bug or intended behavior > but I don't see anything in `FileSystem::Resolve` that attempts to follow > symlinks - it just makes a relative or `~`-path absolute. I'm sorry, my bad. I saw the tilde resolution code and somehow assumed that canonicalization must follow. I think the lack of symlink resolution is intentional. > > Now, what you said about resolving relative to cwd instead of relative to > $PATH also happens there, but that's actually the reason the entire thing > works in the first place - the fact that this resolves relative to cwd causes > `ComputePathRelativeToLibrary` to fail .. because of [this check](https://github.com/llvm/llvm-project/blob/9b1f905b483a2b42e4681bbef42b2641f8ccf5ad/lldb/source/Host/common/HostInfoBase.cpp#L237), presumably > and then `ComputeSupportExeDirectory` falls back to using > `GetProgramFileSpec`. So, this bug masks the first bug. Got it. And I think I finally understand what those checks in ComputeSupportExeDirectory are doing. > > Not exactly. I my use case, `lldb-server` would be a symlink to something > > like `/cas/dead/beef/baadf00d`. The symlink value is supposed to be an > > implementation detail of the CAS system. While the user could execute that > > directly, it wouldn't be totally surprising that it does not work. > > Then maybe we should just execute the path given by `GetProgramFileSpec` but > pass our argv[0] into execve's argv[0] (I don't know if the current process > execution abstraction allows that) I think that'd be fine, given that I know how to get GetProgramFileSpec to return the non-canonical path if that becomes necessary. And it matches what the code was doing originally. Process(Launch)Info has a [GS]etArg0 method, but it looks like ProcessLauncherPosixFork doesn't actually make use of it. It shouldn't be too hard to change that though. Would you like to try that? (If not, I can do it, probably next week) https://github.com/llvm/llvm-project/pull/131519 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][DWARFASTParserClang] Adjust language type for conflicting Objective-C++ forward declarations (PR #130768)
Michael137 wrote: > > Essentially you're suggesting going back to pre-#90663, but only if we have > > ObjC/ObjC++ CUs in the current module? Seems sensible to me. Will also help > > prevent similar issues from creeping up in the future > > Yes, I think that is the best approach do to do definition search (devil's in > the details of course), though I'm still not very happy about having to do > this search in the first place. > > Overall, I think I'd like the "forceful completion" approach more, though I > understand it's fraught with more perils. I'm reasonably confident it can be > made to work in the expression evaluator, but things like "frame variable" > (which work directly on the module AST) are trickier, and I never got that to > work with -flimit-debug-info (ran out of time). This case should be slightly > simpler than that for two reasons: > > * both of the types are in the same module (no need to jump to another module > to search for the definition) > * You don't need to support cases where another class inherits from a > "forcefully completed" class > > So, it _might_ be possible to implement something like this inside the > `CompilerType` class, where if you get asked for a property of a type, and > you see that it's one of these weird "maybe ObjC" types, you return the > relevant property of the ObjC counterpart instead. Coming back to this now. IIUC, you're saying when we `CompleteType` one of these C++ forward declarations, if `FindDefintionDIE` returns an Objective-C definition, we bail out of starting/completing the definition and keep it as a C++ forward declaration but mark the `CompilerType` as one of those mixed decls? I guess what I'm not seeing is when and where we would stash away the Objective-C decl so the `CompilerType` can do the switch? Also, to make this work with the expression evaluator we need to make sure that when Clang asks for a complete definition using the `ExternalASTSource`, we will be able to provide one https://github.com/llvm/llvm-project/pull/130768 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][DWARFASTParserClang] Adjust language type for conflicting Objective-C++ forward declarations (PR #130768)
labath wrote: I was imagining storing this in the ClangASTMetadata class (that's where the forceful completion bit is)? I don't know if it can be done without increasing the class size, but I guess that doesn't matter for the purpose of determining feasibility. https://github.com/llvm/llvm-project/pull/130768 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adding support for cancelling a request. (PR #130169)
@@ -96,7 +115,7 @@ Expected> Transport::Read() {
return createStringError(
formatv("invalid content length {0}", *raw_length).str());
- Expected raw_json = ReadFull(*input, length);
labath wrote:
> Closing a file descriptor does not interrupt in progress reads, I think its
> platform dependent on what happens.
Very much so. It's also basically impossible to do this in race-free manner,.
> Also, frustrating on Windows stdin is an anonymous pipe and anonymous pipes
> do not support
I don't know if this helps you (since you still have to use a dedicated API
instead of `select(2)`), but `lldb_private::Pipe` works around this by creating
a named pipe with an random name (from what I've read, that's actually how
windows implements anonymous pipes internally).
https://github.com/llvm/llvm-project/pull/130169
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Use correct path for lldb-server executable (PR #131519)
yuvald-sweet-security wrote: > Kind of yes, but the two issues are related. The issue with symlinks is that > once you resolve them, there's no way to go back. I'm asking why (in the > scenario you describe in that PR) does `GetModuleFileSpecForHostAddress` > return "lldb-server-19" (instead of "/usr/bin/lldb-server-19" or > "/usr/lib/llvm-19/bin/lldb-server") So, regarding that issue - first of all, `GetModuleFileSpecForHostAddress` doesn't follow symlinks. I'm not sure if that's a bug or intended behavior but I don't see anything in `FileSystem::Resolve` that attempts to follow symlinks - it just makes a relative or `~`-path absolute. Now, what you said about resolving relative to cwd instead of relative to $PATH also happens there, but that's actually the reason the entire thing works in the first place - the fact that this resolves relative to cwd causes `ComputePathRelativeToLibrary` to fail and then `ComputeSupportExeDirectory` falls back to using `GetProgramFileSpec`. So, this bug masks the first bug. https://github.com/llvm/llvm-project/pull/131519 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [lldb][lldb-dap] Implement jump to cursor (PR #130503)
https://github.com/vogelsgesang edited https://github.com/llvm/llvm-project/pull/130503 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
cmtice wrote: > Okay, at this I don't think I have any more comments about functionality. The > remaining comments are either stylistic (which should be self-explanatory) or > about error handling (which I'm going to write about here). > > For the error handling, I missed the fact that your new implementation throws > away the structured diagnostic info after using it to construct the error > string. That kinda misses the point, which is to provide the rest of lldb > with a structured representation of the error. It looks like the base > DiagnosticError is abstract, so for that we need to create our own error > subclass of that. I tried to sketch it out in the inline comments (by > combining the existing `ExpressionError` class and your code), but this is > only a rough sketch -- you'll certainly need to adjust it to make it work. > You can tell whether you've succeded by looking at how the new "frame var" > error messages are formatted. They should come out in the same was as in the > snippet that [Jim > posted](https://github.com/llvm/llvm-project/pull/120971#issuecomment-2722987750). > > The other set of suggested changes is about changing the error representation > from Status to llvm::Error. We're basically already using the error object as > if it was an llvm::Error, so I think we should just complete the transition > and use it throughout the DIL. I think you've misunderstood the code? I don't just throw away the DiagnosticDetail -- its formatted error message, which is what you've been asking for, gets passed back into the Status error, which LLDB then prints out. So the current implementation is giving the formatted error messages now (without any of your further suggested changes): (lldb) v externGlobalVar error: externGlobalVar ˄ ╰─ error: use of undeclared identifier 'externGlobalVar' (lldb) v 'cat + dog' error: cat + dog ˄ ╰─ error: use of undeclared identifier 'cat' (lldb) v globalVar%%32 error: globalVar%%32 ˄ ╰─ error: Unexpected token: <'%' (percent)> https://github.com/llvm/llvm-project/pull/120971 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Use correct path for lldb-server executable (PR #131519)
yuvald-sweet-security wrote: I wrote something, lets see if it works >Process(Launch)Info has a [GS]etArg0 method, but it looks like >ProcessLauncherPosixFork doesn't actually make use of it It looks like nothing makes use of it except for the qemu launcher; the posix launcher just uses the first element in `info.GetArguments()`. I set both to be safe. https://github.com/llvm/llvm-project/pull/131519 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] s/ValidRange/ValidRanges in UnwindPlan (PR #127661)
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/127661
>From 22c489dbd334fb84b8d81deac8e7e6c5590fc6d9 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Tue, 18 Feb 2025 16:14:30 +0100
Subject: [PATCH 1/2] [lldb] s/ValidRange/ValidRanges in UnwindPlan
To be able to describe discontinuous functions, this patch changes the
UnwindPlan to accept more than one address range.
I've also squeezed in a couple improvements/modernizations, for example
using the lower_bound function instead of a linear scan.
---
lldb/include/lldb/Symbol/UnwindPlan.h | 17 ++--
.../ObjectFile/PECOFF/PECallFrameInfo.cpp | 4 +-
.../Breakpad/SymbolFileBreakpad.cpp | 12 +--
.../x86/x86AssemblyInspectionEngine.cpp | 4 +-
lldb/source/Symbol/CompactUnwindInfo.cpp | 2 +-
lldb/source/Symbol/DWARFCallFrameInfo.cpp | 2 +-
lldb/source/Symbol/UnwindPlan.cpp | 89 ---
lldb/unittests/Symbol/CMakeLists.txt | 1 +
lldb/unittests/Symbol/UnwindPlanTest.cpp | 76
.../x86/Testx86AssemblyInspectionEngine.cpp | 6 +-
10 files changed, 138 insertions(+), 75 deletions(-)
create mode 100644 lldb/unittests/Symbol/UnwindPlanTest.cpp
diff --git a/lldb/include/lldb/Symbol/UnwindPlan.h
b/lldb/include/lldb/Symbol/UnwindPlan.h
index 7c361bc08bcfe..db9aade93b6ba 100644
--- a/lldb/include/lldb/Symbol/UnwindPlan.h
+++ b/lldb/include/lldb/Symbol/UnwindPlan.h
@@ -438,7 +438,7 @@ class UnwindPlan {
// Performs a deep copy of the plan, including all the rows (expensive).
UnwindPlan(const UnwindPlan &rhs)
- : m_plan_valid_address_range(rhs.m_plan_valid_address_range),
+ : m_plan_valid_ranges(rhs.m_plan_valid_ranges),
m_register_kind(rhs.m_register_kind),
m_return_addr_register(rhs.m_return_addr_register),
m_source_name(rhs.m_source_name),
@@ -492,10 +492,8 @@ class UnwindPlan {
// This UnwindPlan may not be valid at every address of the function span.
// For instance, a FastUnwindPlan will not be valid at the prologue setup
// instructions - only in the body of the function.
- void SetPlanValidAddressRange(const AddressRange &range);
-
- const AddressRange &GetAddressRange() const {
-return m_plan_valid_address_range;
+ void SetPlanValidAddressRanges(std::vector ranges) {
+m_plan_valid_ranges = std::move(ranges);
}
bool PlanValidAtAddress(Address addr);
@@ -544,11 +542,11 @@ class UnwindPlan {
m_plan_is_for_signal_trap = is_for_signal_trap;
}
- int GetRowCount() const;
+ int GetRowCount() const { return m_row_list.size(); }
void Clear() {
m_row_list.clear();
-m_plan_valid_address_range.Clear();
+m_plan_valid_ranges.clear();
m_register_kind = lldb::eRegisterKindDWARF;
m_source_name.Clear();
m_plan_is_sourced_from_compiler = eLazyBoolCalculate;
@@ -571,9 +569,8 @@ class UnwindPlan {
}
private:
- typedef std::vector collection;
- collection m_row_list;
- AddressRange m_plan_valid_address_range;
+ std::vector m_row_list;
+ std::vector m_plan_valid_ranges;
lldb::RegisterKind m_register_kind; // The RegisterKind these register
numbers
// are in terms of - will need to be
// translated to lldb native reg nums at unwind time
diff --git a/lldb/source/Plugins/ObjectFile/PECOFF/PECallFrameInfo.cpp
b/lldb/source/Plugins/ObjectFile/PECOFF/PECallFrameInfo.cpp
index 459abe417035e..a7c2e4f0b8dbc 100644
--- a/lldb/source/Plugins/ObjectFile/PECOFF/PECallFrameInfo.cpp
+++ b/lldb/source/Plugins/ObjectFile/PECOFF/PECallFrameInfo.cpp
@@ -495,9 +495,9 @@ bool PECallFrameInfo::GetUnwindPlan(const AddressRange
&range,
for (auto it = rows.rbegin(); it != rows.rend(); ++it)
unwind_plan.AppendRow(std::move(*it));
- unwind_plan.SetPlanValidAddressRange(AddressRange(
+ unwind_plan.SetPlanValidAddressRanges({AddressRange(
m_object_file.GetAddress(runtime_function->StartAddress),
- runtime_function->EndAddress - runtime_function->StartAddress));
+ runtime_function->EndAddress - runtime_function->StartAddress)});
unwind_plan.SetUnwindPlanValidAtAllInstructions(eLazyBoolNo);
return true;
diff --git a/lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
b/lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
index 222e04a6a3464..ce2ba69be2e96 100644
--- a/lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
+++ b/lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
@@ -656,9 +656,9 @@ SymbolFileBreakpad::ParseCFIUnwindPlan(const Bookmark
&bookmark,
plan_sp->SetUnwindPlanValidAtAllInstructions(eLazyBoolNo);
plan_sp->SetUnwindPlanForSignalTrap(eLazyBoolNo);
plan_sp->SetSourcedFromCompiler(eLazyBoolYes);
- plan_sp->SetPlanValidAddressRange(
- AddressRange(base + init_record->Address, *init_record->Size,
- m_objfile_sp->GetModule()->GetSectionList()));
+ plan_sp->SetPlanValidAddressRange
[Lldb-commits] [lldb] [llvm] [lldb][lldb-dap] Implement jump to cursor (PR #130503)
@@ -0,0 +1,165 @@
+//===-- GoToTargetsRequestHandler.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 "DAP.h"
+
+#include "JSONUtils.h"
+
+#include
+#include
+#include
+
+namespace lldb_dap {
+
+static llvm::SmallVector
+GetLineValidEntry(DAP &dap, const lldb::SBFileSpec &file_spec, uint32_t line) {
+ // disable breakpoint listeners so they do not send events to the DAP client.
+ lldb::SBListener listener = dap.debugger.GetListener();
+ lldb::SBBroadcaster broadcaster = dap.target.GetBroadcaster();
+ constexpr auto event_mask = lldb::SBTarget::eBroadcastBitBreakpointChanged;
+ listener.StopListeningForEvents(broadcaster, event_mask);
da-viper wrote:
At the moment we do not broadcast breakpoint that is not owned by dap. But I
think we should as it will make setting breakpoint from the debug console
possible.
https://github.com/llvm/llvm-project/pull/130503
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
labath wrote:
It's close, but it's not the same thing. Notice your arrow points into the
error message:
```
(lldb) v externGlobalVar
error: externGlobalVar
˄
╰─ error: use of undeclared identifier 'externGlobalVar'
```
While for `expr`, it points directly into the command:
```
(lldb) expr 1.0+""
˄
╰─ error: invalid operands to binary expression ('double' and
'const char[1]')
```
For that, you really need to return the error in a structured form. The string
itself is needed as well, as it's used in contexts where it's impossible to
show inline diagnostics, or because they have been disabled:
```
And if I disable inline diagnostics I, get the usual clang output:
```
(lldb) set set show-inline-diagnostics false
(lldb) expr 1.0+""
error: :1:4: invalid operands to binary expression ('double'
and 'const char[1]')
1 | 1.0+""
| ~~~^~~
```
For this purpose, you could use your original code, or maybe what you have now
is fine as well.
https://github.com/llvm/llvm-project/pull/120971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix prologue size calculation for discontinuous functions (PR #131597)
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/131597 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fdeb2ff - [lldb] Fix prologue size calculation for discontinuous functions (#131597)
Author: Pavel Labath
Date: 2025-03-20T16:01:24+01:00
New Revision: fdeb2ff30407afbfc3596aaf417a2a91cdff20c9
URL:
https://github.com/llvm/llvm-project/commit/fdeb2ff30407afbfc3596aaf417a2a91cdff20c9
DIFF:
https://github.com/llvm/llvm-project/commit/fdeb2ff30407afbfc3596aaf417a2a91cdff20c9.diff
LOG: [lldb] Fix prologue size calculation for discontinuous functions (#131597)
When searching for the end of prologue, I'm only iterating through the
address range (~basic block) which contains the function entry point.
The reason for that is that even if some other range somehow contained
the end-of-prologue marker, the fact that it's in a different range
would imply it's reachable through some form of control flow, and that's
usually not a good place to set an function entry breakpoint.
Added:
Modified:
lldb/source/Symbol/Function.cpp
lldb/test/Shell/SymbolFile/DWARF/x86/discontinuous-function.s
Removed:
diff --git a/lldb/source/Symbol/Function.cpp b/lldb/source/Symbol/Function.cpp
index c80f37ae68d9d..2c4467cc2e9c5 100644
--- a/lldb/source/Symbol/Function.cpp
+++ b/lldb/source/Symbol/Function.cpp
@@ -662,10 +662,15 @@ uint32_t Function::GetPrologueByteSize() {
}
}
-const addr_t func_start_file_addr =
-m_range.GetBaseAddress().GetFileAddress();
-const addr_t func_end_file_addr =
-func_start_file_addr + m_range.GetByteSize();
+AddressRange entry_range;
+m_block.GetRangeContainingAddress(m_address, entry_range);
+
+// Deliberately not starting at entry_range.GetBaseAddress() because
the
+// function entry point need not be the first address in the range.
+const addr_t func_start_file_addr = m_address.GetFileAddress();
+const addr_t range_end_file_addr =
+entry_range.GetBaseAddress().GetFileAddress() +
+entry_range.GetByteSize();
// Now calculate the offset to pass the subsequent line 0 entries.
uint32_t first_non_zero_line = prologue_end_line_idx;
@@ -677,7 +682,7 @@ uint32_t Function::GetPrologueByteSize() {
break;
}
if (line_entry.range.GetBaseAddress().GetFileAddress() >=
- func_end_file_addr)
+ range_end_file_addr)
break;
first_non_zero_line++;
@@ -692,15 +697,15 @@ uint32_t Function::GetPrologueByteSize() {
}
}
-// Verify that this prologue end file address in the function's address
-// range just to be sure
+// Verify that this prologue end file address inside the function just
+// to be sure
if (func_start_file_addr < prologue_end_file_addr &&
-prologue_end_file_addr < func_end_file_addr) {
+prologue_end_file_addr < range_end_file_addr) {
m_prologue_byte_size = prologue_end_file_addr - func_start_file_addr;
}
if (prologue_end_file_addr < line_zero_end_file_addr &&
-line_zero_end_file_addr < func_end_file_addr) {
+line_zero_end_file_addr < range_end_file_addr) {
m_prologue_byte_size +=
line_zero_end_file_addr - prologue_end_file_addr;
}
diff --git a/lldb/test/Shell/SymbolFile/DWARF/x86/discontinuous-function.s
b/lldb/test/Shell/SymbolFile/DWARF/x86/discontinuous-function.s
index 197ab9aa14910..06934c2bfe9c4 100644
--- a/lldb/test/Shell/SymbolFile/DWARF/x86/discontinuous-function.s
+++ b/lldb/test/Shell/SymbolFile/DWARF/x86/discontinuous-function.s
@@ -16,22 +16,32 @@ image lookup -v -n foo
# CHECK-LABEL: image lookup -v -n foo
# CHECK: 1 match found in {{.*}}
# CHECK: Summary: input.o`foo
-# CHECK: Function: id = {{.*}}, name = "foo", ranges =
[0x-0x000e)[0x0014-0x001c)
+# CHECK: Function: id = {{.*}}, name = "foo", ranges =
[0x-0x000f)[0x0015-0x001d)
image lookup -v --regex -n '^foo$'
# CHECK-LABEL: image lookup -v --regex -n '^foo$'
# CHECK: 1 match found in {{.*}}
# CHECK: Summary: input.o`foo
-# CHECK: Function: id = {{.*}}, name = "foo", ranges =
[0x-0x000e)[0x0014-0x001c)
+# CHECK: Function: id = {{.*}}, name = "foo", ranges =
[0x-0x000f)[0x0015-0x001d)
expr -- &foo
# CHECK-LABEL: expr -- &foo
# CHECK: (void (*)()) $0 = 0x0007
+breakpoint set --name foo --skip-prologue false
+# CHECK-LABEL: breakpoint set --name foo --skip-prologue false
+# CHECK: Breakpoint 1: where = input.o`foo at -:1, address = 0x0007
+
+breakpoint set --name foo --skip-prologue true
+# CHECK-LABEL: breakpoint set --name foo --skip-prologue true
+# CHECK: Breakpoint 2: where = input.o`foo + 1 at -:2, address =
0x0008
+
#--- input.s
.text
[Lldb-commits] [lldb] [lldb] Use correct path for lldb-server executable (PR #131519)
https://github.com/yuvald-sweet-security updated
https://github.com/llvm/llvm-project/pull/131519
>From ea0a08e60f472c518c98db0acf7e32ec328146d1 Mon Sep 17 00:00:00 2001
From: Yuval Deutscher
Date: Sun, 16 Mar 2025 14:08:57 +
Subject: [PATCH 1/2] [lldb] Use correct path for lldb-server executable
---
lldb/tools/lldb-server/lldb-platform.cpp | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/lldb/tools/lldb-server/lldb-platform.cpp
b/lldb/tools/lldb-server/lldb-platform.cpp
index 880b45b989b9c..51174a0f443c3 100644
--- a/lldb/tools/lldb-server/lldb-platform.cpp
+++ b/lldb/tools/lldb-server/lldb-platform.cpp
@@ -31,6 +31,7 @@
#include "Plugins/Process/gdb-remote/ProcessGDBRemoteLog.h"
#include "lldb/Host/ConnectionFileDescriptor.h"
#include "lldb/Host/HostGetOpt.h"
+#include "lldb/Host/HostInfo.h"
#include "lldb/Host/MainLoop.h"
#include "lldb/Host/OptionParser.h"
#include "lldb/Host/Socket.h"
@@ -256,8 +257,9 @@ static void
client_handle(GDBRemoteCommunicationServerPlatform &platform,
printf("Disconnected.\n");
}
-static Status spawn_process(const char *progname, const Socket *conn_socket,
-uint16_t gdb_port, const lldb_private::Args &args,
+static Status spawn_process(const char *progname, const FileSpec &prog,
+const Socket *conn_socket, uint16_t gdb_port,
+const lldb_private::Args &args,
const std::string &log_file,
const StringRef log_channels, MainLoop &main_loop)
{
Status error;
@@ -267,9 +269,10 @@ static Status spawn_process(const char *progname, const
Socket *conn_socket,
ProcessLaunchInfo launch_info;
- FileSpec self_spec(progname, FileSpec::Style::native);
- launch_info.SetExecutableFile(self_spec, true);
+ launch_info.SetExecutableFile(prog, false);
+ launch_info.SetArg0(progname);
Args &self_args = launch_info.GetArguments();
+ self_args.AppendArgument(progname);
self_args.AppendArgument(llvm::StringRef("platform"));
self_args.AppendArgument(llvm::StringRef("--child-platform-fd"));
self_args.AppendArgument(llvm::to_string(shared_socket.GetSendableFD()));
@@ -551,9 +554,10 @@ int main_platform(int argc, char *argv[]) {
log_channels, &main_loop,
&platform_handles](std::unique_ptr sock_up) {
printf("Connection established.\n");
- Status error = spawn_process(progname, sock_up.get(),
- gdbserver_port, inferior_arguments,
- log_file, log_channels, main_loop);
+ Status error = spawn_process(
+ progname, HostInfo::GetProgramFileSpec(), sock_up.get(),
+ gdbserver_port, inferior_arguments, log_file, log_channels,
+ main_loop);
if (error.Fail()) {
Log *log = GetLog(LLDBLog::Platform);
LLDB_LOGF(log, "spawn_process failed: %s", error.AsCString());
>From dc67b5776c60a0a4443fa76402f182ed6ca3b3b1 Mon Sep 17 00:00:00 2001
From: Yuval Deutscher
Date: Thu, 20 Mar 2025 17:01:41 +0200
Subject: [PATCH 2/2] [lldb] Respect arg0 override in fork/exec launcher
---
.../Host/posix/ProcessLauncherPosixFork.cpp| 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
index 3e956290c3055..cbc0234dbd016 100644
--- a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
+++ b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
@@ -94,6 +94,7 @@ struct ForkLaunchInfo {
bool debug;
bool disable_aslr;
std::string wd;
+ std::string executable;
const char **argv;
Environment::Envp envp;
std::vector actions;
@@ -194,7 +195,8 @@ struct ForkLaunchInfo {
}
// Execute. We should never return...
- execve(info.argv[0], const_cast(info.argv), info.envp);
+ execve(info.executable.c_str(), const_cast(info.argv),
+ info.envp);
#if defined(__linux__)
if (errno == ETXTBSY) {
@@ -207,7 +209,8 @@ struct ForkLaunchInfo {
// Since this state should clear up quickly, wait a while and then give it
// one more go.
usleep(5);
-execve(info.argv[0], const_cast(info.argv), info.envp);
+execve(info.executable.c_str(), const_cast(info.argv),
+ info.envp);
}
#endif
@@ -236,8 +239,17 @@ ForkLaunchInfo::ForkLaunchInfo(const ProcessLaunchInfo
&info)
debug(info.GetFlags().Test(eLaunchFlagDebug)),
disable_aslr(info.GetFlags().Test(eLaunchFlagDisableASLR)),
wd(info.GetWorkingDirectory().GetPath()),
+ executable(info.GetExecutableFile().GetPath()),
argv(info.GetArguments().GetConstArgumentVector()),
- envp(info.GetEnvironment().getEnvp()), actions(MakeForkActions(info)) {}
+ envp(info.GetEnvironme
[Lldb-commits] [clang] [clang-tools-extra] [lldb] Reland: [clang] preserve class type sugar when taking pointer to member (PR #132234)
erichkeane wrote: Clang stuff is unchanged, correct? If so I'm fine when the LLDB folks are happy. https://github.com/llvm/llvm-project/pull/132234 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [lldb][lldb-dap] Implement jump to cursor (PR #130503)
@@ -113,6 +113,20 @@ class ExceptionInfoRequestHandler : public RequestHandler {
void operator()(const llvm::json::Object &request) const override;
};
+class GoToRequestHandler : public RequestHandler {
+public:
+ using RequestHandler::RequestHandler;
+ static llvm::StringLiteral getCommand() { return "goto"; }
vogelsgesang wrote:
After rebasing on main... This function got renamed in
1028ea9e2641341436555347fb65d6f2eafcfbdd
```suggestion
static llvm::StringLiteral GetCommand() { return "goto"; }
```
https://github.com/llvm/llvm-project/pull/130503
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [lldb][lldb-dap] Implement jump to cursor (PR #130503)
https://github.com/da-viper updated
https://github.com/llvm/llvm-project/pull/130503
>From 7bad765585b2ae96faf2d2558b099f4b965d2791 Mon Sep 17 00:00:00 2001
From: Ezike Ebuka
Date: Sun, 9 Mar 2025 12:46:54 +
Subject: [PATCH 01/21] [lldb-dap] implement jump to cursor.
---
lldb/cmake/modules/LLDBConfig.cmake | 2 +-
lldb/tools/lldb-dap/CMakeLists.txt| 2 +
lldb/tools/lldb-dap/DAP.cpp | 23 +++-
lldb/tools/lldb-dap/DAP.h | 27 +++-
.../lldb-dap/Handler/GoToRequestHandler.cpp | 103 +++
.../Handler/GoToTargetsRequestHandler.cpp | 120 ++
lldb/tools/lldb-dap/Handler/RequestHandler.h | 14 ++
lldb/tools/lldb-dap/lldb-dap.cpp | 2 +
8 files changed, 290 insertions(+), 3 deletions(-)
create mode 100644 lldb/tools/lldb-dap/Handler/GoToRequestHandler.cpp
create mode 100644 lldb/tools/lldb-dap/Handler/GoToTargetsRequestHandler.cpp
diff --git a/lldb/cmake/modules/LLDBConfig.cmake
b/lldb/cmake/modules/LLDBConfig.cmake
index 9df71edd8b359..a2f9a29b6d5d5 100644
--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -57,7 +57,7 @@ add_optional_dependency(LLDB_ENABLE_CURSES "Enable curses
support in LLDB" Curse
add_optional_dependency(LLDB_ENABLE_LZMA "Enable LZMA compression support in
LLDB" LibLZMA LIBLZMA_FOUND)
add_optional_dependency(LLDB_ENABLE_LUA "Enable Lua scripting support in LLDB"
LuaAndSwig LUAANDSWIG_FOUND)
add_optional_dependency(LLDB_ENABLE_PYTHON "Enable Python scripting support in
LLDB" PythonAndSwig PYTHONANDSWIG_FOUND)
-add_optional_dependency(LLDB_ENABLE_LIBXML2 "Enable Libxml 2 support in LLDB"
LibXml2 LIBXML2_FOUND VERSION 2.8)
+add_optional_dependency(LLDB_ENABLE_LIBXML2 "Enable Libxml 2 support in LLDB"
LibXml2 LIBXML2_FOUND VERSION)
add_optional_dependency(LLDB_ENABLE_FBSDVMCORE "Enable libfbsdvmcore support
in LLDB" FBSDVMCore FBSDVMCore_FOUND QUIET)
option(LLDB_USE_ENTITLEMENTS "When codesigning, use entitlements if available"
ON)
diff --git a/lldb/tools/lldb-dap/CMakeLists.txt
b/lldb/tools/lldb-dap/CMakeLists.txt
index 93c5ee4426783..0709b2b2dc699 100644
--- a/lldb/tools/lldb-dap/CMakeLists.txt
+++ b/lldb/tools/lldb-dap/CMakeLists.txt
@@ -45,6 +45,8 @@ add_lldb_tool(lldb-dap
Handler/DisconnectRequestHandler.cpp
Handler/EvaluateRequestHandler.cpp
Handler/ExceptionInfoRequestHandler.cpp
+Handler/GoToRequestHandler.cpp
+Handler/GoToTargetsRequestHandler.cpp
Handler/InitializeRequestHandler.cpp
Handler/LaunchRequestHandler.cpp
Handler/LocationsRequestHandler.cpp
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index 65de0488729e5..986ac5c3bb408 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -81,7 +81,7 @@ DAP::DAP(llvm::StringRef path, Log *log, const ReplMode
default_repl_mode,
configuration_done_sent(false), waiting_for_run_in_terminal(false),
progress_event_reporter(
[&](const ProgressEvent &event) { SendJSON(event.ToJSON()); }),
- reverse_request_seq(0), repl_mode(default_repl_mode) {}
+ reverse_request_seq(0), repl_mode(default_repl_mode), goto_id_map() {}
DAP::~DAP() = default;
@@ -841,6 +841,27 @@ lldb::SBError DAP::WaitForProcessToStop(uint32_t seconds) {
return error;
}
+std::optional Gotos::GetLineEntry(uint64_t id) const {
+ const auto iter = line_entries.find(id);
+ if (iter != line_entries.end())
+return iter->second;
+
+ return std::nullopt;
+}
+
+uint64_t Gotos::InsertLineEntry(lldb::SBLineEntry line_entry) {
+ const auto spec_id = this->NewSpecId();
+ line_entries.insert(std::make_pair(spec_id, line_entry));
+ return spec_id;
+}
+
+void Gotos::Clear() {
+ new_id = 0UL;
+ line_entries.clear();
+}
+
+uint64_t Gotos::NewSpecId() { return new_id++; }
+
void Variables::Clear() {
locals.Clear();
globals.Clear();
diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index 4b4d471161137..c280adb57d0c5 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -77,6 +77,27 @@ enum class PacketStatus {
enum class ReplMode { Variable = 0, Command, Auto };
+class Gotos {
+public:
+ /// \return the line_entry corresponding with \p id
+ ///
+ /// If \p id is invalid std::nullopt is returned.
+ std::optional GetLineEntry(uint64_t id) const;
+
+ /// Insert a new \p line_entry.
+ /// \return id assigned to this line_entry.
+ uint64_t InsertLineEntry(lldb::SBLineEntry line_entry);
+
+ /// clears all line entries and reset the generated ids.
+ void Clear();
+
+private:
+ uint64_t NewSpecId();
+
+ llvm::DenseMap line_entries;
+ uint64_t new_id = 0ul;
+};
+
struct Variables {
/// Variable_reference start index of permanent expandable variable.
static constexpr int64_t PermanentVariableStartIndex = (1ll << 32);
@@ -205,6 +226,7 @@ struct DAP {
// empty; if the previous expression was a variable expression, this string
//
[Lldb-commits] [lldb] [lldb] Expose the Target API lock through the SB API (PR #131404)
https://github.com/JDevlieghere updated
https://github.com/llvm/llvm-project/pull/131404
>From ab4700b007becba1dfe63310bbb2a627214b6a60 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere
Date: Wed, 19 Mar 2025 10:39:50 -0700
Subject: [PATCH 1/2] [lldb] Expose the Target API lock through the SB API
---
lldb/bindings/interface/SBLockExtensions.i| 11
lldb/bindings/interfaces.swig | 4 +-
lldb/include/lldb/API/LLDB.h | 1 +
lldb/include/lldb/API/SBDefines.h | 1 +
lldb/include/lldb/API/SBLock.h| 46 +++
lldb/include/lldb/API/SBTarget.h | 2 +
lldb/include/lldb/Target/Target.h | 15 +
lldb/source/API/CMakeLists.txt| 1 +
lldb/source/API/SBLock.cpp| 52 +
lldb/source/API/SBTarget.cpp | 16 --
.../API/python_api/target/TestTargetAPI.py| 28 +
lldb/unittests/API/CMakeLists.txt | 1 +
lldb/unittests/API/SBLockTest.cpp | 57 +++
13 files changed, 230 insertions(+), 5 deletions(-)
create mode 100644 lldb/bindings/interface/SBLockExtensions.i
create mode 100644 lldb/include/lldb/API/SBLock.h
create mode 100644 lldb/source/API/SBLock.cpp
create mode 100644 lldb/unittests/API/SBLockTest.cpp
diff --git a/lldb/bindings/interface/SBLockExtensions.i
b/lldb/bindings/interface/SBLockExtensions.i
new file mode 100644
index 0..27736c3f287b7
--- /dev/null
+++ b/lldb/bindings/interface/SBLockExtensions.i
@@ -0,0 +1,11 @@
+%extend lldb::SBLock {
+#ifdef SWIGPYTHON
+%pythoncode %{
+def __enter__(self):
+return self
+
+def __exit__(self, exc_type, exc_value, traceback):
+self.Unlock()
+%}
+#endif
+}
diff --git a/lldb/bindings/interfaces.swig b/lldb/bindings/interfaces.swig
index 08df9a1a8d539..3dffc23d1a4f7 100644
--- a/lldb/bindings/interfaces.swig
+++ b/lldb/bindings/interfaces.swig
@@ -47,6 +47,7 @@
%include "./interface/SBLaunchInfoDocstrings.i"
%include "./interface/SBLineEntryDocstrings.i"
%include "./interface/SBListenerDocstrings.i"
+%include "./interface/SBLockExtensions.i"
%include "./interface/SBMemoryRegionInfoDocstrings.i"
%include "./interface/SBMemoryRegionInfoListDocstrings.i"
%include "./interface/SBModuleDocstrings.i"
@@ -121,11 +122,12 @@
%include "lldb/API/SBHostOS.h"
%include "lldb/API/SBInstruction.h"
%include "lldb/API/SBInstructionList.h"
-%include "lldb/API/SBLanguages.h"
%include "lldb/API/SBLanguageRuntime.h"
+%include "lldb/API/SBLanguages.h"
%include "lldb/API/SBLaunchInfo.h"
%include "lldb/API/SBLineEntry.h"
%include "lldb/API/SBListener.h"
+%include "lldb/API/SBLock.h"
%include "lldb/API/SBMemoryRegionInfo.h"
%include "lldb/API/SBMemoryRegionInfoList.h"
%include "lldb/API/SBModule.h"
diff --git a/lldb/include/lldb/API/LLDB.h b/lldb/include/lldb/API/LLDB.h
index 126fcef31b416..47474d9ead1bf 100644
--- a/lldb/include/lldb/API/LLDB.h
+++ b/lldb/include/lldb/API/LLDB.h
@@ -46,6 +46,7 @@
#include "lldb/API/SBLaunchInfo.h"
#include "lldb/API/SBLineEntry.h"
#include "lldb/API/SBListener.h"
+#include "lldb/API/SBLock.h"
#include "lldb/API/SBMemoryRegionInfo.h"
#include "lldb/API/SBMemoryRegionInfoList.h"
#include "lldb/API/SBModule.h"
diff --git a/lldb/include/lldb/API/SBDefines.h
b/lldb/include/lldb/API/SBDefines.h
index ed5a80da117a5..7fa5150d69d8a 100644
--- a/lldb/include/lldb/API/SBDefines.h
+++ b/lldb/include/lldb/API/SBDefines.h
@@ -84,6 +84,7 @@ class LLDB_API SBLanguageRuntime;
class LLDB_API SBLaunchInfo;
class LLDB_API SBLineEntry;
class LLDB_API SBListener;
+class LLDB_API SBLock;
class LLDB_API SBMemoryRegionInfo;
class LLDB_API SBMemoryRegionInfoList;
class LLDB_API SBModule;
diff --git a/lldb/include/lldb/API/SBLock.h b/lldb/include/lldb/API/SBLock.h
new file mode 100644
index 0..93503d051edaa
--- /dev/null
+++ b/lldb/include/lldb/API/SBLock.h
@@ -0,0 +1,46 @@
+//===-- SBLock.h
--===//
+//
+// 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_SBLOCK_H
+#define LLDB_API_SBLOCK_H
+
+#include "lldb/API/SBDefines.h"
+#include "lldb/lldb-forward.h"
+#include
+
+namespace lldb_private {
+class APILock;
+}
+
+namespace lldb {
+
+class LLDB_API SBLock {
+public:
+ SBLock();
+ SBLock(SBLock &&rhs);
+ SBLock &operator=(SBLock &&rhs);
+ ~SBLock();
+
+ bool IsValid() const;
+
+ void Unlock() const;
+
+private:
+ // Private constructor used by SBTarget to create the Target API lock.
+ // Requires a friend declaration.
+ SBLock(lldb::TargetSP target_sp);
+ friend class SBTarget;
+
+ SBLock(const SBLock &rhs) = delete;
+ const SBLock &operato
[Lldb-commits] [lldb] [lldb][debugserver][MacOSX] Work around sanitizer misaligned address errors when reading exception data (PR #132193)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Michael Buch (Michael137)
Changes
We've been dealing with UBSAN issues around this code for some time now (see
`9c36859b33b386fbfa9599646de1e2ae01158180` and
`1a2122e9e9d1d495fdf337a4a9445b61ca56df6f`). On recent macOS versions, a
UBSAN-enabled debugserver will crash when performing a `memcpy` of the input
`mach_exception_data_t`. The pointer to the beginning of the exception data may
not be aligned on a doubleword boundary, leading to UBSAN failures such as:
```
$ ./bin/debugserver 0.0.0.0:
/Volumes/SSD/llvm-builds/llvm-worktrees/clang-work/build-sanitized-release/tools/lldb/test/Shell/Recognizer/Output/verbose_trap.test.tmp.out
/Volumes/SSD/llvm-builds/llvm-worktrees/clang-work/lldb/tools/debugserver/source/MacOSX/MachException.cpp:35:12:
runtime error: store to misaligned address 0x00016ddfa634 for type
'mach_exception_data_type_t *' (aka 'long long *'), which requires 8 byte
alignment
0x00016ddfa634: note: pointer points here
02 00 00 00 03 00 01 00 00 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00 08
00 00 00 00 00 00 00
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/Volumes/SSD/llvm-builds/llvm-worktrees/clang-work/lldb/tools/debugserver/source/MacOSX/MachException.cpp:35:12
```
Work around these failures by pretending the input data is a `char*` buffer.
Drive-by changes:
* I factored out some duplicated code into a static `AppendExceptionData` and
made the types consistent
---
Full diff: https://github.com/llvm/llvm-project/pull/132193.diff
2 Files Affected:
- (modified) lldb/tools/debugserver/source/MacOSX/MachException.cpp (+25-13)
- (modified) lldb/tools/debugserver/source/MacOSX/MachException.h (-9)
``diff
diff --git a/lldb/tools/debugserver/source/MacOSX/MachException.cpp
b/lldb/tools/debugserver/source/MacOSX/MachException.cpp
index 659fb2ff8186d..d05b47cd9b590 100644
--- a/lldb/tools/debugserver/source/MacOSX/MachException.cpp
+++ b/lldb/tools/debugserver/source/MacOSX/MachException.cpp
@@ -20,6 +20,23 @@
#include
#include
#include
+#include
+
+static void AppendExceptionData(
+std::vector &out,
+mach_exception_data_t Data, mach_msg_type_number_t Count) {
+ mach_exception_data_type_t Buf;
+ for (mach_msg_type_number_t i = 0; i < Count; ++i) {
+// The input Data we receive need not be aligned correctly.
+// Perform an unaligned copy by pretending we're dealing with
+// a char* buffer. This is required to work around UBSAN/ASAN
+// "misaligned address" errors.
+auto * src = reinterpret_cast(&Buf);
+auto * dst = reinterpret_cast(Data + i);
+memcpy(dst, src, sizeof(mach_exception_data_type_t));
+out.push_back(Buf);
+ }
+}
// Routine mach_exception_raise
extern "C" kern_return_t
@@ -95,20 +112,15 @@ catch_mach_exception_raise(mach_port_t exc_port,
mach_port_t thread_port,
mach_exception_data_t exc_data,
mach_msg_type_number_t exc_data_count) {
if (DNBLogCheckLogBit(LOG_EXCEPTIONS)) {
-std::vector exc_datas;
-uint64_t tmp;
-for (unsigned i = 0; i < exc_data_count; ++i) {
- // Perform an unaligned copy.
- memcpy(&tmp, &exc_data[i], sizeof(uint64_t));
- exc_datas.push_back(tmp);
-}
+std::vector exc_datas;
+AppendExceptionData(exc_datas, exc_data, exc_data_count);
DNBLogThreaded("::%s ( exc_port = 0x%4.4x, thd_port = 0x%4.4x, tsk_port = "
- "0x%4.4x, exc_type = %d ( %s ), exc_data[%d] = { 0x%llx, "
- "0x%llx })",
+ "0x%4.4x, exc_type = %d ( %s ), exc_data[%d] = { 0x%"
PRIx64 ", "
+ "0x%" PRIx64 " })",
__FUNCTION__, exc_port, thread_port, task_port, exc_type,
MachException::Name(exc_type), exc_data_count,
- (uint64_t)(exc_data_count > 0 ? exc_datas[0] : 0xBADDBADD),
- (uint64_t)(exc_data_count > 1 ? exc_datas[1] : 0xBADDBADD));
+ (exc_data_count > 0 ? exc_datas[0] : 0xBADDBADD),
+ (exc_data_count > 1 ? exc_datas[1] : 0xBADDBADD));
}
g_message->exc_type = 0;
g_message->exc_data.clear();
@@ -117,7 +129,7 @@ catch_mach_exception_raise(mach_port_t exc_port,
mach_port_t thread_port,
g_message->task_port = task_port;
g_message->thread_port = thread_port;
g_message->exc_type = exc_type;
-g_message->AppendExceptionData(exc_data, exc_data_count);
+AppendExceptionData(g_message->exc_data, exc_data, exc_data_count);
return KERN_SUCCESS;
} else if (!MachTask::IsValid(g_message->task_port)) {
// Our original exception port isn't valid anymore check for a SIGTRAP
@@ -129,7 +141,7 @@ catch_mach_exception_raise(mach_port_t exc_port,
mach_port_t thread_port,
g_message->task_port = task_port;
g_message->thread_port = thread_port;
g_message->exc_type = exc_type;
- g_message->AppendExce
[Lldb-commits] [lldb] [llvm] [lldb][lldb-dap] Implement jump to cursor (PR #130503)
@@ -113,6 +113,20 @@ class ExceptionInfoRequestHandler : public RequestHandler {
void operator()(const llvm::json::Object &request) const override;
};
+class GoToRequestHandler : public RequestHandler {
da-viper wrote:
There is an issue with the way to new protocol works, If you need to send and
event after a response. (currently needed for goto, next , stepIn , stepOut) .
It does not handle that case.
Instead you have to copy the implementation of `void operator()(const
protocol::Request &request)` from the `RequestHandler`
https://github.com/llvm/llvm-project/pull/130503
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver][MacOSX] Work around sanitizer misaligned address errors when reading exception data (PR #132193)
https://github.com/Michael137 ready_for_review https://github.com/llvm/llvm-project/pull/132193 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose the Target API lock through the SB API (PR #131404)
@@ -0,0 +1,11 @@
+%extend lldb::SBLock {
+#ifdef SWIGPYTHON
+%pythoncode %{
+def __enter__(self):
+return self
+
+def __exit__(self, exc_type, exc_value, traceback):
+self.Unlock()
JDevlieghere wrote:
What I can make work is this:
```
lock = target.AcquireLock();
[...]
lock.Unlock()
with lock:
# we are correctly locked here
with lock:
# we are correctly locked here
```
https://github.com/llvm/llvm-project/pull/131404
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
