[lldb] Propose MultiBreakpoint extension to GDB Remote by felipepiovezan · Pull Request #192910 · llvm/llvm-project

felipepiovezan · 2026-04-20T08:12:12Z

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:

llvmbot · 2026-04-20T08:12:43Z

@llvm/pr-subscribers-lldb

Author: Felipe de Azevedo Piovezan (felipepiovezan)

Changes

This describes the packet discussed in the RFC ...link soon...

Full diff: https://github.com/llvm/llvm-project/pull/192910.diff

1 Files Affected:

(modified) lldb/docs/resources/lldbgdbremote.md (+46)

diff --git a/lldb/docs/resources/lldbgdbremote.md b/lldb/docs/resources/lldbgdbremote.md
index 9aa7ad2259a6a..2fa1c39af317f 100644
--- a/lldb/docs/resources/lldbgdbremote.md
+++ b/lldb/docs/resources/lldbgdbremote.md
@@ -738,6 +738,52 @@ This is a performance optimization, which speeds up debugging by avoiding
 multiple round-trips for retrieving thread information. The information from this
 packet can be retrieved using a combination of `qThreadStopInfo` and `m` packets.
 
+## MultiBreakpoint
+
+This packet allows setting and removing multiple breakpoints in one go. It
+concatenates multiple `Z` and `z` packets, separating them with a `;`.
+Formally:
+
+```
+$MultiBreakpoint:breakpoint_request[;breakpoint_request]*
+```
+
+Where each `breakpoint_request` is one of:
+
+```
+* z0,addr,kind
+* z1,addr,kind
+* z2,addr,kind
+* z3,addr,kind
+* z4,addr,kind
+* Z0,addr,kind[;cond_list…][;cmds:persist,cmd_list…]
+* Z1,addr,kind[;cond_list…][;cmds:persist,cmd_list…]
+* Z2,addr,kind
+* Z3,addr,kind
+* Z4,addr,kind
+```
+
+Each field has the same meaning as the corresponding packet in the GDB Remote
+Protocol.
+
+Note: there is no ambiguity in using `;` as a separator between
+`breakpoint_request`s. According to the GDB Remote Protocol specification, both
+`cond_list` and `cmd_list` start with an `X` character and contain no
+separators; it follows that a ";z" or ";Z" always indicate the start of a new
+request.
+
+The stub must execute the sequence of `breakpoint_request`s in the order they
+appear in the `MultiBreakpoint` packet. This is not an atomic operation:
+individual requests may fail, and the stub must process subsequent requests
+upon failure.
+
+The reply consists of a `;`-separated sequence of `OK`s or `E` strings, one per
+`breakpoint_request`, representing whether the `breakpoint_request` was
+successful.
+
+A stub that supports this packet must include `MultiBreakpoint+` in the reply
+to `qSupported`.
+
 ### MultiMemRead
 
 Read memory from multiple memory ranges.

This implements the packet as described in #192910

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. #192910

This is fairly straightfoward, thanks to the helper functions created in the previous commit. #192910

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. #192910

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. #192910

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

This implements the packet as described in #192910

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. #192910

This is fairly straightforward, thanks to the helper functions created in the previous commit. #192910

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. #192910

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. #192910

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

This is fairly straightforward, thanks to the helper functions created in the previous commit. #192910

DavidSpickett

LGTM

DavidSpickett · 2026-04-24T13:35:46Z

@@ -618,6 +618,50 @@ running, then an error message is returned.
 do live tracing. Specifically, the name of the plug-in should match the name
 of the tracing technology returned by this packet.

+## jMultiBreakpoint
+
+This packet allows setting and removing multiple breakpoints in one go. It


Can you confirm that mixing z and Z is allowed? Based on this text I think it is, which is good.

Probably somewhere where we "move" a breakpoint and that could be done in one go in theory.

I added the following, since we were missing an example:

For example, the packet below is a request to set one breakpoint and to remove two others: $jMultiBreakpoint: {"breakpoint_requests": ["Z0,1025783e8,4", "z0,1025783ec,4", "z0,1025783e8,4"]} The same address may be specified multiple times.

DavidSpickett · 2026-04-24T13:37:08Z

@@ -618,6 +618,50 @@ running, then an error message is returned.
 do live tracing. Specifically, the name of the plug-in should match the name
 of the tracing technology returned by this packet.

+## jMultiBreakpoint
+


Considering this is being added specifically for performance, I'd like a "priority to implement" section like the other packets.

At least it means if you ctrl-f for "performance" you'll find this and all the other nice to haves.

felipepiovezan · 2026-04-25T08:43:56Z

I've addressed all the feedback and will merge. Happy to tweak anything else in follow-up PRs.

This implements the packet as described in #192910

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. #192910

…92910) 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/llvm-project#192910) * [[debugserver] Implement MultiBreakpoint](llvm/llvm-project#192914) * [[lldb-server][NFC] Factor out code handling breakpoint packets](llvm/llvm-project#192915) * [[lldb-server] Implement support for MultiBreakpoint packet](llvm/llvm-project#192919) * [[lldb][GDBRemote] Parse MultiBreakpoint+ capability](llvm/llvm-project#192962) * [[lldb][NFC] Move BreakpointSite::IsEnabled/SetEnabled into Process](llvm/llvm-project#192964) * [[lldb] Implement delayed breakpoints](llvm/llvm-project#192971) * [[lldb] Override UpdateBreakpointSites in ProcessGDBRemote to use MultiBreakpoint](llvm/llvm-project#192988)

This is fairly straightforward, thanks to the helper functions created in the previous commit. #192910

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. #192910

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. #192910

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

This is fairly straightforward, thanks to the helper functions created in the previous commit. #192910

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. #192910

This implements the packet as described in llvm#192910 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

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. #192910

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: * #192910 * #192914 * #192915 * #192919 * #192962 * #192964 * #192971 * #192988

This is fairly straightforward, thanks to the helper functions created in the previous commit. #192910

This implements the packet as described in llvm/llvm-project#192910 The following PRs are related to the MultiBreakpoint feature: * llvm/llvm-project#192910 * llvm/llvm-project#192914 * llvm/llvm-project#192915 * llvm/llvm-project#192919 * llvm/llvm-project#192962 * llvm/llvm-project#192964 * llvm/llvm-project#192971 * llvm/llvm-project#192988

