Skip to content

🍒 [lldb] Patches implementing MultiBreakpoint #12930

Open
felipepiovezan wants to merge 16 commits intoswiftlang:stable/21.xfrom
felipepiovezan:felipe/cherry_pick_multibreak
Open

🍒 [lldb] Patches implementing MultiBreakpoint #12930
felipepiovezan wants to merge 16 commits intoswiftlang:stable/21.xfrom
felipepiovezan:felipe/cherry_pick_multibreak

Conversation

@felipepiovezan
Copy link
Copy Markdown

@felipepiovezan felipepiovezan commented May 8, 2026

These all cherry-picks from upstream

…#187462)

This will allow us to more conveniently use llvm::formatv in the
codebase.

(cherry picked from commit 4df2967)
…ss (llvm#190762)

This allows the callsite to be simplified.
This also exposes a bug where the variable `ShouldShowError` is guarding
more than the error printing.

(cherry picked from commit 30a99ce)
…vm#191136)

Re-using this code will be important in an upcoming patch.

This commit also greatly simplifies the comments in the function.

(cherry picked from commit 2f2bd5e)
This describes the packet discussed in the RFC:
https://discourse.llvm.org/t/rfc-a-new-packet-to-set-remove-multiple-breakpoints/90623

The following PRs are related:

* [[lldb] Propose MultiBreakpoint extension to GDB
Remote](llvm#192910)
* [[debugserver] Implement
MultiBreakpoint](llvm#192914)
* [[lldb-server][NFC] Factor out code handling breakpoint
packets](llvm#192915)
* [[lldb-server] Implement support for MultiBreakpoint
packet](llvm#192919)
* [[lldb][GDBRemote] Parse MultiBreakpoint+
capability](llvm#192962)
* [[lldb][NFC] Move BreakpointSite::IsEnabled/SetEnabled into
Process](llvm#192964)
* [[lldb] Implement delayed
breakpoints](llvm#192971)
* [[lldb] Override UpdateBreakpointSites in ProcessGDBRemote to use
MultiBreakpoint](llvm#192988)

(cherry picked from commit 5c73c7a)
This is causing bot failures.

(cherry picked from commit 74781cf)
The following PRs are related to the MultiBreakpoint feature:

* llvm#192910
* llvm#192914
* llvm#192915
* llvm#192919
* llvm#192962
* llvm#192964
* llvm#192971
* llvm#192988

(cherry picked from commit 1ef7d35)
…lvm#192964)

The Process class is the one responsible for managing the state of a
BreakpointSite inside the process. As such, it should be the one
answering questions about the state of the site.

Future patches will make this even more important by introducing a
"logical" is enabled, by delaying the moment in which breakpoints are
actually updated in the process.

The following PRs are related to the MultiBreakpoint feature:

* llvm#192910
* llvm#192914
* llvm#192915
* llvm#192919
* llvm#192962
* llvm#192964
* llvm#192971
* llvm#192988

(cherry picked from commit 3e8fbb2)
This patch changes the Process class so that it delays *physically*
enabling/disabling breakpoints until the process is about to
resume/detach/be destroyed, potentially reducing the packets transmitted
by batching all breakpoints together.

Most classes only need to know whether a breakpoint is "logically"
enabled, as opposed to "physically" enabled (i.e. the remote server has
actually enabled the breakpoint). However, lower level classes like
derived Process classes, or StopInfo may actually need to know whether
the breakpoint was physically enabled. As such, this commit also adds a
"IsPhysicallyEnabled" API.

The following PRs are related to the MultiBreakpoint feature:

* llvm#192910
* llvm#192914
* llvm#192915
* llvm#192919
* llvm#192962
* llvm#192964
* llvm#192971
* llvm#192988

(cherry picked from commit 776ee6f)
Tests started failing on a mysterious way there, potentially related to:
llvm#191222

(cherry picked from commit f5eb7a9)
This removes some duplicated code, and also helps future tests. It's
also surprisingly not easy to write these, as there are a few footguns.

(cherry picked from commit 3cad5df)
…5815)

See the discussion in llvm#192971

When LLDB makes the decision to eagerly send a breakpoint packet, it
should first ensure the delayed breakpoints are flushed, as they may
interfere with the eager breakpoint that is about to be changed.

Implementation note: we could have included the eager breakpoint in the
    batch that is about to be flushed. However, it's important to get
    information about the error status of this eager breakpoint, and the
current APIs dont make it easy to distinguish which breakpoint caused an
    error.

(cherry picked from commit 11d15c3)
…92915)

This commit extracts the code handling breakpoint packets into a helper
function that can be used by a future implementation of the
MultiBreakpointPacket.

It is meant to be purely NFC.

There are two functions handling breakpoint packets (`handle_Z` and
`handle_z`) with a lot of repeated code. This commit did not attempt to
merge the two, as that would make the diff much larger due to subtle
differences in the error message produced by the two. The only
deduplication done is in the code processing a GDBStoppointType, where a
helper struct (`BreakpointKind`) and function
(`std::optional<BreakpointKind> getBreakpointKind(GDBStoppointType
stoppoint_type)`) was created.

The following PRs are related to the MultiBreakpoint feature:

* llvm#192910
* llvm#192914
* llvm#192915
* llvm#192919
* llvm#192962
* llvm#192964
* llvm#192971
* llvm#192988

(cherry picked from commit c2ab7f2)
Some old compilers complained about the `static_assert(false)` pattern.

Fixes https://lab.llvm.org/buildbot/#/builders/163/builds/39139

(cherry picked from commit 4974ae5)
This is fairly straightforward, thanks to the helper functions created
in the previous commit.

The following PRs are related to the MultiBreakpoint feature:

* llvm#192910
* llvm#192914
* llvm#192915
* llvm#192919
* llvm#192962
* llvm#192964
* llvm#192971
* llvm#192988

(cherry picked from commit e33bac0)
…iBreakpoint (llvm#192988)

This concludes the implementation of MultiBreakpoint by actually using
the new packet to batch breakpoint requests.

The following PRs are related to the MultiBreakpoint feature:

* llvm#192910
* llvm#192914
* llvm#192915
* llvm#192919
* llvm#192962
* llvm#192964
* llvm#192971
* llvm#192988
@felipepiovezan felipepiovezan requested a review from a team as a code owner May 8, 2026 15:09
@felipepiovezan
Copy link
Copy Markdown
Author

@swift-ci test

@felipepiovezan felipepiovezan force-pushed the felipe/cherry_pick_multibreak branch from 58265b0 to 59dbe33 Compare May 8, 2026 16:29
@felipepiovezan
Copy link
Copy Markdown
Author

@swift-ci test

@felipepiovezan
Copy link
Copy Markdown
Author

[2026-05-08T18:37:58.122Z] AssertionError: False is not true : Command 'platform process list' did not return successfully
[2026-05-08T18:37:58.122Z] Error output:
[2026-05-08T18:37:58.122Z] error: no processes were found on the "ios-simulator" platform
[2026-05-08T18:37:05.078Z]     self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
[2026-05-08T18:37:05.078Z] AssertionError: 'could not find a process named test_with_attach_to_process_with_name_api_71968' is not success

@felipepiovezan
Copy link
Copy Markdown
Author

@swift-ci test macos platform

@felipepiovezan felipepiovezan changed the title 🍒 [lldb] Patches implementing MultiBreakpoint with default = OFF 🍒 [lldb] Patches implementing MultiBreakpoint May 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant