<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/Target/ExecutionContext.cpp, branch main</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] Rework how we pass the execution context to the statusline (#159887)</title>
<updated>2025-09-23T21:18:11+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-09-23T21:18:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d136fbdf8cf626a446cc53345810d3f59b7e433c'/>
<id>d136fbdf8cf626a446cc53345810d3f59b7e433c</id>
<content type='text'>
Currently, we always pass the "selected" execution context to the
statusline. When handling a process or thread event, we can be more
precise, and build an execution context from the event data. This PR
also adopts the new `StoppedExecutionContext` that was recently
introduced.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, we always pass the "selected" execution context to the
statusline. When handling a process or thread event, we can be more
precise, and build an execution context from the event data. This PR
also adopts the new `StoppedExecutionContext` that was recently
introduced.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][NFC] Address follow up comments in ExecutionContext (#153110)</title>
<updated>2025-08-12T00:21:45+00:00</updated>
<author>
<name>Felipe de Azevedo Piovezan</name>
<email>fpiovezan@apple.com</email>
</author>
<published>2025-08-12T00:21:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c4160343741731680359feb2652aa9e4d2376e31'/>
<id>c4160343741731680359feb2652aa9e4d2376e31</id>
<content type='text'>
The PR https://github.com/llvm/llvm-project/pull/152020 got merged by
accident. This commit addresses some follow up review comments.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The PR https://github.com/llvm/llvm-project/pull/152020 got merged by
accident. This commit addresses some follow up review comments.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Guard SBFrame/SBThread methods against running processes (#152020)</title>
<updated>2025-08-11T17:26:57+00:00</updated>
<author>
<name>Felipe de Azevedo Piovezan</name>
<email>fpiovezan@apple.com</email>
</author>
<published>2025-08-11T17:26:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f12e0380be3bd6084ae860090dc027e0281e388e'/>
<id>f12e0380be3bd6084ae860090dc027e0281e388e</id>
<content type='text'>
Prior to this patch, SBFrame/SBThread methods exhibit racy behavior if
called while the process is running, because they do not lock the
`Process::RetRunLock` mutex. If they did, they would fail, correctly
identifying that the process is not running.

Some methods _attempt_ to protect against this with the pattern:

```
ExecutionContext exe_ctx(m_opaque_sp.get(), lock); // this is a different lock
Process *process = exe_ctx.GetProcessPtr();
if (process) {
  Process::StopLocker stop_locker;
  if (stop_locker.TryLock(&amp;process-&gt;GetRunLock()))
        .... do work ...
```

However, this is also racy: the constructor of `ExecutionContext` will
access the frame list, which is something that can only be done once the
process is stopped.

With this patch:

1. The constructor of `ExecutionContext` now expects a `ProcessRunLock`
as an argument. It attempts to lock the run lock, and only fills in
information about frames and threads if the lock can be acquired.
Callers of the constructor are expected to check the lock.
2. All uses of ExecutionContext are adjusted to conform to the above.
3. The SBThread.cpp-defined helper function ResumeNewPlan now expects a
locked ProcessRunLock as _proof_ that the execution is stopped. It will
unlock the mutex prior to resuming the process.

This commit exposes many opportunities for early-returns, but these
would increase the diff of this patch and distract from the important
changes, so we opt not to do it here.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Prior to this patch, SBFrame/SBThread methods exhibit racy behavior if
called while the process is running, because they do not lock the
`Process::RetRunLock` mutex. If they did, they would fail, correctly
identifying that the process is not running.

Some methods _attempt_ to protect against this with the pattern:

```
ExecutionContext exe_ctx(m_opaque_sp.get(), lock); // this is a different lock
Process *process = exe_ctx.GetProcessPtr();
if (process) {
  Process::StopLocker stop_locker;
  if (stop_locker.TryLock(&amp;process-&gt;GetRunLock()))
        .... do work ...
```

However, this is also racy: the constructor of `ExecutionContext` will
access the frame list, which is something that can only be done once the
process is stopped.

With this patch:

1. The constructor of `ExecutionContext` now expects a `ProcessRunLock`
as an argument. It attempts to lock the run lock, and only fills in
information about frames and threads if the lock can be acquired.
Callers of the constructor are expected to check the lock.
2. All uses of ExecutionContext are adjusted to conform to the above.
3. The SBThread.cpp-defined helper function ResumeNewPlan now expects a
locked ProcessRunLock as _proof_ that the execution is stopped. It will
unlock the mutex prior to resuming the process.

This commit exposes many opportunities for early-returns, but these
would increase the diff of this patch and distract from the important
changes, so we opt not to do it here.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][nfc] Use delegating ctor for ExecutionContext (#151987)</title>
<updated>2025-08-04T16:43:21+00:00</updated>
<author>
<name>Felipe de Azevedo Piovezan</name>
<email>fpiovezan@apple.com</email>
</author>
<published>2025-08-04T16:43:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=80bd72b9b0d5d1f8fd54a4ee6f8af80734912d5d'/>
<id>80bd72b9b0d5d1f8fd54a4ee6f8af80734912d5d</id>
<content type='text'>
The ctor that takes a reference to ExecutionContextRef can be
implemented in terms of the ctor that takes a pointer to that object,
removing code duplication.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The ctor that takes a reference to ExecutionContextRef can be
implemented in terms of the ctor that takes a pointer to that object,
removing code duplication.</pre>
</div>
</content>
</entry>
<entry>
<title>Make sure SelectMostRelevantFrame happens only when returning to the user.</title>
<updated>2023-04-21T21:21:25+00:00</updated>
<author>
<name>Jim Ingham</name>
<email>jingham@apple.com</email>
</author>
<published>2023-04-21T20:49:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=076341d1088b0b3e0140178760dc45ac5162cd65'/>
<id>076341d1088b0b3e0140178760dc45ac5162cd65</id>
<content type='text'>
This is a user facing action, it is meant to focus the user's attention on
something other than the 0th frame when you stop somewhere where that's
helpful. For instance, stopping in pthread_kill after an assert will select
the assert frame.

This is not something you want to have happen internally in lldb, both
because internally you really don't want the selected frame changing out
from under you, and because the recognizers can do arbitrary work, and that
can cause deadlocks or other unexpected behavior.

However, it's not something that the current code does
explicitly after a stop has been delivered, it's expected to happen implicitly
as part of stopping. I changing this to call SMRF explicitly after a user
stop, but that got pretty ugly quickly.

So I added a bool to control whether to run this and audited all the current
uses to determine whether we're returning to the user or not.

Differential Revision: https://reviews.llvm.org/D148863
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a user facing action, it is meant to focus the user's attention on
something other than the 0th frame when you stop somewhere where that's
helpful. For instance, stopping in pthread_kill after an assert will select
the assert frame.

This is not something you want to have happen internally in lldb, both
because internally you really don't want the selected frame changing out
from under you, and because the recognizers can do arbitrary work, and that
can cause deadlocks or other unexpected behavior.

However, it's not something that the current code does
explicitly after a stop has been delivered, it's expected to happen implicitly
as part of stopping. I changing this to call SMRF explicitly after a user
stop, but that got pretty ugly quickly.

So I added a bool to control whether to run this and audited all the current
uses to determine whether we're returning to the user or not.

Differential Revision: https://reviews.llvm.org/D148863
</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB</title>
<updated>2022-03-31T20:21:49+00:00</updated>
<author>
<name>Shafik Yaghmour</name>
<email>syaghmour@apple.com</email>
</author>
<published>2022-03-31T20:20:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=24f9a2f53db78df59761f46ceed3bb5e7aa0d331'/>
<id>24f9a2f53db78df59761f46ceed3bb5e7aa0d331</id>
<content type='text'>
Applied modernize-use-equals-default clang-tidy check over LLDB.

This check is already present in the lldb/.clang-tidy config.

Differential Revision: https://reviews.llvm.org/D121844
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Applied modernize-use-equals-default clang-tidy check over LLDB.

This check is already present in the lldb/.clang-tidy config.

Differential Revision: https://reviews.llvm.org/D121844
</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB</title>
<updated>2022-03-14T20:32:03+00:00</updated>
<author>
<name>Shafik Yaghmour</name>
<email>syaghmour@apple.com</email>
</author>
<published>2022-03-14T20:32:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=28c878aeb29a7e7a9ae8f748de6a3c41482b97be'/>
<id>28c878aeb29a7e7a9ae8f748de6a3c41482b97be</id>
<content type='text'>
Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in class member init but
never updated the constructors to reflect that. This check is already present in
the lldb/.clang-tidy config.

Differential Revision: https://reviews.llvm.org/D121481
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in class member init but
never updated the constructors to reflect that. This check is already present in
the lldb/.clang-tidy config.

Differential Revision: https://reviews.llvm.org/D121481
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Use C++11 default member initializers</title>
<updated>2021-06-09T16:43:13+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2021-06-09T16:25:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9494c510af56d9c8593ab69017dcaa232210b235'/>
<id>9494c510af56d9c8593ab69017dcaa232210b235</id>
<content type='text'>
This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy and the modernize-use-default-member-init check.

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix

This is a mass-refactoring patch and this commit will be added to
.git-blame-ignore-revs.

Differential revision: https://reviews.llvm.org/D103483
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy and the modernize-use-default-member-init check.

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix

This is a mass-refactoring patch and this commit will be added to
.git-blame-ignore-revs.

Differential revision: https://reviews.llvm.org/D103483
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][NFC] Fix all formatting errors in .cpp file headers</title>
<updated>2020-01-24T07:52:55+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2020-01-24T07:23:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=808142876c10b52e7ee57cdc6dcf0acc5c97c1b7'/>
<id>808142876c10b52e7ee57cdc6dcf0acc5c97c1b7</id>
<content type='text'>
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258
</pre>
</div>
</content>
</entry>
<entry>
<title>[ExecutionContext] Return the target/process byte order.</title>
<updated>2019-08-07T16:09:35+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2019-08-07T16:09:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=af0c828a1ef2a85e8e98d97e8f72d985ed08fe6f'/>
<id>af0c828a1ef2a85e8e98d97e8f72d985ed08fe6f</id>
<content type='text'>
Currently ExecutionContext::GetByteOrder() always returns the host byte
order. This seems like a simple mistake: the return keyword appears to
have been omitted by accident. This patch fixes that and adds a unit
test.

Bugreport: https://llvm.org/PR37950

Differential revision: https://reviews.llvm.org/D48704

llvm-svn: 368181
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently ExecutionContext::GetByteOrder() always returns the host byte
order. This seems like a simple mistake: the return keyword appears to
have been omitted by accident. This patch fixes that and adds a unit
test.

Bugreport: https://llvm.org/PR37950

Differential revision: https://reviews.llvm.org/D48704

llvm-svn: 368181
</pre>
</div>
</content>
</entry>
</feed>
