<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/Breakpoint/BreakpointLocationCollection.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] Fix crash in BreakpointSite::BumpHitCounts (#166876)</title>
<updated>2025-11-10T23:35:11+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-11-10T23:35:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=97d50b5c8a7b9269953888d2fcf21e4d4a16dc25'/>
<id>97d50b5c8a7b9269953888d2fcf21e4d4a16dc25</id>
<content type='text'>
Fix crash in `BreakpointSite::BumpHitCounts` due to missing
synchronization. When bumping the hit count, we were correctly acquiring
the constituents mutex, but didn't protect the breakpoint location
collection. This PR fixes the issue by making the iterator returned by
the collection a `LockingAdaptedIterable`.

rdar://163760832</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix crash in `BreakpointSite::BumpHitCounts` due to missing
synchronization. When bumping the hit count, we were correctly acquiring
the constituents mutex, but didn't protect the breakpoint location
collection. This PR fixes the issue by making the iterator returned by
the collection a `LockingAdaptedIterable`.

rdar://163760832</pre>
</div>
</content>
</entry>
<entry>
<title>Fix a potential use-after-free in StopInfoBreakpoint. (#163471)</title>
<updated>2025-10-20T23:46:25+00:00</updated>
<author>
<name>jimingham</name>
<email>jingham@apple.com</email>
</author>
<published>2025-10-20T23:46:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c9124a1b0853899bdd22d267124551ec4d720a23'/>
<id>c9124a1b0853899bdd22d267124551ec4d720a23</id>
<content type='text'>
StopInfoBreakpoint keeps a BreakpointLocationCollection for all the
breakpoint locations at the BreakpointSite that was hit. It is also
lives through the time a given thread is stopped, so there are plenty of
opportunities for one of the owning breakpoints to get deleted.

But BreakpointLocations don't keep their owner Breakpoints alive, so if
the BreakpointLocationCollection can live past when some code gets a
chance to delete an owner breakpoint, and then you ask that location for
some breakpoint information, it will access freed memory.

This wasn't a problem before PR #158128 because the StopInfoBreakpoint
just kept the BreakpointSite that was hit, and when you asked it
questions, it relooked up that list. That was not great, however,
because if you hit breakpoints 5 &amp; 6, deleted 5 and then asked which
breakpoints got hit, you would just get 6. For that and other reasons
that PR changed to storing a BreakpointLocationCollection of the
breakpoints that were hit. That's better from a UI perspective but
caused this potential problem.

I fix it by adding a variant of the BreakpointLocationCollection that
also holds onto a shared pointer to the Breakpoints that own the
locations that were hit, thus keeping them alive till the
StopInfoBreakpoint goes away.

This fixed the ASAN assertion. I also added a test that works harder to
cause trouble by deleting breakpoints during a stop.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
StopInfoBreakpoint keeps a BreakpointLocationCollection for all the
breakpoint locations at the BreakpointSite that was hit. It is also
lives through the time a given thread is stopped, so there are plenty of
opportunities for one of the owning breakpoints to get deleted.

But BreakpointLocations don't keep their owner Breakpoints alive, so if
the BreakpointLocationCollection can live past when some code gets a
chance to delete an owner breakpoint, and then you ask that location for
some breakpoint information, it will access freed memory.

This wasn't a problem before PR #158128 because the StopInfoBreakpoint
just kept the BreakpointSite that was hit, and when you asked it
questions, it relooked up that list. That was not great, however,
because if you hit breakpoints 5 &amp; 6, deleted 5 and then asked which
breakpoints got hit, you would just get 6. For that and other reasons
that PR changed to storing a BreakpointLocationCollection of the
breakpoints that were hit. That's better from a UI perspective but
caused this potential problem.

I fix it by adding a variant of the BreakpointLocationCollection that
also holds onto a shared pointer to the Breakpoints that own the
locations that were hit, thus keeping them alive till the
StopInfoBreakpoint goes away.

This fixed the ASAN assertion. I also added a test that works harder to
cause trouble by deleting breakpoints during a stop.</pre>
</div>
</content>
</entry>
<entry>
<title>Add a scripted way to re-present a stop location (#158128)</title>
<updated>2025-10-09T15:37:21+00:00</updated>
<author>
<name>jimingham</name>
<email>jingham@apple.com</email>
</author>
<published>2025-10-09T15:37:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=36bce68b97316363085ae3681e8dde33a62fc9b1'/>
<id>36bce68b97316363085ae3681e8dde33a62fc9b1</id>
<content type='text'>
This patch adds the notion of "Facade" locations which can be reported
from a ScriptedResolver instead of the actual underlying breakpoint
location for the breakpoint. Also add a "was_hit" method to the scripted
resolver that allows the breakpoint to say which of these "Facade"
locations was hit, and "get_location_description" to provide a
description for the facade locations.

I apologize in advance for the size of the patch. Almost all of what's
here was necessary to (a) make the feature testable and (b) not break
any of the current behavior.

The motivation for this feature is given in the "Providing Facade
Locations" section that I added to the python-reference.rst so I won't
repeat it here.

rdar://152112327</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds the notion of "Facade" locations which can be reported
from a ScriptedResolver instead of the actual underlying breakpoint
location for the breakpoint. Also add a "was_hit" method to the scripted
resolver that allows the breakpoint to say which of these "Facade"
locations was hit, and "get_location_description" to provide a
description for the facade locations.

I apologize in advance for the size of the patch. Almost all of what's
here was necessary to (a) make the feature testable and (b) not break
any of the current behavior.

The motivation for this feature is given in the "Providing Facade
Locations" section that I added to the python-reference.rst so I won't
repeat it here.

rdar://152112327</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Fix trailing whitespace in Breakpoint (NFC)</title>
<updated>2025-07-08T22:38:45+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-07-08T22:35:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d9060794c20e9446f66be7c20d3c9fe57ba6d382'/>
<id>d9060794c20e9446f66be7c20d3c9fe57ba6d382</id>
<content type='text'>
Working in the Breakpoint library is a minefield if you have your editor
configured to trim trailing whitespace. Remove it and format the
affected lines.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Working in the Breakpoint library is a minefield if you have your editor
configured to trim trailing whitespace. Remove it and format the
affected lines.
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Use llvm::find_if (NFC) (#141385)</title>
<updated>2025-05-25T15:21:30+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-05-25T15:21:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ef29a79adf8f3a5b80e0ef10b84de54f7eacefa4'/>
<id>ef29a79adf8f3a5b80e0ef10b84de54f7eacefa4</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Add a repeat command option for "thread backtrace --count N".</title>
<updated>2022-02-14T23:48:06+00:00</updated>
<author>
<name>Jim Ingham</name>
<email>jingham@apple.com</email>
</author>
<published>2022-02-04T23:16:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=635f03fe976e250cc64999663f47716412dfa029'/>
<id>635f03fe976e250cc64999663f47716412dfa029</id>
<content type='text'>
This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent &lt;Return&gt;-s will page you through the stack.

This took a little more effort than just adding the repeat command, since
the GetRepeatCommand API was returning a "const char *".  That meant the command
had to keep the repeat string alive, which is inconvenient.  The original
API returned either a nullptr, or a const char *, so I changed the private API to
return an llvm::Optional&lt;std::string&gt;.  Most of the patch is propagating that change.

Also, there was a little thinko in fetching the repeat command.  We don't
fetch repeat commands for commands that aren't being added to history, which
is in general reasonable.  And we don't add repeat commands to the history -
also reasonable.  But we do want the repeat command to be able to generate
the NEXT repeat command.  So I adjusted the logic in HandleCommand to work
that way.

Differential Revision: https://reviews.llvm.org/D119046
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent &lt;Return&gt;-s will page you through the stack.

This took a little more effort than just adding the repeat command, since
the GetRepeatCommand API was returning a "const char *".  That meant the command
had to keep the repeat string alive, which is inconvenient.  The original
API returned either a nullptr, or a const char *, so I changed the private API to
return an llvm::Optional&lt;std::string&gt;.  Most of the patch is propagating that change.

Also, there was a little thinko in fetching the repeat command.  We don't
fetch repeat commands for commands that aren't being added to history, which
is in general reasonable.  And we don't add repeat commands to the history -
also reasonable.  But we do want the repeat command to be able to generate
the NEXT repeat command.  So I adjusted the logic in HandleCommand to work
that way.

Differential Revision: https://reviews.llvm.org/D119046
</pre>
</div>
</content>
</entry>
<entry>
<title>[Breakpoint] Remove redundant member initialization (NFC)</title>
<updated>2022-02-06T18:54:46+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2022-02-06T18:54:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ee4b6cf5387b1b9eef7f21ae93a868b1aded4b08'/>
<id>ee4b6cf5387b1b9eef7f21ae93a868b1aded4b08</id>
<content type='text'>
Identified with readability-redundant-member-init.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Identified with readability-redundant-member-init.
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Replace default bodies of special member functions with = default;</title>
<updated>2021-07-02T18:31:16+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2021-07-02T18:27:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=fd2433e139f78658e059cf911af8ae735fcda57c'/>
<id>fd2433e139f78658e059cf911af8ae735fcda57c</id>
<content type='text'>
Replace default bodies of special member functions with = default;

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

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

Differential revision: https://reviews.llvm.org/D104041
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Replace default bodies of special member functions with = default;

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

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

Differential revision: https://reviews.llvm.org/D104041
</pre>
</div>
</content>
</entry>
<entry>
<title>Convert functions that were returning BreakpointOption * to BreakpointOption &amp;.</title>
<updated>2021-06-15T21:34:02+00:00</updated>
<author>
<name>Jim Ingham</name>
<email>jingham@apple.com</email>
</author>
<published>2021-06-12T00:00:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cfb96d845a684a5c567823dbe2aa4392937ee979'/>
<id>cfb96d845a684a5c567823dbe2aa4392937ee979</id>
<content type='text'>
This is an NFC cleanup.

Many of the API's that returned BreakpointOptions always returned valid ones.
Internally the BreakpointLocations usually have null BreakpointOptions, since they
use their owner's options until an option is set specifically on the location.
So the original code used pointers &amp; unique_ptr everywhere for consistency.
But that made the code hard to reason about from the outside.

This patch changes the code so that everywhere an API is guaranteed to
return a non-null BreakpointOption, it returns it as a reference to make
that clear.

It also changes the Breakpoint to hold a BreakpointOption
member where it previously had a UP.  Since we were always filling the UP
in the Breakpoint constructor, having the UP wasn't helping anything.

Differential Revision: https://reviews.llvm.org/D104162
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is an NFC cleanup.

Many of the API's that returned BreakpointOptions always returned valid ones.
Internally the BreakpointLocations usually have null BreakpointOptions, since they
use their owner's options until an option is set specifically on the location.
So the original code used pointers &amp; unique_ptr everywhere for consistency.
But that made the code hard to reason about from the outside.

This patch changes the code so that everywhere an API is guaranteed to
return a non-null BreakpointOption, it returns it as a reference to make
that clear.

It also changes the Breakpoint to hold a BreakpointOption
member where it previously had a UP.  Since we were always filling the UP
in the Breakpoint constructor, having the UP wasn't helping anything.

Differential Revision: https://reviews.llvm.org/D104162
</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>
</feed>
