devnexen wrote:
ping :)
https://github.com/llvm/llvm-project/pull/79662
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/chelcassanova updated
https://github.com/llvm/llvm-project/pull/81319
>From f5ef07849c61ee9387f92376d5e1bd13bedc43e5 Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Thu, 8 Feb 2024 15:31:33 -0800
Subject: [PATCH] [lldb][progress] Add progress manager class
Per discuss
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
clayborg wrote:
I am fine with telling people what to do and giving them a golden path to what
is easiest for our debuggers. And I will suggest to everyone that they use
`.debug` and `.dwp`, but if we want to only support this, this leaves the
downloading of the `.debug` file requiring a renam
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
dwblaikie wrote:
> > FWIW, I think we should be opinionated (& consistent with whatever gdb
> > does, if it has some precedent here - if it is less opinionated, then maybe
> > we have to be accepting) when it comes to whether x.debug goes with x.dwp
> > or x.debug.dwp - we shouldn't support bo
https://github.com/clayborg approved this pull request.
Ok, LGTM.
https://github.com/llvm/llvm-project/pull/81314
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/81314
>From 1d24f118373af64a212893366051b7da1b02d791 Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Fri, 9 Feb 2024 12:09:27 -0800
Subject: [PATCH 1/3] It makes no sense to make a ValueObjectPrinter with a
null Val
@@ -119,6 +120,32 @@ class Progress {
bool m_complete = false;
};
+/// A class used to group progress reports by category. This is done by using a
+/// map that maintains a refcount of each category of progress reports that
have
+/// come in. Keeping track of progress repor
jimingham wrote:
The other thing I'm trying to eliminate is problem arising from the way the old
code started with `m_valobj` primed to `nullptr` and then getting set by
calling GetMostSpecializedValue, but then not always accessing it through that
API, but often accessing `m_valobj` directly.
jimingham wrote:
I don't think this is a lifetime issue. If it were I would see more of the
crashes at random addresses.
Whatever's going on is something odd, so I'm just trying to make the code
easier to reason about. I think in the ValueObjectPrinter's case, it's code
will be cleaner if i
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/81067
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
clayborg wrote:
None of what I suggested was mandatory. I was mainly trying to make sure things
don't go away on us without us knowing about it. If we have crashes it is
always hard to tell if simple heap corruption is the issue or if we are having
lifetime issues. If you are not concerned abo
https://github.com/JDevlieghere edited
https://github.com/llvm/llvm-project/pull/81319
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
@@ -119,6 +120,32 @@ class Progress {
bool m_complete = false;
};
+/// A class used to group progress reports by category. This is done by using a
+/// map that maintains a refcount of each category of progress reports that
have
+/// come in. Keeping track of progress repor
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
@@ -119,6 +120,32 @@ class Progress {
bool m_complete = false;
};
+/// A class used to group progress reports by category. This is done by using a
+/// map that maintains a refcount of each category of progress reports that
have
+/// come in. Keeping track of progress repor
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/81319
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager
https://github.com/clayborg requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/81319
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jimingham wrote:
Note, these really are transitory objects and need to be quick to make and
delete because in the course of printing a complex object we make a
ValueObjectPrinter for each node we print. So we're making a lot of them as we
descend and then directly throwing them away when we'r
@@ -18,39 +18,35 @@
using namespace lldb;
using namespace lldb_private;
-ValueObjectPrinter::ValueObjectPrinter(ValueObject *valobj, Stream *s) {
- if (valobj) {
-DumpValueObjectOptions options(*valobj);
-Init(valobj, s, options, m_options.m_max_ptr_depth, 0, nullptr)
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 ff8c865838b46d0202963b816fbed50aaf96a7f4
dc2c387e357c7cdd6837614f20095d2f4540f9d8 --
@@ -177,7 +177,10 @@ class CommandObjectFrameDiagnose : public
CommandObjectParsed {
DumpValueObjectOptions options;
options.SetDeclPrintingHelper(helper);
-ValueObjectPrinter printer(valobj_sp.get(), &result.GetOutputStream(),
+// We've already handled the ca
https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/81314
>From 1d24f118373af64a212893366051b7da1b02d791 Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Fri, 9 Feb 2024 12:09:27 -0800
Subject: [PATCH 1/2] It makes no sense to make a ValueObjectPrinter with a
null Val
https://github.com/jimingham edited
https://github.com/llvm/llvm-project/pull/81314
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jimingham edited
https://github.com/llvm/llvm-project/pull/81314
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -177,7 +177,10 @@ class CommandObjectFrameDiagnose : public
CommandObjectParsed {
DumpValueObjectOptions options;
options.SetDeclPrintingHelper(helper);
-ValueObjectPrinter printer(valobj_sp.get(), &result.GetOutputStream(),
+// We've already handled the ca
jimingham wrote:
Replying to a bunch of Greg's comments in sum.
The way we use the ValueObjectPrinter is that you have a ValueObject and want
to print it, so you make a ValueObjectPrinter passing in that ValueObject, then
tell it to print it. We don't preserve ValueObjectPrinters or try to
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Chelsea Cassanova (chelcassanova)
Changes
Per discussions from https://github.com/llvm/llvm-project/pull/81026, it was
decided that having a class that manages a map of progress reports would be
beneficial in order to categorize them. This
https://github.com/chelcassanova created
https://github.com/llvm/llvm-project/pull/81319
Per discussions from https://github.com/llvm/llvm-project/pull/81026, it was
decided that having a class that manages a map of progress reports would be
beneficial in order to categorize them. This class i
clayborg wrote:
> Will this now work with .dwp files not having UUID?
I actually added a test for this and it works just fine if the main executable
(`a.out`) has a UUID and the debug info file (`a.out.debug`) also has the UUID,
but the .dwp file doesn't, we _are_ able to load the .dwp file ju
@@ -121,8 +135,10 @@ class ValueObjectPrinter {
private:
bool ShouldShowName() const;
- ValueObject *m_orig_valobj;
- ValueObject *m_valobj;
+ ValueObject &m_orig_valobj;
+ ValueObject *m_cached_valobj; /// Cache the current "most specialized" value.
cla
@@ -177,7 +177,10 @@ class CommandObjectFrameDiagnose : public
CommandObjectParsed {
DumpValueObjectOptions options;
options.SetDeclPrintingHelper(helper);
-ValueObjectPrinter printer(valobj_sp.get(), &result.GetOutputStream(),
+// We've already handled the ca
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/81314
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -18,39 +18,35 @@
using namespace lldb;
using namespace lldb_private;
-ValueObjectPrinter::ValueObjectPrinter(ValueObject *valobj, Stream *s) {
- if (valobj) {
-DumpValueObjectOptions options(*valobj);
-Init(valobj, s, options, m_options.m_max_ptr_depth, 0, nullptr)
https://github.com/clayborg commented:
See inlined comments, but maybe we need to start storing a
`std::weak_ptr` instead of raw pointers to things, and possibly
always passsing a `ValueObjectSP` object into the `ValueObjectPrinter` so it
holds a strong reference to the value object while prin
@@ -177,7 +177,10 @@ class CommandObjectFrameDiagnose : public
CommandObjectParsed {
DumpValueObjectOptions options;
options.SetDeclPrintingHelper(helper);
-ValueObjectPrinter printer(valobj_sp.get(), &result.GetOutputStream(),
+// We've already handled the ca
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: None (jimingham)
Changes
I get a small but fairly steady stream of crash reports which I can only
explain by ValueObjectPrinter trying to access its m_valobj field, and finding
it NULL. I have never been able to reproduce any of these, an
https://github.com/jimingham created
https://github.com/llvm/llvm-project/pull/81314
I get a small but fairly steady stream of crash reports which I can only
explain by ValueObjectPrinter trying to access its m_valobj field, and finding
it NULL. I have never been able to reproduce any of thes
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Po-yao Chang (poyaoc97)
Changes
LLDB_RELOCATABLE_PYTHON was removed in LLVM 11
(https://github.com/llvm/llvm-project/commit/3ec3f62f0a0b1ac13230922c91ffc988c1b1e8d5).
---
Full diff: https://github.com/llvm/llvm-project/pull/81310.diff
1 F
https://github.com/poyaoc97 created
https://github.com/llvm/llvm-project/pull/81310
LLDB_RELOCATABLE_PYTHON was removed in LLVM 11
(https://github.com/llvm/llvm-project/commit/3ec3f62f0a0b1ac13230922c91ffc988c1b1e8d5).
>From 756cb44e6965f1a01b2f9512f8e60d02eee14e8c Mon Sep 17 00:00:00 2001
From
Author: Adrian Prantl
Date: 2024-02-09T08:13:24-08:00
New Revision: 99446df3f5357b327b3884adf6465999ea60
URL:
https://github.com/llvm/llvm-project/commit/99446df3f5357b327b3884adf6465999ea60
DIFF:
https://github.com/llvm/llvm-project/commit/99446df3f5357b327b3884adf6465999ea60.diff
53 matches
Mail list logo
