<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/API/SystemInitializerFull.cpp, branch users/nico/python-2</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[LLDB][NFC] Remove Debugger dependency in SystemLifetimeManager (#134383)</title>
<updated>2025-04-08T18:24:59+00:00</updated>
<author>
<name>Dmitry Vasilyev</name>
<email>dvassiliev@accesssoftek.com</email>
</author>
<published>2025-04-08T18:24:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7e70d708a39470397a8df9aa5842d0875b471def'/>
<id>7e70d708a39470397a8df9aa5842d0875b471def</id>
<content type='text'>
It reduces the memory usage in lldb-server.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It reduces the memory usage in lldb-server.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Remove progress report coalescing (#130329)</title>
<updated>2025-03-08T17:10:46+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-03-08T17:10:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a1b14dbc4740fe49dfb2af44907a195597474556'/>
<id>a1b14dbc4740fe49dfb2af44907a195597474556</id>
<content type='text'>
Remove support for coalescing progress reports in LLDB. This
functionality was motivated by Xcode, which wanted to listen for less
frequent, aggregated progress events at the cost of losing some detail.
See the original RFC [1] for more details. Since then, they've
reevaluated this trade-off and opted to listen for the regular, full
fidelity progress events and do any post processing on their end.

rdar://146425487</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove support for coalescing progress reports in LLDB. This
functionality was motivated by Xcode, which wanted to listen for less
frequent, aggregated progress events at the cost of losing some detail.
See the original RFC [1] for more details. Since then, they've
reevaluated this trade-off and opted to listen for the regular, full
fidelity progress events and do any post processing on their end.

rdar://146425487</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Log errors to the system log if they would otherwise get dropped (#111911)</title>
<updated>2024-10-22T16:00:08+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2024-10-22T16:00:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cd4b33c9a976543171bb7b3455c485f99cfe654b'/>
<id>cd4b33c9a976543171bb7b3455c485f99cfe654b</id>
<content type='text'>
Log errors to the (always-on) system log if they would otherwise get
dropped by LLDB_LOG_ERROR.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Log errors to the (always-on) system log if they would otherwise get
dropped by LLDB_LOG_ERROR.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Introduce an always-on system log category/channel (#108495)</title>
<updated>2024-10-10T15:47:30+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2024-10-10T15:47:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c77b10746160f985625603b1e9c837b44caa5c67'/>
<id>c77b10746160f985625603b1e9c837b44caa5c67</id>
<content type='text'>
Add an "always on" log category and channel. Unlike other, existing log
channels, it is not exposed to users. The channel is meant to be used
sparsely and deliberately for logging high-value information to the
system log.

We have a similar concept in the downstream Swift fork and this has
proven to be extremely valuable. This is especially true on macOS where
system log messages are automatically captured as part of a sysdiagnose.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add an "always on" log category and channel. Unlike other, existing log
channels, it is not exposed to users. The channel is meant to be used
sparsely and deliberately for logging high-value information to the
system log.

We have a similar concept in the downstream Swift fork and this has
proven to be extremely valuable. This is especially true on macOS where
system log messages are automatically captured as part of a sysdiagnose.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Implement coalescing of disjoint progress events (#84854)</title>
<updated>2024-03-26T19:35:34+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2024-03-25T21:50:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=156c2907462bc5e97d13d3e7d334a32a291bc787'/>
<id>156c2907462bc5e97d13d3e7d334a32a291bc787</id>
<content type='text'>
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/
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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/
</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB] Don't forcefully initialize the process trace plugin (#71455)</title>
<updated>2023-11-07T00:45:52+00:00</updated>
<author>
<name>Walter Erquinigo</name>
<email>a20012251@gmail.com</email>
</author>
<published>2023-11-07T00:45:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=555a71be457f351411b89c6a6a66aeecf7ca5291'/>
<id>555a71be457f351411b89c6a6a66aeecf7ca5291</id>
<content type='text'>
This was causing some process to wrongfully be handled by ProcessTrace.
    
The only place this was being used is in the intel pt plugin, but it
doesn't even build anymore, so I'm sure no one is using it.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This was causing some process to wrongfully be handled by ProcessTrace.
    
The only place this was being used is in the intel pt plugin, but it
doesn't even build anymore, so I'm sure no one is using it.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Print lldbassert to debugger diagnostics</title>
<updated>2023-06-14T03:46:33+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2023-06-14T03:24:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=83a6a0a620476d2fa181cb663ccbf06cc9d7a24f'/>
<id>83a6a0a620476d2fa181cb663ccbf06cc9d7a24f</id>
<content type='text'>
When hitting an lldbassert in a non-assert build, we emit a blurb
including the assertion, the triggering file and line and a pretty
backtrace leading up to the issue. Currently, this is all printed to
stderr. That's fine on the command line, but when used as library, for
example from Xcode, this information doesn't make it to the user. This
patch uses the diagnostic infrastructure to report LLDB asserts as
diagnostic events.

The patch is slightly more complicated than I would've liked because of
layering. lldbassert is part of Utility while the debugger diagnostics
are implemented in Core.

Differential revision: https://reviews.llvm.org/D152866
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When hitting an lldbassert in a non-assert build, we emit a blurb
including the assertion, the triggering file and line and a pretty
backtrace leading up to the issue. Currently, this is all printed to
stderr. That's fine on the command line, but when used as library, for
example from Xcode, this information doesn't make it to the user. This
patch uses the diagnostic infrastructure to report LLDB asserts as
diagnostic events.

The patch is slightly more complicated than I would've liked because of
layering. lldbassert is part of Utility while the debugger diagnostics
are implemented in Core.

Differential revision: https://reviews.llvm.org/D152866
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Remove LLDB reproducers</title>
<updated>2022-09-19T21:43:31+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2022-09-19T17:47:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=70599d70273b671b1b2e6a0e0b9c11e413209647'/>
<id>70599d70273b671b1b2e6a0e0b9c11e413209647</id>
<content type='text'>
This patch removes the remaining reproducer code. The SBReproducer class
remains for ABI stability but is just an empty shell. This completes the
removal process outlined on the mailing list [1].

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch removes the remaining reproducer code. The SBReproducer class
remains for ABI stability but is just an empty shell. This completes the
removal process outlined on the mailing list [1].

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Use nullptr instead of 0 or NULL (NFC)</title>
<updated>2022-01-01T19:54:25+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2022-01-01T19:54:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b8336280d8244039a648ffde06b1e857cb664b15'/>
<id>b8336280d8244039a648ffde06b1e857cb664b15</id>
<content type='text'>
This is a re-submission of 24d240558811604354a8d6080405f6bad8d15b5c
without the hunks in HostNativeThreadBase.{h,cpp}, which break builds
on Windows.

Identified with modernize-use-nullptr.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a re-submission of 24d240558811604354a8d6080405f6bad8d15b5c
without the hunks in HostNativeThreadBase.{h,cpp}, which break builds
on Windows.

Identified with modernize-use-nullptr.
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[lldb] Use nullptr instead of 0 or NULL (NFC)"</title>
<updated>2022-01-01T19:15:14+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2022-01-01T19:15:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=95f7112be8daa521e607fb3c231012a6d5eafa96'/>
<id>95f7112be8daa521e607fb3c231012a6d5eafa96</id>
<content type='text'>
This reverts commit 913457acf07be7f22d71ac41ad1076517d7f45c6.

It again broke builds on Windows:

  lldb/source/Host/common/HostNativeThreadBase.cpp(37,14): error:
  assigning to 'lldb::thread_result_t' (aka 'unsigned int') from
  incompatible type 'std::nullptr_t'
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 913457acf07be7f22d71ac41ad1076517d7f45c6.

It again broke builds on Windows:

  lldb/source/Host/common/HostNativeThreadBase.cpp(37,14): error:
  assigning to 'lldb::thread_result_t' (aka 'unsigned int') from
  incompatible type 'std::nullptr_t'
</pre>
</div>
</content>
</entry>
</feed>