…ets (#192915) 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/llvm-project#192910 * llvm/llvm-project#192914 * llvm/llvm-project#192915 * llvm/llvm-project#192919 * llvm/llvm-project#192962 * llvm/llvm-project#192964 * llvm/llvm-project#192971 * llvm/llvm-project#192988

This implements the packet as described in llvm/llvm-project#192910 The following PRs are related to the MultiBreakpoint feature: * llvm/llvm-project#192910 * llvm/llvm-project#192914 * llvm/llvm-project#192915 * llvm/llvm-project#192919 * llvm/llvm-project#192962 * llvm/llvm-project#192964 * llvm/llvm-project#192971 * llvm/llvm-project#192988

…ets (#192915) 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/llvm-project#192910 * llvm/llvm-project#192914 * llvm/llvm-project#192915 * llvm/llvm-project#192919 * llvm/llvm-project#192962 * llvm/llvm-project#192964 * llvm/llvm-project#192971 * llvm/llvm-project#192988

This is fairly straightforward, thanks to the helper functions created in the previous commit. #192910

This is fairly straightforward, thanks to the helper functions created in the previous commit. The following PRs are related to the MultiBreakpoint feature: * #192910 * #192914 * #192915 * #192919 * #192962 * #192964 * #192971 * #192988

This implements the packet as described in llvm/llvm-project#192910 The following PRs are related to the MultiBreakpoint feature: * llvm/llvm-project#192910 * llvm/llvm-project#192914 * llvm/llvm-project#192915 * llvm/llvm-project#192919 * llvm/llvm-project#192962 * llvm/llvm-project#192964 * llvm/llvm-project#192971 * llvm/llvm-project#192988

…ets (#192915) 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/llvm-project#192910 * llvm/llvm-project#192914 * llvm/llvm-project#192915 * llvm/llvm-project#192919 * llvm/llvm-project#192962 * llvm/llvm-project#192964 * llvm/llvm-project#192971 * llvm/llvm-project#192988

felipepiovezan requested a review from JDevlieghere as a code owner April 20, 2026 08:12

llvmbot added the lldb label Apr 20, 2026

felipepiovezan added a commit that referenced this pull request Apr 20, 2026

[debugserver] Implement MultiBreakpoint

aca05b0

This implements the packet as described in #192910

felipepiovezan mentioned this pull request Apr 20, 2026

[debugserver] Implement MultiBreakpoint #192914

Merged

felipepiovezan mentioned this pull request Apr 20, 2026

[lldbremote][NFC] Factor out code handling breakpoint packets #192915

Merged

felipepiovezan added a commit that referenced this pull request Apr 20, 2026

[lldbserver] Implement support for MultiBreakpoint packet

6bf0eda

This is fairly straightfoward, thanks to the helper functions created in the previous commit. #192910

felipepiovezan mentioned this pull request Apr 20, 2026

[lldbremote] Implement support for MultiBreakpoint packet #192919

Merged

felipepiovezan added a commit that referenced this pull request Apr 20, 2026

[lldbremote] Implement support for MultiBreakpoint packet

8265e86

This is fairly straightfoward, thanks to the helper functions created in the previous commit. #192910

felipepiovezan mentioned this pull request Apr 20, 2026

[lldb][NFC] Move BreakpointSite::IsEnabled/SetEnabled into Process #192964

Merged

felipepiovezan mentioned this pull request Apr 20, 2026

[lldb][GDBRemote] Parse MultiBreakpoint+ capability #192962

Merged

felipepiovezan mentioned this pull request Apr 20, 2026

[lldb] Implement delayed breakpoints #192971

Merged

felipepiovezan mentioned this pull request Apr 20, 2026

[lldb] Override UpdateBreakpointSites in ProcessGDBRemote to use MultiBreakpoint #192988

Merged

felipepiovezan added a commit that referenced this pull request Apr 22, 2026

[debugserver] Implement MultiBreakpoint

50428a7

This implements the packet as described in #192910

felipepiovezan added a commit that referenced this pull request Apr 22, 2026

[debugserver] Implement MultiBreakpoint

0c5d9b6

This implements the packet as described in #192910

felipepiovezan added a commit that referenced this pull request Apr 22, 2026

[lldb-server] Implement support for MultiBreakpoint packet

a490b93

This is fairly straightforward, thanks to the helper functions created in the previous commit. #192910

felipepiovezan force-pushed the felipe/multibreakpoint_docs branch from 9794553 to 83d8649 Compare April 22, 2026 14:31

felipepiovezan added a commit that referenced this pull request Apr 24, 2026

[lldb-server] Implement support for MultiBreakpoint packet

738715a

This is fairly straightforward, thanks to the helper functions created in the previous commit. #192910

DavidSpickett approved these changes Apr 24, 2026

View reviewed changes

fixup! address review feedback

6639bfa

felipepiovezan enabled auto-merge (squash) April 25, 2026 08:45

felipepiovezan merged commit 5c73c7a into llvm:main Apr 25, 2026
11 checks passed

felipepiovezan added a commit that referenced this pull request Apr 25, 2026

[debugserver] Implement MultiBreakpoint

012f32b

This implements the packet as described in #192910

felipepiovezan added a commit that referenced this pull request Apr 25, 2026

[lldb-server] Implement support for MultiBreakpoint packet

87051f3

This is fairly straightforward, thanks to the helper functions created in the previous commit. #192910

felipepiovezan added a commit that referenced this pull request Apr 27, 2026

[lldb-server] Implement support for MultiBreakpoint packet

df05297

This is fairly straightforward, thanks to the helper functions created in the previous commit. #192910

felipepiovezan added a commit that referenced this pull request Apr 27, 2026

[lldb-server] Implement support for MultiBreakpoint packet

24076e7

This is fairly straightforward, thanks to the helper functions created in the previous commit. #192910

felipepiovezan added a commit that referenced this pull request Apr 27, 2026

[lldb-server] Implement support for MultiBreakpoint packet

6cbbea7

This is fairly straightforward, thanks to the helper functions created in the previous commit. #192910

felipepiovezan added a commit that referenced this pull request Apr 27, 2026

[lldb-server] Implement support for MultiBreakpoint packet

42704d2

This is fairly straightforward, thanks to the helper functions created in the previous commit. #192910

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[lldb] Propose MultiBreakpoint extension to GDB Remote#192910

[lldb] Propose MultiBreakpoint extension to GDB Remote#192910
felipepiovezan merged 2 commits into
llvm:mainfrom
felipepiovezan:felipe/multibreakpoint_docs

felipepiovezan commented Apr 20, 2026 •

edited

Loading

Uh oh!

llvmbot commented Apr 20, 2026

Uh oh!

DavidSpickett left a comment

Uh oh!

DavidSpickett Apr 24, 2026

Uh oh!

felipepiovezan Apr 25, 2026

Uh oh!

DavidSpickett Apr 24, 2026

Uh oh!

felipepiovezan commented Apr 25, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

felipepiovezan commented Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

llvmbot commented Apr 20, 2026

Uh oh!

DavidSpickett left a comment

Choose a reason for hiding this comment

Uh oh!

DavidSpickett Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

felipepiovezan Apr 25, 2026

Choose a reason for hiding this comment

Uh oh!

DavidSpickett Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

felipepiovezan commented Apr 25, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

felipepiovezan commented Apr 20, 2026 •

edited

Loading