[LLDB] Add external progress bit category (#120171)

As feedback on #119052, it was recommended I add a new bit to delineate
internal and external progress events. This patch adds this new
category

[LLDB] Add external progress bit category (#120171)

As feedback on #119052, it was recommended I add a new bit to delineate
internal and external progress events. This patch adds this new
category, and sets up Progress.h to support external events via
SBProgress.

show more ...

[lldb] Fix warnings

This patch fixes:

third-party/unittest/googletest/include/gtest/gtest.h:1379:11:
error: comparison of integers of different signs: 'const unsigned
long' and 'const int' [-

[lldb] Fix warnings

This patch fixes:

third-party/unittest/googletest/include/gtest/gtest.h:1379:11:
error: comparison of integers of different signs: 'const unsigned
long' and 'const int' [-Werror,-Wsign-compare]

show more ...

[lldb] Add ability to rate-limit progress reports (#119377)

For high-frequency multithreaded progress reports, the contention of
taking the progress mutex and the overhead of generating event can
si

[lldb] Add ability to rate-limit progress reports (#119377)

For high-frequency multithreaded progress reports, the contention of
taking the progress mutex and the overhead of generating event can
significantly slow down the operation whose progress we are reporting.

This patch adds an (optional) capability to rate-limit them. It's
optional because this approach has one drawback: if the progress
reporting has a pattern where it generates a burst of activity and then
blocks (without reporting anything) for a large amount of time, it can
appear as if less progress was made that it actually was (because we
only reported the first event from the burst and dropped the other
ones).

I've also made a small refactor of the Progress class to better
distinguish between const (don't need protection), atomic (are used on
the hot path) and other (need mutex protection) members.

show more ...

[lldb] Make sure that a `Progress` "completed" update is always reported at destruction (#102097)

Make all `Progress` destructions to cause `progressEnd` events,
regardless of the value of `m_compl

[lldb] Make sure that a `Progress` "completed" update is always reported at destruction (#102097)

Make all `Progress` destructions to cause `progressEnd` events,
regardless of the value of `m_completed` before the destruction.

Currently, a `Progress` instance with `m_completed != 0 && m_complete !=
m_total` will cause a `progressUpdate` event (not `progressEnd`) at
destruction and. This contradicts with the classdoc: "a progress completed
update is reported even if the user doesn't explicitly cause one to be sent."

show more ...

[lldb][enums] Remove broadcast bits from debugger (#91618)

Removes the debugger broadcast bits from `Debugger.h` and instead uses
the enum from `lldb-enumerations.h` and adds the
`eBroadcastSymbol

[lldb][enums] Remove broadcast bits from debugger (#91618)

Removes the debugger broadcast bits from `Debugger.h` and instead uses
the enum from `lldb-enumerations.h` and adds the
`eBroadcastSymbolChange` bit to the enum in `lldb-enumerations.h`. This fixes a bug wherein the incorrect broadcast bit could be referenced due both of these enums previously existing and being out-of-sync with each other.

show more ...

[lldb] Implement coalescing of disjoint progress events (#84854)

This implements coalescing of progress events using a timeout, as
discussed in the RFC on Discourse [1]. This PR consists of two comm

[lldb] Implement coalescing of disjoint progress events (#84854)

This implements coalescing of progress events using a timeout, as
discussed in the RFC on Discourse [1]. This PR consists of two commits
which, depending on the feedback, I may split up into two PRs. For now,
I think it's easier to review this as a whole.

1. The first commit introduces a new generic `Alarm` class. The class
lets you to schedule a function (callback) to be executed after a given
timeout expires. You can cancel and reset a callback before its
corresponding timeout expires. It achieves this with the help of a
worker thread that sleeps until the next timeout expires. The only
guarantee it provides is that your function is called no sooner than the
requested timeout. Because the callback is called directly from the
worker thread, a long running callback could potentially block the
worker thread. I intentionally kept the implementation as simple as
possible while addressing the needs for the `ProgressManager` use case.
If we want to rely on this somewhere else, we can reassess whether we
need to address those limitations.

2. The second commit uses the Alarm class to coalesce progress events.
To recap the Discourse discussion, when multiple progress events with
the same title execute in close succession, they get broadcast as one to
`eBroadcastBitProgressCategory`. The `ProgressManager` keeps track of
the in-flight progress events and when the refcount hits zero, the Alarm
class is used to schedule broadcasting the event. If a new progress
event comes in before the alarm fires, the alarm is reset (and the
process repeats when the new progress event ends). If no new event comes
in before the timeout expires, the progress event is broadcast.

[1]
https://discourse.llvm.org/t/rfc-improve-lldb-progress-reporting/75717/

show more ...

Revert "[lldb] Implement coalescing of disjoint progress events (#84854)"

This reverts commit 930f64689c1fb487714c3836ffa43e49e46aa488 as it's
failing on the Linux bots.

[lldb] Implement coalescing of disjoint progress events (#84854)

This implements coalescing of progress events using a timeout, as
discussed in the RFC on Discourse [1]. This PR consists of two com

[lldb] Implement coalescing of disjoint progress events (#84854)

This implements coalescing of progress events using a timeout, as
discussed in the RFC on Discourse [1]. This PR consists of two commits
which, depending on the feedback, I may split up into two PRs. For now,
I think it's easier to review this as a whole.

1. The first commit introduces a new generic `Alarm` class. The class
lets you to schedule a function (callback) to be executed after a given
timeout expires. You can cancel and reset a callback before its
corresponding timeout expires. It achieves this with the help of a
worker thread that sleeps until the next timeout expires. The only
guarantee it provides is that your function is called no sooner than the
requested timeout. Because the callback is called directly from the
worker thread, a long running callback could potentially block the
worker thread. I intentionally kept the implementation as simple as
possible while addressing the needs for the `ProgressManager` use case.
If we want to rely on this somewhere else, we can reassess whether we
need to address those limitations.

2. The second commit uses the Alarm class to coalesce progress events.
To recap the Discourse discussion, when multiple progress events with
the same title execute in close succession, they get broadcast as one to
`eBroadcastBitProgressCategory`. The `ProgressManager` keeps track of
the in-flight progress events and when the refcount hits zero, the Alarm
class is used to schedule broadcasting the event. If a new progress
event comes in before the alarm fires, the alarm is reset (and the
process repeats when the new progress event ends). If no new event comes
in before the timeout expires, the progress event is broadcast.

[1]
https://discourse.llvm.org/t/rfc-improve-lldb-progress-reporting/75717/

show more ...

[lldb] Do some gardening in ProgressReportTest (NFC) (#84278)

- Factor our common setup code.
- Split the ProgressManager test into separate tests as they test
separate things.
- Fix usage of EXP

[lldb] Do some gardening in ProgressReportTest (NFC) (#84278)

- Factor our common setup code.
- Split the ProgressManager test into separate tests as they test
separate things.
- Fix usage of EXPECT (which continues on failure) and ASSERT (which
halts on failure). We must use the latter when calling GetEvent as
otherwise we'll try to dereference a null EventSP.

show more ...

[lldb] Don't report all progress event as completed. (#84281)

Currently, progress events reported by the ProgressManager and broadcast
to eBroadcastBitProgressCategory always specify they're comple

[lldb] Don't report all progress event as completed. (#84281)

Currently, progress events reported by the ProgressManager and broadcast
to eBroadcastBitProgressCategory always specify they're complete. The
problem is that the ProgressManager reports kNonDeterministicTotal for
both the total and the completed number of (sub)events. Because the
values are the same, the event reports itself as complete.

This patch fixes the issue by reporting 0 as the completed value for the
start event and kNonDeterministicTotal for the end event.

show more ...

[lldb][progress] Hook up new broadcast bit and progress manager (#83069)

This commit adds the functionality to broadcast events using the
`Debugger::eBroadcastProgressCategory`
bit (https://github

[lldb][progress] Hook up new broadcast bit and progress manager (#83069)

This commit adds the functionality to broadcast events using the
`Debugger::eBroadcastProgressCategory`
bit (https://github.com/llvm/llvm-project/pull/81169) by keeping track
of these reports with the `ProgressManager`
class (https://github.com/llvm/llvm-project/pull/81319). The new bit is
used in such a way that it will only broadcast the initial and final
progress reports for specific progress categories that are managed by
the progress manager.

This commit also adds a new test to the progress report unit test that
checks that only the initial/final reports are broadcasted when using
the new bit.

show more ...

Reland "[lldb][progress][NFC] Add unit test for progress reports" (#80791)

This file was previously approved and merged from this PR:
https://github.com/llvm/llvm-project/pull/79533 but caused a te

Reland "[lldb][progress][NFC] Add unit test for progress reports" (#80791)

This file was previously approved and merged from this PR:
https://github.com/llvm/llvm-project/pull/79533 but caused a test
failure on the Linux AArch64 bots due to hitting an assertion that
`Debugger::Initialize` was already called.

To fix this, this commit uses the
changes made here: https://github.com/llvm/llvm-project/pull/80786 to
use a shared call_once flag to initialize the debugger.

show more ...

Reland "[lldb][progress][NFC] Add unit test for progress reports (#79533)"

This reverts commit 209fe1f3d70d1c4a20bb2687e0d0a94b1bbfa0c6.

The original commit failed to due an assertion failure in th

Reland "[lldb][progress][NFC] Add unit test for progress reports (#79533)"

This reverts commit 209fe1f3d70d1c4a20bb2687e0d0a94b1bbfa0c6.

The original commit failed to due an assertion failure in the unit test
`ProgressReportTest` that the commit added. The Debugger::Initialize()
function was called more than once which triggered the assertion, so
this commit calls that function under a `std::call_once`.

show more ...

[lldb][progress][NFC] Add unit test for progress reports (#79533)

This test is being added as a way to check the behaviour of how progress
events are broadcasted when reports are started and ended

[lldb][progress][NFC] Add unit test for progress reports (#79533)

This test is being added as a way to check the behaviour of how progress
events are broadcasted when reports are started and ended with the
current implementation of progress reports. Here we're mainly checking
and ensuring that the current behaviour is that progress events are
broadcasted individually and placed in the event queue in order of their
creation and deletion.

show more ...