https://github.com/clayborg requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/108309
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1132,6 +1138,8 @@ Status MinidumpFileBuilder::AddMemoryList_64(
error = AddData(data_up->GetBytes(), bytes_read);
if (error.Fail())
return error;
+
+progress.Increment();
clayborg wrote:
Ditto, move before the memory read and add descript
jeffreytan81 wrote:
Also, I want to point out that, in this specific example, IRInterpreter will
try to interpret the "(bool)true" expression so it won't run the thread plan
with `TryAllThreads = true`, but I assume you are commenting the danger in a
general sense.
https://github.com/llvm/ll
https://github.com/cmtice updated
https://github.com/llvm/llvm-project/pull/107485
>From 15541f354decf80586d590db9f9cb353be04b122 Mon Sep 17 00:00:00 2001
From: Caroline Tice
Date: Thu, 5 Sep 2024 15:51:35 -0700
Subject: [PATCH 1/5] [lldb-dap] Add feature to remember last non-empty
expression.
@@ -1364,8 +1364,20 @@ void request_evaluate(const llvm::json::Object &request)
{
std::string expression = GetString(arguments, "expression").str();
llvm::StringRef context = GetString(arguments, "context");
- if (context == "repl" && g_dap.DetectExpressionContext(frame,
@@ -686,16 +692,10 @@ Status MinidumpFileBuilder::AddExceptions() {
for (const ThreadSP &thread_sp : thread_list) {
StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
bool add_exception = false;
-if (stop_info_sp) {
- switch (stop_info_sp->GetStopReason()) {
jimingham wrote:
You are right, TryAllThreads defaults to True.
Not using TryAllThreads is actually dangerous in the general case. For
instance, you can have the thread you run take a lock, then call some code that
tries another lock that is held by a thread we aren't running. That times o
https://github.com/jeffreytan81 updated
https://github.com/llvm/llvm-project/pull/108414
>From 6e84ab9a14e63c58e1facdbf9a695c093882b37b Mon Sep 17 00:00:00 2001
From: jeffreytan81
Date: Mon, 19 Aug 2024 10:57:35 -0700
Subject: [PATCH 1/4] Fix StartDebuggingRequestHandler/ReplModeRequestHandler
jeffreytan81 wrote:
It's funny that there is already an `ValueObject::CreateValueObjectFromBool()`
function :-)
https://github.com/llvm/llvm-project/pull/108414
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
jimingham wrote:
BTW, I agree that the "run one thread, then run all threads" strategy is
unfortunate. But I can't think of a better way to do that that's likely to be
supported on all platforms. It might be good at some point to add a "Lock
detection plugin" that could provide enough inform
jeffreytan81 wrote:
> You are right, TryAllThreads defaults to True.
>
> Not using TryAllThreads is actually dangerous in the general case. For
> instance, you can have the thread you run take a lock, then call some code
> that tries another lock that is held by a thread we aren't running. Tha
jimingham wrote:
> It's funny that there is already a `ValueObject::CreateValueObjectFromBool()`
> function :-)
The very thing I was worried about!
Might be a good idea to put the general "don't do substantial implementations
in SB API" principle in the "SBI API" doc page. I did a quick scan
jimingham wrote:
> > You are right, TryAllThreads defaults to True.
> > Not using TryAllThreads is actually dangerous in the general case. For
> > instance, you can have the thread you run take a lock, then call some code
> > that tries another lock that is held by a thread we aren't running. T
@@ -645,6 +645,23 @@ lldb::SBValue SBValue::CreateValueFromData(const char
*name, SBData data,
return sb_value;
}
+lldb::SBValue SBValue::CreateBoolValue(const char *name, bool value) {
+ LLDB_INSTRUMENT_VA(this, name);
+
+ lldb::SBValue sb_value;
+ lldb::ValueObjectSP n
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/108259
>From 022173d669e84c96362024feb6512342fdd02d09 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Wed, 11 Sep 2024 10:27:31 -0700
Subject: [PATCH 1/6] Unlink file on failure
---
.../ObjectFile/Minidump/Minidum
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r
c2b93e0671d8cfd6b1a24c6e1d7be290125b8974...33b647410bacca3e429d1021b8c8ef9ea14ddbe6
lldb
https://github.com/jimingham created
https://github.com/llvm/llvm-project/pull/108462
None
>From f1b503559d9c488b3f2354b836fe5031548b7903 Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Thu, 12 Sep 2024 15:25:19 -0700
Subject: [PATCH] Add a comment in the SB API doc about keeping the SB API's
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: None (jimingham)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/108462.diff
1 Files Affected:
- (modified) lldb/docs/resources/sbapi.rst (+11)
``diff
diff --git a/lldb/docs/resources/sbapi.rst b/lldb/docs/re
jimingham wrote:
> > It's funny that there is already a
> > `ValueObject::CreateValueObjectFromBool()` function :-)
>
> The very thing I was worried about!
>
> Might be a good idea to put the general "don't do substantial implementations
> in SB API" principle in the "SBI API" doc page. I did
@@ -175,9 +175,10 @@
"type": "array",
"description": "Additional environment variables to set
when launching the program. E.g. `[\"FOO=1\", \"BAR\"]`",
"items": {
- "type": "string"
+
https://github.com/Da-Viper updated
https://github.com/llvm/llvm-project/pull/106919
>From d2bddca1753b4c960895f51d7eb80b6efa7dc986 Mon Sep 17 00:00:00 2001
From: Ezike Ebuka
Date: Sun, 1 Sep 2024 17:26:11 +0100
Subject: [PATCH 1/8] [lldb-dap] Make environment option an object
---
.../tools/l
AbdAlRahmanGad wrote:
As a new contributor, I don't have an opinion on this, but I'm more than happy
to help out with additional tasks whenever needed.
https://github.com/llvm/llvm-project/pull/106831
___
lldb-commits mailing list
lldb-commits@lists.l
jimingham wrote:
This is more an architectural issue. Right now, we're always handing out
ValueObjectSP's which means there are two ways of indicating failure, having an
empty ValueObjectSP, and having a ValueObjectSP that has a ValueObject in it,
but it's Error state is set. That's pretty a
AbdAlRahmanGad wrote:
Could you please recommend something to me? If you don't have something
specific in mind right now, should I look it up and then ask if it is suitable
to work on before I begin?
https://github.com/llvm/llvm-project/pull/106831
_
jimingham wrote:
> Could you please recommend something to me? If you don't have something
> specific in mind right now, should I look it up and then ask if it is
> suitable to work on before I begin?
The conversion of error handling behaviors was Adrian's project, I haven't
thought about it
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/108309
>From e7054832dc6e54d4b9f3ce86a8babd1f62cac81a Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Wed, 11 Sep 2024 13:33:44 -0700
Subject: [PATCH 1/4] Add Progress bar to minidump memory emission
---
.../Minid
@@ -645,6 +645,23 @@ lldb::SBValue SBValue::CreateValueFromData(const char
*name, SBData data,
return sb_value;
}
+lldb::SBValue SBValue::CreateBoolValue(const char *name, bool value) {
+ LLDB_INSTRUMENT_VA(this, name);
+
+ lldb::SBValue sb_value;
+ lldb::ValueObjectSP n
https://github.com/jeffreytan81 updated
https://github.com/llvm/llvm-project/pull/108414
>From 6e84ab9a14e63c58e1facdbf9a695c093882b37b Mon Sep 17 00:00:00 2001
From: jeffreytan81
Date: Mon, 19 Aug 2024 10:57:35 -0700
Subject: [PATCH 1/5] Fix StartDebuggingRequestHandler/ReplModeRequestHandler
https://github.com/jeffreytan81 approved this pull request.
Now I wish we can feed this kind of information to AI and let AI code review
and catch it :-)
https://github.com/llvm/llvm-project/pull/108462
___
lldb-commits mailing list
lldb-commits@list
https://github.com/medismailben approved this pull request.
https://github.com/llvm/llvm-project/pull/108462
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/108259
>From 022173d669e84c96362024feb6512342fdd02d09 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Wed, 11 Sep 2024 10:27:31 -0700
Subject: [PATCH 1/7] Unlink file on failure
---
.../ObjectFile/Minidump/Minidum
https://github.com/JDevlieghere created
https://github.com/llvm/llvm-project/pull/108495
Add an "always on" log category and channel. Unlike other, existing log
channels, it is not exposed to users. The channel is meant to be used sparsely
and deliberately for logging high-value information to
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jonas Devlieghere (JDevlieghere)
Changes
Add an "always on" log category and channel. Unlike other, existing log
channels, it is not exposed to users. The channel is meant to be used sparsely
and deliberately for logging high-value informa
@@ -49,6 +49,7 @@ enum class LLDBLog : Log::MaskType {
Watchpoints = Log::ChannelFlag<30>,
OnDemand = Log::ChannelFlag<31>,
Source = Log::ChannelFlag<32>,
+ AlwaysOn = Log::ChannelFlag<32>,
jasonmolenda wrote:
does this number need to be unique?
https:
https://github.com/JDevlieghere created
https://github.com/llvm/llvm-project/pull/108498
Emit signpost intervals for progress events so that when users report an
operation takes a long time, we can see investigate the issue with Instruments.
>From 60096062924d8364e953d8479dcbd4b7ea2faaff Mon S
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jonas Devlieghere (JDevlieghere)
Changes
Emit signpost intervals for progress events so that when users report an
operation takes a long time, we can see investigate the issue with Instruments.
---
Full diff: https://github.com/llvm/llvm-p
@@ -49,6 +49,7 @@ enum class LLDBLog : Log::MaskType {
Watchpoints = Log::ChannelFlag<30>,
OnDemand = Log::ChannelFlag<31>,
Source = Log::ChannelFlag<32>,
+ AlwaysOn = Log::ChannelFlag<32>,
JDevlieghere wrote:
Yes, definitely. But this code shouldn't ha
https://github.com/JDevlieghere updated
https://github.com/llvm/llvm-project/pull/108495
>From 734088d8ec84d32304b4f78743999fd561fd4fe3 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere
Date: Thu, 12 Sep 2024 22:29:46 -0700
Subject: [PATCH] [lldb] Introduce an always-on system log category/chann
https://github.com/JDevlieghere updated
https://github.com/llvm/llvm-project/pull/108498
>From d15881207001934ff83934fae9cdeb52f61eaf6f Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere
Date: Thu, 12 Sep 2024 22:43:40 -0700
Subject: [PATCH] [lldb] Emit signpost intervals for progress events (NFC
Author: Jonas Devlieghere
Date: 2024-09-12T22:52:58-07:00
New Revision: 8f653ca135cb8d4f8d08b97cc32a497091f68cdc
URL:
https://github.com/llvm/llvm-project/commit/8f653ca135cb8d4f8d08b97cc32a497091f68cdc
DIFF:
https://github.com/llvm/llvm-project/commit/8f653ca135cb8d4f8d08b97cc32a497091f68cdc.d
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/108504
lldb-server built with NativeProcessLinux.cpp and NativeProcessFreeBSD.cpp can
use breakpoints to implement instruction stepping on cores where there is no
native instruction-step primitive. Currently the
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jason Molenda (jasonmolenda)
Changes
lldb-server built with NativeProcessLinux.cpp and NativeProcessFreeBSD.cpp can
use breakpoints to implement instruction stepping on cores where there is no
native instruction-step primitive. Currently
jasonmolenda wrote:
This is addressing the discussion about the CI failures (and David's repoing of
them) from when I tried to land https://github.com/llvm/llvm-project/pull/96260
.
I had this as a commit for the PR where I'm addressing the CI fails so I can
re-land ( https://github.com/llv
101 - 143 of 143 matches
Mail list logo
