@@ -66,3 +67,41 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+ProgressManager &ProgressManager::InstanceImpl() {
+ static std::once_flag g_once_flag;
+ static ProgressManager *g_progress_manager = nullptr;
+ std::call_once(g_once_
Author: Prabhuk
Date: 2024-02-14T22:07:26-08:00
New Revision: 6c74a6f6f4f01500f9deabadc7673b4935643928
URL:
https://github.com/llvm/llvm-project/commit/6c74a6f6f4f01500f9deabadc7673b4935643928
DIFF:
https://github.com/llvm/llvm-project/commit/6c74a6f6f4f01500f9deabadc7673b4935643928.diff
LOG:
https://github.com/Prabhuk closed
https://github.com/llvm/llvm-project/pull/81812
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -66,3 +67,41 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+ProgressManager &ProgressManager::InstanceImpl() {
+ static std::once_flag g_once_flag;
+ static ProgressManager *g_progress_manager = nullptr;
+ std::call_once(g_once_
@@ -66,3 +67,41 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+ProgressManager &ProgressManager::InstanceImpl() {
+ static std::once_flag g_once_flag;
+ static ProgressManager *g_progress_manager = nullptr;
+ std::call_once(g_once_
https://github.com/kusmour updated
https://github.com/llvm/llvm-project/pull/81706
>From 0fec0afdbcfcb896a45c4ba837331aa2c0349f02 Mon Sep 17 00:00:00 2001
From: Wanyi Ye
Date: Mon, 5 Feb 2024 11:33:03 -0800
Subject: [PATCH 1/4] Only report total currently loaded debug info
---
lldb/include/ll
ZequanWu wrote:
>From logs, looks like setting breakpoint with size being 1 byte failed on arm,
>and works with size being 4 bytes.
https://github.com/llvm/llvm-project/pull/81541
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists
https://github.com/ZequanWu approved this pull request.
Thanks for reporting.
https://github.com/llvm/llvm-project/pull/81812
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kusmour updated
https://github.com/llvm/llvm-project/pull/81706
>From 0fec0afdbcfcb896a45c4ba837331aa2c0349f02 Mon Sep 17 00:00:00 2001
From: Wanyi Ye
Date: Mon, 5 Feb 2024 11:33:03 -0800
Subject: [PATCH 1/4] Only report total currently loaded debug info
---
lldb/include/ll
https://github.com/kusmour edited
https://github.com/llvm/llvm-project/pull/81706
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kusmour updated
https://github.com/llvm/llvm-project/pull/81706
>From 0fec0afdbcfcb896a45c4ba837331aa2c0349f02 Mon Sep 17 00:00:00 2001
From: Wanyi Ye
Date: Mon, 5 Feb 2024 11:33:03 -0800
Subject: [PATCH 1/4] Only report total currently loaded debug info
---
lldb/include/ll
https://github.com/kusmour updated
https://github.com/llvm/llvm-project/pull/81706
>From 0fec0afdbcfcb896a45c4ba837331aa2c0349f02 Mon Sep 17 00:00:00 2001
From: Wanyi Ye
Date: Mon, 5 Feb 2024 11:33:03 -0800
Subject: [PATCH 1/4] Only report total currently loaded debug info
---
lldb/include/ll
kamleshbhalui wrote:
> I am fine with this patch if we fix the Scalar class to obey the bit width as
> suggested above. I do worry though that other Scalar values in the expression
> might get set to 64 bit values all of the time and cause problems with DWARF
> expressions. Do you have a code
@@ -857,10 +857,18 @@ static Scalar DerefSizeExtractDataHelper(uint8_t
*addr_bytes,
DataExtractor addr_data(addr_bytes, size_addr_bytes, byte_order, size);
lldb::offset_t addr_data_offset = 0;
- if (size <= 8)
-return addr_data.GetMaxU64(&addr_data_offset, size);
-
kamleshbhalui wrote:
> > @clayborg @bulbazord we have extension in lldb to support cobol code
> > debugging, we require byteswapping there. upstream version of lldb does not
> > do byteswapping on scalar so no problem seen.
>
> Maybe not, but this should still be testable with a unit test. If
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Prabhuk (Prabhuk)
Changes
This reverts commit 8c56e78ec531f0e2460213c20fff869b6b7add99.
Reverting to address the LLDB test failure in ARM64.
---
Patch is 28.13 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm
https://github.com/Prabhuk created
https://github.com/llvm/llvm-project/pull/81812
This reverts commit 8c56e78ec531f0e2460213c20fff869b6b7add99.
Reverting to address the LLDB test failure in ARM64.
>From 73070214069c491623689858788b4c26e434a10b Mon Sep 17 00:00:00 2001
From: prabhukr
Date: We
@@ -883,8 +906,17 @@ static bool DumpValue(Stream &s, const SymbolContext *sc,
}
if (!is_array_range) {
-LLDB_LOGF(log,
- "[Debugger::FormatPrompt] dumping ordinary printable output");
+if (!entry.printf_format.empty()) {
+ if (DumpValueWithPrintf
@@ -658,6 +658,29 @@ static char ConvertValueObjectStyleToChar(
return '\0';
}
+static bool DumpValueWithPrintf(Stream &s, llvm::StringRef format,
+ValueObject &target) {
+ auto type_info = target.GetTypeInfo();
+ if (type_info & eTypeIsInte
kastiglione wrote:
@jimingham I've updated the PR to a non-draft form if you want to check out the
implementation.
https://github.com/llvm/llvm-project/pull/81196
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
Prabhuk wrote:
We (Fuchsia clang toolchain team) are facing a LLDB test failure in our ARM64
Clang toolchain builders and I suspect this change is causing the failure.
Build link:
https://ci.chromium.org/raw/build/logs.chromium.org/fuchsia/led/prabhukr_google.com/04517f65babfe0d4ee60f891a29018
Author: Jordan Rupprecht
Date: 2024-02-14T15:53:19-06:00
New Revision: 0fc578664809d9f808d24a91e50a68d6bfa22118
URL:
https://github.com/llvm/llvm-project/commit/0fc578664809d9f808d24a91e50a68d6bfa22118
DIFF:
https://github.com/llvm/llvm-project/commit/0fc578664809d9f808d24a91e50a68d6bfa22118.di
https://github.com/rupprecht closed
https://github.com/llvm/llvm-project/pull/81703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
rupprecht wrote:
> Yeah given GreenDragon has been red for 20h, I'd like to get this merged
> sooner rather than later. @DavidSpickett what's the benefit of waiting for
> the arm bots to come back up?
Broadly speaking, if a buildbot is down, it interferes with bisection if
something unexpecte
Author: Dave Lee
Date: 2024-02-14T13:13:23-08:00
New Revision: 1da4494184566d68f32206e3ac5a8b90bc05889d
URL:
https://github.com/llvm/llvm-project/commit/1da4494184566d68f32206e3ac5a8b90bc05889d
DIFF:
https://github.com/llvm/llvm-project/commit/1da4494184566d68f32206e3ac5a8b90bc05889d.diff
LOG:
https://github.com/kastiglione closed
https://github.com/llvm/llvm-project/pull/81681
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kastiglione updated
https://github.com/llvm/llvm-project/pull/81681
>From 35a48898e20ba45db829dbf137d88a8417dd4d7c Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Tue, 13 Feb 2024 14:43:33 -0800
Subject: [PATCH 1/2] [lldb] Add comment on cross printing of summary/value
---
ll
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/81573
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Jason Molenda
Date: 2024-02-14T13:06:20-08:00
New Revision: aab48c99c2234e348aa37657accfb6110c84c9b7
URL:
https://github.com/llvm/llvm-project/commit/aab48c99c2234e348aa37657accfb6110c84c9b7
DIFF:
https://github.com/llvm/llvm-project/commit/aab48c99c2234e348aa37657accfb6110c84c9b7.diff
@@ -66,3 +67,41 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+ProgressManager &ProgressManager::InstanceImpl() {
+ static std::once_flag g_once_flag;
+ static ProgressManager *g_progress_manager = nullptr;
+ std::call_once(g_once_
https://github.com/jimingham approved this pull request.
Thanks for taking out the friend. LGTM.
https://github.com/llvm/llvm-project/pull/81573
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/
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 1/2] [lldb][progress] Add progress manager class
Per dis
https://github.com/jeffreytan81 updated
https://github.com/llvm/llvm-project/pull/81564
>From d65900f5e6169062fc0988b57fb5be2474789025 Mon Sep 17 00:00:00 2001
From: jeffreytan81
Date: Mon, 12 Feb 2024 18:08:23 -0800
Subject: [PATCH 1/4] Fix lldb crash while handling concurrent vfork()
---
..
dwblaikie wrote:
> > > If the client strips the debug info first into "a.out.debug" and then
> > > runs llvm-dwp, they will end up with a "a.out.debug.dwp". We have clients
> > > that are doing this already and we want to support them.
> >
> >
> > OK, could we fix llvm-dwp to match the behavi
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
bc66e0cf9feb8f3c38fa2e33850b6c6e5477fb21...2e7bf2386394ff35fa43f0cb78ea029e0e075bc8
lldb/
https://github.com/jeffreytan81 updated
https://github.com/llvm/llvm-project/pull/81564
>From d65900f5e6169062fc0988b57fb5be2474789025 Mon Sep 17 00:00:00 2001
From: jeffreytan81
Date: Mon, 12 Feb 2024 18:08:23 -0800
Subject: [PATCH 1/3] Fix lldb crash while handling concurrent vfork()
---
..
clayborg wrote:
I am fine with this patch if we fix the Scalar class to obey the bit width as
suggested above. I do worry though that other Scalar values in the expression
might get set to 64 bit values all of the time and cause problems with DWARF
expressions. Do you have a code snippet of wh
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 r
dwblaikie 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 `.debu
JDevlieghere wrote:
Yeah given GreenDragon has been red for 20h, I'd like to get this merged sooner
rather than later. @DavidSpickett what's the benefit of waiting for the arm
bots to come back up?
https://github.com/llvm/llvm-project/pull/81703
___
bulbazord wrote:
> @clayborg @bulbazord we have extension in lldb to support cobol code
> debugging, we require byteswapping there. upstream version of lldb does not
> do byteswapping on scalar so no problem seen.
Maybe not, but this should still be testable with a unit test. If somebody
modi
https://github.com/bulbazord commented:
Idea looks ok, the naming could use a bit of work. Right now it feels a bit
generic and I'm not sure what "loading" means. I like Greg's suggestion here.
https://github.com/llvm/llvm-project/pull/81706
___
lldb-
@@ -224,6 +224,7 @@ llvm::json::Value DebuggerStats::ReportStatistics(
const lldb_private::StatisticsOptions &options) {
const bool summary_only = options.summary_only;
+ const bool force_laoding = options.force_loading;
bulbazord wrote:
typo in this o
https://github.com/bulbazord closed
https://github.com/llvm/llvm-project/pull/79901
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Alex Langford
Date: 2024-02-14T10:20:58-08:00
New Revision: 307cd883546348cd658d74699915fd48ae01e9a0
URL:
https://github.com/llvm/llvm-project/commit/307cd883546348cd658d74699915fd48ae01e9a0
DIFF:
https://github.com/llvm/llvm-project/commit/307cd883546348cd658d74699915fd48ae01e9a0.diff
rupprecht wrote:
The arm bots still haven't picked up the change :(
Green Dragon is back online, and TestRequireHWBreakpoints.py is failing:
https://green.lab.llvm.org/green/view/LLDB/job/as-lldb-cmake/16077/testReport/lldb-api/functionalities_breakpoint_hardware_breakpoints_require_hw_breakpoi
kastiglione wrote:
@adrian-prantl good call, done.
https://github.com/llvm/llvm-project/pull/81196
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kastiglione updated
https://github.com/llvm/llvm-project/pull/81196
>From 81a2034ff2b41e30a1f5b82c86b4d5d4c429ed52 Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Thu, 8 Feb 2024 13:59:12 -0800
Subject: [PATCH 1/4] [lldb] Support custom printf formatting for variables
---
lld
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/81710
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Jason Molenda
Date: 2024-02-14T10:05:22-08:00
New Revision: dbc40b34617b5ee5d2f82272c8863c602265063c
URL:
https://github.com/llvm/llvm-project/commit/dbc40b34617b5ee5d2f82272c8863c602265063c
DIFF:
https://github.com/llvm/llvm-project/commit/dbc40b34617b5ee5d2f82272c8863c602265063c.diff
@@ -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
@@ -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
@@ -857,10 +857,18 @@ static Scalar DerefSizeExtractDataHelper(uint8_t
*addr_bytes,
DataExtractor addr_data(addr_bytes, size_addr_bytes, byte_order, size);
lldb::offset_t addr_data_offset = 0;
- if (size <= 8)
-return addr_data.GetMaxU64(&addr_data_offset, size);
-
@@ -66,3 +67,41 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+ProgressManager &ProgressManager::InstanceImpl() {
+ static std::once_flag g_once_flag;
+ static ProgressManager *g_progress_manager = nullptr;
+ std::call_once(g_once_
@@ -66,3 +67,41 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+ProgressManager &ProgressManager::InstanceImpl() {
+ static std::once_flag g_once_flag;
+ static ProgressManager *g_progress_manager = nullptr;
+ std::call_once(g_once_
@@ -66,3 +67,41 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+ProgressManager &ProgressManager::InstanceImpl() {
+ static std::once_flag g_once_flag;
+ static ProgressManager *g_progress_manager = nullptr;
+ std::call_once(g_once_
@@ -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
@@ -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
@@ -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
@@ -825,6 +806,56 @@ StopInfoSP
StopInfoMachException::CreateStopReasonWithMachException(
break;
}
- return StopInfoSP(new StopInfoMachException(thread, exc_type, exc_data_count,
- exc_code, exc_sub_code));
+ return std::ma
@@ -825,6 +806,56 @@ StopInfoSP
StopInfoMachException::CreateStopReasonWithMachException(
break;
}
- return StopInfoSP(new StopInfoMachException(thread, exc_type, exc_data_count,
- exc_code, exc_sub_code));
+ return std::ma
adrian-prantl wrote:
Should this be documented in `lldb/docs/use/variable.rst` or a similar place on
the website?
https://github.com/llvm/llvm-project/pull/81196
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
https://github.com/arrowd updated
https://github.com/llvm/llvm-project/pull/81355
>From f129c6315388085e95244b9df289d22524c86890 Mon Sep 17 00:00:00 2001
From: Gleb Popov <6year...@gmail.com>
Date: Sat, 10 Feb 2024 14:15:49 +0300
Subject: [PATCH] [lldb] Teach LocateExecutableSymbolFile to look i
https://github.com/JDevlieghere approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/81710
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
felipepiovezan wrote:
All patches merged
https://github.com/llvm/llvm-project/pull/77121
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/felipepiovezan closed
https://github.com/llvm/llvm-project/pull/77121
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -2757,13 +2769,18 @@ void request_dataBreakpointInfo(const
llvm::json::Object &request) {
body.try_emplace("description", error_cstr && error_cstr[0]
? std::string(error_cstr)
: "evalu
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/81680
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu commented:
In terms of interpreting `name` as `${number of bytes}@${expression}`, it's
made-up. And I just noticed that someone already filed an issue about this:
https://github.com/microsoft/debug-adapter-protocol/issues/455. Should we
revert the change inside the
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/81680
>From f9c509c519c9937d2e2de5098c4241e936187527 Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Tue, 13 Feb 2024 17:41:26 -0500
Subject: [PATCH 1/2] [lldb-dap] Followup fixs for data breakpoints
---
lldb/tools/l
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
kamleshbhalui wrote:
> > > This uses `DataExtractor::GetMaxU64` which already does this under the
> > > hood. What does this do that isn't already being done? It may help if you
> > > add a test case to show what you are trying to fix.
> >
> >
> > @clayborg @bulbazord The problem with GetMaxU
kamleshbhalui wrote:
I think this PR https://reviews.llvm.org/D121408 introduced the current code,
which causing the problem.
https://github.com/llvm/llvm-project/pull/81451
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.
kamleshbhalui wrote:
@clayborg @bulbazord
we have extension in lldb to support cobol code debugging, we require
byteswapping there. upstream version of lldb does not do byteswapping on scalar
so no problem seen.
https://github.com/llvm/llvm-project/pull/81451
_
https://github.com/DavidSpickett approved this pull request.
LGTM.
Please hold off on merging until the Arm lldb bots are working again. I've
landed the fix so it shouldn't be too long now.
https://github.com/llvm/llvm-project/pull/81703
___
lldb-com
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 approved this pull request.
LGTM
Can you add a bit more detail into the commit message and PR description about
what the underlying problem was. I.e., `DeclContextGetName` used to return type
names without template parameters which `FindTypes` would then compare a
DavidSpickett wrote:
Yeah now was a bad time to land this unfortunately, because I managed to screw
up Linaro's lldb bots. Waiting on a fix for that to go in and we'll get back to
you if stuff is broken.
https://github.com/llvm/llvm-project/pull/79945
__
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Endilll ready_for_review
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -150,6 +150,23 @@ def test(self):
invalid_type = task_type.FindDirectNestedType(None)
self.assertFalse(invalid_type)
+# Check that FindDirectNestedType works with types from AST
+pointer = frame0.FindVariable("pointer")
+pointer_type
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/81666
>From bf92dc89858668518a5d842eac34bdf1b3eaade2 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Wed, 14 Feb 2024 00:26:09 +0300
Subject: [PATCH 1/3] [lldb] Fix `FindDirectNestedType` not working with class
83 matches
Mail list logo
