@@ -227,7 +265,7 @@ class ThreadPool {
class ThreadPoolTaskGroup {
joker-eph wrote:
> Uniqueness is "guaranteed" through memory addressing. Someone can break
> uniqueness when going through the public ThreadPool API.
How so?
> Type safety; sure you don't hav
https://github.com/GeorgeARM edited
https://github.com/llvm/llvm-project/pull/82094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/GeorgeARM edited
https://github.com/llvm/llvm-project/pull/82094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/GeorgeARM edited
https://github.com/llvm/llvm-project/pull/82094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/GeorgeARM edited
https://github.com/llvm/llvm-project/pull/82094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/GeorgeARM edited
https://github.com/llvm/llvm-project/pull/82094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -227,7 +265,7 @@ class ThreadPool {
class ThreadPoolTaskGroup {
GeorgeARM wrote:
So the way I see this is:
I have a public API that looks like:
```
virtual void asyncEnqueue(std::function Task, ThreadPoolTaskGroup
*Group) = 0;
// or similar
```
My thoug
https://github.com/joker-eph edited
https://github.com/llvm/llvm-project/pull/82094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -227,7 +265,7 @@ class ThreadPool {
class ThreadPoolTaskGroup {
joker-eph wrote:
> What you get is probably a cleaner API IMHO
I don't quite get why it would cleaner actually? This makes is for a weaker
interface that does not guarantee any uniqueness an
https://github.com/GeorgeARM edited
https://github.com/llvm/llvm-project/pull/82094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -227,7 +265,7 @@ class ThreadPool {
class ThreadPoolTaskGroup {
GeorgeARM wrote:
Sure you can convert the address of the object to a string or int that is fine;
it is not the best but not worse than what is there. You can do this inside the
`ThreadPoolTaskG
@@ -227,7 +265,7 @@ class ThreadPool {
class ThreadPoolTaskGroup {
joker-eph wrote:
> We could change for example this with a std::string or uint64_t with probably
> minimal changes to any call site.
How would you get a unique id at runtime if not for the addr
https://github.com/GeorgeARM edited
https://github.com/llvm/llvm-project/pull/82094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -227,7 +265,7 @@ class ThreadPool {
class ThreadPoolTaskGroup {
GeorgeARM wrote:
Btw, I still think that passing a `ThreadPoolTaskGroup` for the sole purpose of
a uid is a bit brittle as you bind the interface with this construct but
internally to the `Thre
jasonmolenda wrote:
Thanks so much for reading through these @DavidSpickett and @hawkinsw !
@adrian-prantl and @JDevlieghere suggested using a doxygen group for this set
of methods and having the long definitions of `type` and `addr_range` a single
time, referring back to them from the indiv
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/83095
>From dae16776e8c97158e8965e4d0e950cd2ce836f75 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Mon, 26 Feb 2024 18:05:27 -0800
Subject: [PATCH 1/2] [lldb] Add SBProcess methods for get/set/use address
ma
@@ -29,8 +30,12 @@ Progress::Progress(std::string title, std::string details,
if (debugger)
m_debugger_id = debugger->GetID();
+
+ m_progress_data = {m_title, m_details, m_id,
+ m_completed, m_total, m_debugger_id};
chelcassano
@@ -227,7 +265,7 @@ class ThreadPool {
class ThreadPoolTaskGroup {
aganea wrote:
That point was raised by the OP in the Discourse thread (allow for custom
implementations of `ThreadPoolTaskGroup`) and I think it deserved a clear
answer, and I do agree now to y
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Walter Erquinigo (walter-erquinigo)
Changes
https://github.com/modularml/mojo/issues/1796 discovered that if you try to
complete a space-only line in the REPL on Linux, LLDB crashes. I suspect that
editline doesn't behave the same way on l
https://github.com/walter-erquinigo created
https://github.com/llvm/llvm-project/pull/83203
https://github.com/modularml/mojo/issues/1796 discovered that if you try to
complete a space-only line in the REPL on Linux, LLDB crashes. I suspect that
editline doesn't behave the same way on linux an
@@ -29,8 +30,12 @@ Progress::Progress(std::string title, std::string details,
if (debugger)
m_debugger_id = debugger->GetID();
+
+ m_progress_data = {m_title, m_details, m_id,
+ m_completed, m_total, m_debugger_id};
JDevliegher
@@ -1875,7 +1883,8 @@ lldb::thread_result_t Debugger::DefaultEventHandler() {
listener_sp->StartListeningForEvents(
&m_broadcaster, eBroadcastBitProgress | eBroadcastBitWarning |
- eBroadcastBitError | eBroadcastSymbolChange);
+
@@ -97,27 +98,44 @@ class Progress {
/// Used to indicate a non-deterministic progress report
static constexpr uint64_t kNonDeterministicTotal = UINT64_MAX;
+ /// Use a struct to send data from a Progress object to
+ /// the progress manager.
+ struct ProgressData {
+
@@ -1433,13 +1434,17 @@ void Debugger::SetDestroyCallback(
static void PrivateReportProgress(Debugger &debugger, uint64_t progress_id,
std::string title, std::string details,
uint64_t completed, uint64_t total,
@@ -1929,6 +1938,8 @@ lldb::thread_result_t Debugger::DefaultEventHandler() {
} else if (broadcaster == &m_broadcaster) {
if (event_type & Debugger::eBroadcastBitProgress)
HandleProgressEvent(event_sp);
+else if (event_type & Debu
https://github.com/bulbazord approved this pull request.
LGTM
@JDevlieghere @adrian-prantl we should consider adding this to the list of
required python modules on our bots too and enforce it with
`LLDB_ENFORCE_STRICT_TEST_REQUIREMENTS`? Probably not in this PR, but after we
can get our bots
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Zequan Wu (ZequanWu)
Changes
If a SetDataBreakpointsRequest contains a list data breakpoints which have
duplicate starting addresses, the current behaviour is returning `{verified:
true}` to both watchpoints with duplicated starting addres
https://github.com/ZequanWu created
https://github.com/llvm/llvm-project/pull/83192
If a SetDataBreakpointsRequest contains a list data breakpoints which have
duplicate starting addresses, the current behaviour is returning `{verified:
true}` to both watchpoints with duplicated starting addres
@@ -92,30 +104,32 @@ class ThreadPool {
&Group);
}
- /// Blocking wait for all the threads to complete and the queue to be empty.
- /// It is an error to try to add new tasks while blocking on this call.
- /// Calling wait() from a task would deadlock
https://github.com/joker-eph updated
https://github.com/llvm/llvm-project/pull/82094
>From f13befdfdb8715c034eed6dd4c04f712d30d043a Mon Sep 17 00:00:00 2001
From: Mehdi Amini
Date: Fri, 16 Feb 2024 21:55:57 -0800
Subject: [PATCH] Split the llvm::ThreadPool into an abstract base class and an
im
@@ -92,30 +104,32 @@ class ThreadPool {
&Group);
}
- /// Blocking wait for all the threads to complete and the queue to be empty.
- /// It is an error to try to add new tasks while blocking on this call.
- /// Calling wait() from a task would deadlock
@@ -92,30 +104,20 @@ class ThreadPool {
&Group);
}
- /// Blocking wait for all the threads to complete and the queue to be empty.
- /// It is an error to try to add new tasks while blocking on this call.
- /// Calling wait() from a task would deadlock
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jordan Rupprecht (rupprecht)
Changes
The goal here is to remove the third_party/Python/module tree, which LLDB tests
only use to `import pexpect`. This package is available on `pip`, and I believe
should not be hard to obtain.
However, in
https://github.com/rupprecht created
https://github.com/llvm/llvm-project/pull/83191
The goal here is to remove the third_party/Python/module tree, which LLDB tests
only use to `import pexpect`. This package is available on `pip`, and I believe
should not be hard to obtain.
However, in case i
@@ -92,30 +104,32 @@ class ThreadPool {
&Group);
}
- /// Blocking wait for all the threads to complete and the queue to be empty.
- /// It is an error to try to add new tasks while blocking on this call.
- /// Calling wait() from a task would deadlock
https://github.com/joker-eph edited
https://github.com/llvm/llvm-project/pull/82094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -227,7 +265,7 @@ class ThreadPool {
class ThreadPoolTaskGroup {
joker-eph wrote:
> Wouldn't the implemention for ThreadPoolTaskGroup come in hand with the one
> for ThreadPool?
Right now the only thing the TaskGroup provide is a unique ID in the form of
i
https://github.com/rupprecht closed
https://github.com/llvm/llvm-project/pull/83162
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Jordan Rupprecht
Date: 2024-02-27T12:43:05-06:00
New Revision: e427e934f677567f8184ff900cb4cbdb8cf21a21
URL:
https://github.com/llvm/llvm-project/commit/e427e934f677567f8184ff900cb4cbdb8cf21a21
DIFF:
https://github.com/llvm/llvm-project/commit/e427e934f677567f8184ff900cb4cbdb8cf21a21.di
Author: jimingham
Date: 2024-02-27T10:34:01-08:00
New Revision: 2d704f4bf2edb0f9343dac818ab4d29442be9968
URL:
https://github.com/llvm/llvm-project/commit/2d704f4bf2edb0f9343dac818ab4d29442be9968
DIFF:
https://github.com/llvm/llvm-project/commit/2d704f4bf2edb0f9343dac818ab4d29442be9968.diff
LOG
https://github.com/jimingham closed
https://github.com/llvm/llvm-project/pull/83097
___
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/83069
>From 2cef4a29f0105847fa11b7f6a6ee063184fb838a Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Tue, 20 Feb 2024 13:56:53 -0800
Subject: [PATCH] [lldb][progress] Hook up new broadcast bit and progress
https://github.com/chelcassanova updated
https://github.com/llvm/llvm-project/pull/83069
>From d2854ecb51d5996cd5cabf4e1c1ac9dc6e01240b Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Tue, 20 Feb 2024 13:56:53 -0800
Subject: [PATCH] [lldb][progress] Hook up new broadcast bit and progress
https://github.com/ZequanWu approved this pull request.
https://github.com/llvm/llvm-project/pull/83162
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/bulbazord closed
https://github.com/llvm/llvm-project/pull/83086
___
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-27T10:25:56-08:00
New Revision: 0ef66fcc858cc8abb978d83d48b3e7a8b23742c9
URL:
https://github.com/llvm/llvm-project/commit/0ef66fcc858cc8abb978d83d48b3e7a8b23742c9
DIFF:
https://github.com/llvm/llvm-project/commit/0ef66fcc858cc8abb978d83d48b3e7a8b23742c9.diff
https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/83097
>From 2ed71038d9d16a09b3a04cf667dd272c911fef23 Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Mon, 26 Feb 2024 18:09:18 -0800
Subject: [PATCH 1/2] Start to clean up the process of defining command
arguments.
https://github.com/walter-erquinigo approved this pull request.
This is amazing! That finally explains some flakes I've seen
https://github.com/llvm/llvm-project/pull/83162
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.or
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jordan Rupprecht (rupprecht)
Changes
The `EventThreadFunction` can end up calling `HandleCommand` concurrently with
the main request processing thread. The underlying API does not appear to be
thread safe, so add a narrowly scoped mutex lo
https://github.com/rupprecht created
https://github.com/llvm/llvm-project/pull/83162
The `EventThreadFunction` can end up calling `HandleCommand` concurrently with
the main request processing thread. The underlying API does not appear to be
thread safe, so add a narrowly scoped mutex lock to p
@@ -407,6 +407,129 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// Get the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ ///
https://github.com/hawkinsw edited
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -407,6 +407,129 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// Get the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ ///
https://github.com/hawkinsw commented:
I really appreciate the thorough documentation you wrote for these new
functions. Because there is so much overlap in the documentation between the
functions, could we refactor it somehow (not sure how?) so that any future
change could be more easily trac
@@ -694,27 +712,32 @@ void CommandObject::GenerateHelpText(Stream &output_strm)
{
}
}
-void CommandObject::AddIDsArgumentData(CommandArgumentEntry &arg,
- CommandArgumentType ID,
- CommandArgumentTy
https://github.com/GeorgeARM edited
https://github.com/llvm/llvm-project/pull/82094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -227,7 +265,7 @@ class ThreadPool {
class ThreadPoolTaskGroup {
GeorgeARM wrote:
Get the point of @aganea; the `ThreadPoolTaskGroup` is a bit tricky to reason
when it comes to customized extensibility as the concrete implementation is
injected to the interf
@@ -92,30 +104,20 @@ class ThreadPool {
&Group);
}
- /// Blocking wait for all the threads to complete and the queue to be empty.
- /// It is an error to try to add new tasks while blocking on this call.
- /// Calling wait() from a task would deadlock
https://github.com/GeorgeARM commented:
Sorry to pitch in; hope my comments help.
Overall, looks like a nice starting drop-in interface injection on top of the
what we have. Thanks @joker-eph
https://github.com/llvm/llvm-project/pull/82094
___
lldb-c
https://github.com/GeorgeARM edited
https://github.com/llvm/llvm-project/pull/82094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Adrian Prantl
Date: 2024-02-27T08:14:46-08:00
New Revision: 8a87f763a6841832e71bcd24dea45eac8d2dbee1
URL:
https://github.com/llvm/llvm-project/commit/8a87f763a6841832e71bcd24dea45eac8d2dbee1
DIFF:
https://github.com/llvm/llvm-project/commit/8a87f763a6841832e71bcd24dea45eac8d2dbee1.diff
https://github.com/adrian-prantl closed
https://github.com/llvm/llvm-project/pull/83099
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -227,7 +265,7 @@ class ThreadPool {
class ThreadPoolTaskGroup {
aganea wrote:
Wouldn't the implemention for `ThreadPoolTaskGroup` come in hand with the one
for `ThreadPool`? I feel if someone implements the `ThreadPoolInterface` they
would want something si
@@ -407,6 +407,129 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// Get the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ ///
@@ -407,6 +407,129 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// Get the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ ///
@@ -407,6 +407,129 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// Get the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ ///
@@ -407,6 +407,129 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// Get the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ ///
Author: David Spickett
Date: 2024-02-27T09:34:42Z
New Revision: a1bbba06eabc5ddf533e611d15fddcfd0a8e79db
URL:
https://github.com/llvm/llvm-project/commit/a1bbba06eabc5ddf533e611d15fddcfd0a8e79db
DIFF:
https://github.com/llvm/llvm-project/commit/a1bbba06eabc5ddf533e611d15fddcfd0a8e79db.diff
LOG
@@ -92,30 +104,32 @@ class ThreadPool {
&Group);
}
- /// Blocking wait for all the threads to complete and the queue to be empty.
- /// It is an error to try to add new tasks while blocking on this call.
- /// Calling wait() from a task would deadlock
@@ -92,30 +104,32 @@ class ThreadPool {
&Group);
}
- /// Blocking wait for all the threads to complete and the queue to be empty.
- /// It is an error to try to add new tasks while blocking on this call.
- /// Calling wait() from a task would deadlock
https://github.com/joker-eph updated
https://github.com/llvm/llvm-project/pull/82094
>From f9f2e9380b1333b3b2503aebb6ee234b84b8c035 Mon Sep 17 00:00:00 2001
From: Mehdi Amini
Date: Fri, 16 Feb 2024 21:55:57 -0800
Subject: [PATCH] Split the llvm::ThreadPool into an abstract base class and an
im
71 matches
Mail list logo
