[Lldb-commits] [lldb] 2f5c836 - [SBProgress] Add swig support for `with` statement in Python (#133527)
Author: Jacob Lalonde
Date: 2025-03-29T15:21:51-07:00
New Revision: 2f5c836e08164ce8835d520001042efe93caf950
URL:
https://github.com/llvm/llvm-project/commit/2f5c836e08164ce8835d520001042efe93caf950
DIFF:
https://github.com/llvm/llvm-project/commit/2f5c836e08164ce8835d520001042efe93caf950.diff
LOG: [SBProgress] Add swig support for `with` statement in Python (#133527)
We recently added an explicit finalize to SBProgress, #128966. I
realized while adding some additional implementations of SBProgress that
we should to add `with` support for ease of use. This patch addresses
adding and `__enter()__` method (which a no-op) and an `__exit()__` to
swig. I also refactor the emitter for the test to leverage `with`
instead of explicitly calling finalize, and I've updated the docstrings.
Added:
lldb/bindings/interface/SBProgressExtensions.i
Modified:
lldb/bindings/interface/SBProgressDocstrings.i
lldb/bindings/interfaces.swig
lldb/test/API/tools/lldb-dap/progress/Progress_emitter.py
Removed:
diff --git a/lldb/bindings/interface/SBProgressDocstrings.i
b/lldb/bindings/interface/SBProgressDocstrings.i
index 8d252ef1f370c..4c001d7d5ebcb 100644
--- a/lldb/bindings/interface/SBProgressDocstrings.i
+++ b/lldb/bindings/interface/SBProgressDocstrings.i
@@ -46,12 +46,19 @@ rely on the garbage collection when using lldb.SBProgress.
Non-deterministic progresses behave the same, but omit the total in the
constructor. ::
-non_deterministic_progress = lldb.SBProgress('Non deterministic progress,
'Detail', lldb.SBDebugger)
+non_deterministic_progress = lldb.SBProgress('Non deterministic progress',
'Detail', lldb.SBDebugger)
for i in range(10):
non_deterministic_progress.Increment(1)
# Explicitly send a progressEnd, otherwise this will be sent
# when the python runtime cleans up this object.
non_deterministic_progress.Finalize()
+
+Additionally for Python, progress is supported in a with statement. ::
+with lldb.SBProgress('Non deterministic progress', 'Detail',
lldb.SBDebugger) as progress:
+for i in range(10):
+progress.Increment(1)
+# The progress object is automatically finalized when the with statement
+
") lldb::SBProgress;
%feature("docstring",
diff --git a/lldb/bindings/interface/SBProgressExtensions.i
b/lldb/bindings/interface/SBProgressExtensions.i
new file mode 100644
index 0..6ecf3a1af93b7
--- /dev/null
+++ b/lldb/bindings/interface/SBProgressExtensions.i
@@ -0,0 +1,13 @@
+%extend lldb::SBProgress {
+#ifdef SWIGPYTHON
+%pythoncode %{
+def __enter__(self):
+'''No-op for with statement'''
+pass
+
+def __exit__(self, exc_type, exc_value, traceback):
+'''Finalize the progress object'''
+self.Finalize()
+%}
+#endif
+}
\ No newline at end of file
diff --git a/lldb/bindings/interfaces.swig b/lldb/bindings/interfaces.swig
index 08df9a1a8d539..6da56e4e0fa52 100644
--- a/lldb/bindings/interfaces.swig
+++ b/lldb/bindings/interfaces.swig
@@ -200,6 +200,7 @@
%include "./interface/SBModuleSpecExtensions.i"
%include "./interface/SBModuleSpecListExtensions.i"
%include "./interface/SBProcessExtensions.i"
+%include "./interface/SBProgressExtensions.i"
%include "./interface/SBProcessInfoListExtensions.i"
%include "./interface/SBQueueItemExtensions.i"
%include "./interface/SBScriptObjectExtensions.i"
diff --git a/lldb/test/API/tools/lldb-dap/progress/Progress_emitter.py
b/lldb/test/API/tools/lldb-dap/progress/Progress_emitter.py
index e94a09676e067..445d1bdf4e496 100644
--- a/lldb/test/API/tools/lldb-dap/progress/Progress_emitter.py
+++ b/lldb/test/API/tools/lldb-dap/progress/Progress_emitter.py
@@ -88,21 +88,18 @@ def __call__(self, debugger, command, exe_ctx, result):
progress = lldb.SBProgress(
"Progress tester", "Initial Detail", total, debugger
)
-
# Check to see if total is set to None to indicate an indeterminate
progress
# then default to 10 steps.
-if total is None:
-total = 10
-
-for i in range(1, total):
-if cmd_options.no_details:
-progress.Increment(1)
-else:
-progress.Increment(1, f"Step {i}")
-time.sleep(cmd_options.seconds)
-
-# Not required for deterministic progress, but required for
indeterminate progress.
-progress.Finalize()
+with progress:
+if total is None:
+total = 10
+
+for i in range(1, total):
+if cmd_options.no_details:
+progress.Increment(1)
+else:
+progress.Increment(1, f"Step {i}")
+time.sleep(cmd_options.seconds)
def __lldb_init_module(debugger, dict):
[Lldb-commits] [lldb] [lldb] Combine disassembler gtest binaries for efficiency (PR #133539)
https://github.com/bulbazord approved this pull request. One minor suggestion. Otherwise lgtm https://github.com/llvm/llvm-project/pull/133539 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Addressing ubsan enum usage. (PR #133542)
ashgti wrote: Sure I’ll convert it to that in a follow up patch https://github.com/llvm/llvm-project/pull/133542 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement CLI support for reverse-continue (PR #132783)
https://github.com/vogelsgesang edited https://github.com/llvm/llvm-project/pull/132783 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement CLI support for reverse-continue (PR #132783)
@@ -468,7 +468,23 @@ class CommandObjectProcessContinue : public
CommandObjectParsed {
case 'b':
m_run_to_bkpt_args.AppendArgument(option_arg);
m_any_bkpts_specified = true;
- break;
+break;
+ case 'F':
+if (m_base_direction == lldb::RunDirection::eRunReverse) {
+ error = Status::FromErrorString(
+ "cannot specify both 'forward' and 'reverse'");
+ break;
+}
+m_base_direction = lldb::RunDirection::eRunForward;
+break;
+ case 'R':
+if (m_base_direction == lldb::RunDirection::eRunForward) {
+ error = Status::FromErrorString(
+ "cannot specify both 'forward' and 'reverse'");
vogelsgesang wrote:
We might want to add a test case for this error condition?
https://github.com/llvm/llvm-project/pull/132783
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement CLI support for reverse-continue (PR #132783)
vogelsgesang wrote: We probably also want to test that * reverse-continue on a non-reverse-capable process gives a decent error message * `process continue -F` also work for non-reverse-capable processes https://github.com/llvm/llvm-project/pull/132783 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [SBProgress] Add swig support for `with` statement in Python (PR #133527)
https://github.com/Jlalond closed https://github.com/llvm/llvm-project/pull/133527 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement CLI support for reverse-continue (PR #132783)
vogelsgesang wrote: > I suppose we need to add documentation for this but I'm not sure where... Afaict, your code change should already be sufficient such that `help processor continue` also lists the new -F and -R flags. In addition, I guess we would eventually want to also document more generally how to use rr with lldb (how to start the rr replay, how to connect lldb to it, etc.) such that end users are able to discover this feature. However, I guess before doing so, we would like to also implement reverse single- stepping etc.? https://github.com/llvm/llvm-project/pull/132783 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Refactoring lldb-dap 'launch' request to use typed RequestHandler<>. (PR #133624)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: John Harrison (ashgti)
Changes
This converts a number of json::Value's into well defined types that are used
throughout lldb-dap and updates the 'launch' command to use the new well
defined types.
---
Patch is 68.84 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm-project/pull/133624.diff
22 Files Affected:
- (modified) lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
(+2-1)
- (modified)
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py (+1-1)
- (modified) lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py (+4-2)
- (modified)
lldb/test/API/tools/lldb-dap/restart/TestDAP_restart_runInTerminal.py (+2-2)
- (modified)
lldb/test/API/tools/lldb-dap/runInTerminal/TestDAP_runInTerminal.py (+8-8)
- (modified) lldb/tools/lldb-dap/DAP.cpp (+54-28)
- (modified) lldb/tools/lldb-dap/DAP.h (+24-20)
- (modified) lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp (+19-14)
- (modified) lldb/tools/lldb-dap/Handler/CompletionsHandler.cpp (+4-3)
- (modified) lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp (+2-1)
- (modified) lldb/tools/lldb-dap/Handler/LaunchRequestHandler.cpp (+29-89)
- (modified) lldb/tools/lldb-dap/Handler/RequestHandler.cpp (+51-45)
- (modified) lldb/tools/lldb-dap/Handler/RequestHandler.h (+15-4)
- (modified) lldb/tools/lldb-dap/Handler/RestartRequestHandler.cpp (+40-14)
- (modified) lldb/tools/lldb-dap/Handler/SetVariableRequestHandler.cpp (+2-1)
- (modified) lldb/tools/lldb-dap/Handler/StackTraceRequestHandler.cpp (+1-1)
- (modified) lldb/tools/lldb-dap/Handler/VariablesRequestHandler.cpp (+10-10)
- (modified) lldb/tools/lldb-dap/JSONUtils.cpp (+20-28)
- (modified) lldb/tools/lldb-dap/JSONUtils.h (+6-5)
- (modified) lldb/tools/lldb-dap/Protocol/ProtocolRequests.cpp (+169-6)
- (modified) lldb/tools/lldb-dap/Protocol/ProtocolRequests.h (+150)
- (modified) lldb/tools/lldb-dap/SourceBreakpoint.cpp (+3-3)
``diff
diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index 01ef4b68f2653..6e13fcddcc933 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -862,7 +862,8 @@ def request_launch(
args_dict["enableAutoVariableSummaries"] = enableAutoVariableSummaries
args_dict["enableSyntheticChildDebugging"] =
enableSyntheticChildDebugging
args_dict["displayExtendedBacktrace"] = displayExtendedBacktrace
-args_dict["commandEscapePrefix"] = commandEscapePrefix
+if commandEscapePrefix:
+args_dict["commandEscapePrefix"] = commandEscapePrefix
command_dict = {"command": "launch", "type": "request", "arguments":
args_dict}
response = self.send_recv(command_dict)
diff --git
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index 70b04b051e0ec..9ab8a905a79dd 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -443,7 +443,7 @@ def cleanup():
if not (response and response["success"]):
self.assertTrue(
-response["success"], "launch failed (%s)" %
(response["message"])
+response["success"], "launch failed (%s)" %
(response["body"]["error"]["format"])
)
return response
diff --git a/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
b/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
index 64c99019a1c9b..c6a3e9cc879a4 100644
--- a/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
+++ b/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
@@ -41,7 +41,9 @@ def test_termination(self):
self.dap_server.request_disconnect()
# Wait until the underlying lldb-dap process dies.
-
self.dap_server.process.wait(timeout=lldbdap_testcase.DAPTestCaseBase.timeoutval)
+self.dap_server.process.wait(
+timeout=lldbdap_testcase.DAPTestCaseBase.timeoutval
+)
# Check the return code
self.assertEqual(self.dap_server.process.poll(), 0)
@@ -459,7 +461,7 @@ def test_failing_launch_commands(self):
self.assertFalse(response["success"])
self.assertRegex(
-response["message"],
+response["body"]["error"]["format"],
r"Failed to run launch commands\. See the Debug Console for more
details",
)
diff --git
a/lldb/test/API/tools/lldb-dap/restart/TestDAP_restart_runInTerminal.py
b/lldb/test/API/tools/lldb-dap/restart/TestDAP_restart_runInTerminal.py
index 5a9938c25c2c8..a94c9860c1508 100644
--- a/lldb/test/API/tools/lldb-dap/restart/TestDAP_restart_runInTerminal.py
+++ b/lldb/test/API/to
[Lldb-commits] [clang] [clang-tools-extra] [lldb] Reland: [clang] preserve class type sugar when taking pointer to member (PR #132401)
mizvekov wrote: @alexfh should be fixed by https://github.com/llvm/llvm-project/pull/133613 https://github.com/llvm/llvm-project/pull/132401 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Swapping to not use FLAG_ENUM and just defining typed enums. (PR #133622)
https://github.com/ashgti created
https://github.com/llvm/llvm-project/pull/133622
Small tweak to the previous patch to make the enums in `lldb_dap::protocol`
typed to work with types like `llvm::DenseSet` found by ubsan.
>From b7ecaef75b0e059b11761eea4a640e6a68f3d2d6 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Sat, 29 Mar 2025 22:30:58 -0700
Subject: [PATCH] [lldb-dap] Swapping to not use FLAG_ENUM and just defining
typed enums.
Small tweak to the previous patch to make the enums in `lldb_dap::protocol`
typed to work with types like `llvm::DenseSet` found by ubsan.
---
lldb/tools/lldb-dap/Protocol/ProtocolBase.cpp | 8 +-
lldb/tools/lldb-dap/Protocol/ProtocolBase.h | 11 +-
.../lldb-dap/Protocol/ProtocolRequests.h | 35 ++-
lldb/tools/lldb-dap/Protocol/ProtocolTypes.h | 235 +-
4 files changed, 148 insertions(+), 141 deletions(-)
diff --git a/lldb/tools/lldb-dap/Protocol/ProtocolBase.cpp
b/lldb/tools/lldb-dap/Protocol/ProtocolBase.cpp
index 0d63e37d3eafb..87fd0df018b65 100644
--- a/lldb/tools/lldb-dap/Protocol/ProtocolBase.cpp
+++ b/lldb/tools/lldb-dap/Protocol/ProtocolBase.cpp
@@ -7,7 +7,6 @@
//===--===//
#include "Protocol/ProtocolBase.h"
-#include "lldb/lldb-enumerations.h"
#include "llvm/ADT/StringRef.h"
#include "llvm/ADT/StringSwitch.h"
#include "llvm/Support/ErrorHandling.h"
@@ -32,8 +31,11 @@ static bool mapRaw(const json::Value &Params, StringLiteral
Prop,
namespace lldb_dap::protocol {
-FLAGS_ENUM(MessageType){eMessageTypeRequest, eMessageTypeResponse,
-eMessageTypeEvent};
+enum MessageType : unsigned {
+ eMessageTypeRequest,
+ eMessageTypeResponse,
+ eMessageTypeEvent
+};
bool fromJSON(const json::Value &Params, MessageType &M, json::Path P) {
auto rawType = Params.getAsString();
diff --git a/lldb/tools/lldb-dap/Protocol/ProtocolBase.h
b/lldb/tools/lldb-dap/Protocol/ProtocolBase.h
index 5ac68e38cb9c4..2c647610de11c 100644
--- a/lldb/tools/lldb-dap/Protocol/ProtocolBase.h
+++ b/lldb/tools/lldb-dap/Protocol/ProtocolBase.h
@@ -20,7 +20,6 @@
#ifndef LLDB_TOOLS_LLDB_DAP_PROTOCOL_H
#define LLDB_TOOLS_LLDB_DAP_PROTOCOL_H
-#include "lldb/lldb-enumerations.h"
#include "llvm/Support/JSON.h"
#include
#include
@@ -65,11 +64,11 @@ struct Event {
llvm::json::Value toJSON(const Event &);
bool fromJSON(const llvm::json::Value &, Event &, llvm::json::Path);
-FLAGS_ENUM(ResponseMessage){
-/// The request was cancelled
-eResponseMessageCancelled,
-/// The request may be retried once the adapter is in a 'stopped' state
-eResponseMessageNotStopped,
+enum ResponseMessage : unsigned {
+ /// The request was cancelled
+ eResponseMessageCancelled,
+ /// The request may be retried once the adapter is in a 'stopped' state
+ eResponseMessageNotStopped,
};
/// Response for a request.
diff --git a/lldb/tools/lldb-dap/Protocol/ProtocolRequests.h
b/lldb/tools/lldb-dap/Protocol/ProtocolRequests.h
index 116cf8516c52e..927106997953a 100644
--- a/lldb/tools/lldb-dap/Protocol/ProtocolRequests.h
+++ b/lldb/tools/lldb-dap/Protocol/ProtocolRequests.h
@@ -22,7 +22,6 @@
#include "Protocol/ProtocolBase.h"
#include "Protocol/ProtocolTypes.h"
-#include "lldb/lldb-enumerations.h"
#include "llvm/ADT/DenseSet.h"
#include "llvm/Support/JSON.h"
#include
@@ -57,26 +56,26 @@ bool fromJSON(const llvm::json::Value &,
DisconnectArguments &,
using DisconnectResponse = VoidResponse;
/// Features supported by DAP clients.
-FLAGS_ENUM(ClientFeature){
-eClientFeatureVariableType,
-eClientFeatureVariablePaging,
-eClientFeatureRunInTerminalRequest,
-eClientFeatureMemoryReferences,
-eClientFeatureProgressReporting,
-eClientFeatureInvalidatedEvent,
-eClientFeatureMemoryEvent,
-/// Client supports the `argsCanBeInterpretedByShell` attribute on the
-/// `runInTerminal` request.
-eClientFeatureArgsCanBeInterpretedByShell,
-eClientFeatureStartDebuggingRequest,
-/// The client will interpret ANSI escape sequences in the display of
-/// `OutputEvent.output` and `Variable.value` fields when
-/// `Capabilities.supportsANSIStyling` is also enabled.
-eClientFeatureANSIStyling,
+enum ClientFeature : unsigned {
+ eClientFeatureVariableType,
+ eClientFeatureVariablePaging,
+ eClientFeatureRunInTerminalRequest,
+ eClientFeatureMemoryReferences,
+ eClientFeatureProgressReporting,
+ eClientFeatureInvalidatedEvent,
+ eClientFeatureMemoryEvent,
+ /// Client supports the `argsCanBeInterpretedByShell` attribute on the
+ /// `runInTerminal` request.
+ eClientFeatureArgsCanBeInterpretedByShell,
+ eClientFeatureStartDebuggingRequest,
+ /// The client will interpret ANSI escape sequences in the display of
+ /// `OutputEvent.output` and `Variable.value` fields when
+ /// `Capabilities.supportsANSIStyling` is also enabled.
+ eClientFeatureANSIStyling,
};
/// Format of paths reported by the debug
[Lldb-commits] [lldb] [lldb] Implement CLI support for reverse-continue (PR #132783)
@@ -744,6 +744,10 @@ let Command = "process continue" in {
Arg<"BreakpointIDRange">, Desc<"Specify a breakpoint to continue to,
temporarily "
"ignoring other breakpoints. Can be specified more than once. "
"The continue action will be done synchronously if this option is
specified.">;
+ def thread_continue_forward : Option<"forward", "F">, Group<3>,
+Desc<"Execute in forward direction">;
+ def thread_continue_reverse : Option<"reverse", "R">, Group<3>,
+Desc<"Execute in forward direction">;
vogelsgesang wrote:
s/forward/reverse
https://github.com/llvm/llvm-project/pull/132783
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [SBProgress] Add swig support for `with` statement in Python (PR #133527)
https://github.com/JDevlieghere approved this pull request. Nice improvement! Not sure how hard it would be to extend this even more, but Python's [rich](https://rich.readthedocs.io/en/stable/progress.html) package has a progress bar that allows you to write: ``` for i in track(range(20), description="Processing..."): time.sleep(1) # Simulate work being done ``` It would be cool if we could add an extension so you could write the same thing with LLDB's progress: ``` for i in lldb.Progress.track(range(20), description="Processing..."): time.sleep(1) # Simulate work being done ``` https://github.com/llvm/llvm-project/pull/133527 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [SBProgress] Add swig support for `with` statement in Python (PR #133527)
JDevlieghere wrote:
> Neat! While I don't love the reverse video, is there an easier way to update
> the status line color other than setting the entire format like so?
>
> ```
> settings set statusline-format "${ansi.bg.blue}{${target.file.basename}}{ |
> ${line.file.basename}:${line.number}:${line.column}}{ |
> ${thread.stop-reason}}{ | {${progress.count} }${progress.message}}"
> ```
>
> If not, I'd love to contribute to make this a bit easier to update the color.
> Otherwise it's really neat!
Yup, that's the way to do it. I agree that the reverse video doesn't look
"great", but it's the only thing that is guaranteed to look "alright" with any
color scheme. I played around with the colors and there's always one color
scheme where a combination of colors looks horrible.
As to ways to make it easier to configure this, we generally have two ways to
do this:
1. Using a prefix/suffix setting for things that don't take format strings. For
example `show-progress-ansi-prefix` (now deprecated),
`show-autosuggestion-ansi-prefix`, etc. The primary downside of that approach
is that you have two settings.
2. Using a format strings so you can change the color of its components. For
example `frame-format`, `thread-format`, etc. That's the approach I went with
here as it follows the existing pattern, but it also allows you to have a
different background color for things like the target, the stop reason, etc.
Very similar to the `vim` statusline (and often folks do the same with tmux).
What I was thinking is that maybe we could extend LLDB to have the notion of
"themes". That would allow you to tweak the colors without changing any of the
individual settings. Plus, it would ensure that colors remain consistent: if
two things were originally one color, they'd both be the new color, rather than
having you to go through all the settings and finding other instances of things
being that color.
https://github.com/llvm/llvm-project/pull/133527
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Addressing ubsan enum usage. (PR #133542)
https://github.com/JDevlieghere commented: I think using `FLAGS_ENUM` here is misleading: these are not flags which you can mask. Could we instead just add a type like `enum Message: unsinged` or `enum Message: uint64_t` to make UBSan happy? https://github.com/llvm/llvm-project/pull/133542 ___ 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 closed https://github.com/llvm/llvm-project/pull/132043 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Combine disassembler gtest binaries for efficiency (PR #133539)
https://github.com/JDevlieghere approved this pull request. LGTM with Alex' suggestion. https://github.com/llvm/llvm-project/pull/133539 ___ 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,142 @@
+//===-- 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 "JSONUtils.h"
+#include "RequestHandler.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;
+ 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("");
+
+ lldb::SBError writeError;
+ uint64_t bytes_written = 0;
+
+ std::string output = llvm::encodeBase64(data64);
santhoshe447 wrote:
oh, I will check this,
https://github.com/llvm/llvm-project/pull/131820
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [SBProgress] Add swig support for `with` statement in Python (PR #133527)
Jlalond wrote:
> > Neat! While I don't love the reverse video, is there an easier way to
> > update the status line color other than setting the entire format like so?
> > ```
> > settings set statusline-format "${ansi.bg.blue}{${target.file.basename}}{ |
> > ${line.file.basename}:${line.number}:${line.column}}{ |
> > ${thread.stop-reason}}{ | {${progress.count} }${progress.message}}"
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > If not, I'd love to contribute to make this a bit easier to update the
> > color. Otherwise it's really neat!
>
> Yup, that's the way to do it. I agree that the reverse video doesn't look
> "great", but it's the only thing that is guaranteed to look "alright" with
> any color scheme. I played around with the colors and there's always one
> color scheme where a combination of colors looks horrible.
>
> As to ways to make it easier to configure this, we generally have two ways to
> do this:
>
> 1. Using a prefix/suffix setting for things that don't take format strings.
> For example `show-progress-ansi-prefix` (now deprecated),
> `show-autosuggestion-ansi-prefix`, etc. The primary downside of that approach
> is that you have two settings.
> 2. Using a format strings so you can change the color of its components. For
> example `frame-format`, `thread-format`, etc. That's the approach I went with
> here as it follows the existing pattern, but it also allows you to have a
> different background color for things like the target, the stop reason, etc.
> Very similar to the `vim` statusline (and often folks do the same with tmux).
>
> What I was thinking is that maybe we could extend LLDB to have the notion of
> "themes". That would allow you to tweak the colors without changing any of
> the individual settings. Plus, it would ensure that colors remain consistent:
> if two things were originally one color, they'd both be the new color, rather
> than having you to go through all the settings and finding other instances of
> things being that color.
An alternative to making it a setting it just make it exposed through the SB
API as structured data, and then we can programmatically update the prefix (or
expose a command to do so). I'll comment on your RFC.
https://github.com/llvm/llvm-project/pull/133527
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [SBProgress] Add swig support for `with` statement in Python (PR #133527)
Jlalond wrote: > Nice improvement! > > Not sure how hard it would be to extend this even more, but Python's > [rich](https://rich.readthedocs.io/en/stable/progress.html) package has a > progress bar that allows you to write: > > ``` > for i in track(range(20), description="Processing..."): > time.sleep(1) # Simulate work being done > ``` > > It would be cool if we could add an extension so you could write the same > thing with LLDB's progress: > > ``` > for i in lldb.Progress.track(range(20), description="Processing..."): > time.sleep(1) # Simulate work being done > ``` @aperez Thoughts on this? I think this could be useful https://github.com/llvm/llvm-project/pull/133527 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
