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
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void
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
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void
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
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
@@ -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
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`
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
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
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void
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
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
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void
@@ -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
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void
@@ -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
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
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
@@ -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,
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(), (),
+// We've already handled the case where the value
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
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(), (),
+// We've already handled the case where the value
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.
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
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
@@ -121,8 +135,10 @@ class ValueObjectPrinter {
private:
bool ShouldShowName() const;
- ValueObject *m_orig_valobj;
- ValueObject *m_valobj;
+ ValueObject _orig_valobj;
+ ValueObject *m_cached_valobj; /// Cache the current "most specialized" value.
@@ -177,7 +177,10 @@ class CommandObjectFrameDiagnose : public
CommandObjectParsed {
DumpValueObjectOptions options;
options.SetDeclPrintingHelper(helper);
-ValueObjectPrinter printer(valobj_sp.get(), (),
+// We've already handled the case where the value
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,
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
@@ -177,7 +177,10 @@ class CommandObjectFrameDiagnose : public
CommandObjectParsed {
DumpValueObjectOptions options;
options.SetDeclPrintingHelper(helper);
-ValueObjectPrinter printer(valobj_sp.get(), (),
+// We've already handled the case where the value
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,
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
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
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
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
