[Dexter] Add DAP instruction and function breakpoint handling

[OCHyams]

No description provided.

[OCHyams]

• [Dexter] Implement DexStepFunction and DexContinue #152721
• [Dexter] Add DexStepFunction and DexContinue skeletons #152720
• [Dexter] add get_pc #152719
• [Dexter] Add DAP instruction and function breakpoint handling #152718 👈 (View in Graphite)
• [Dexter] Add DAP stepNext and stepOut support #152717
• [Dexter][NFC] Rename step -> step_in #152716
• [Dexter] Track DAP capabilities #152715
• [Dexter] Add DAP support for Dexter, including lldb-dap #152714
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

⚠️ Python code formatter, darker found issues in your code. ⚠️

You can test this locally with the following command:

darker --check --diff -r HEAD~1...HEAD cross-project-tests/debuginfo-tests/dexter/dex/debugger/DAP.py cross-project-tests/debuginfo-tests/dexter/dex/debugger/DebuggerBase.py cross-project-tests/debuginfo-tests/dexter/dex/debugger/lldb/LLDB.py

View the diff from darker here.

--- DAP.py	2025-08-12 16:31:17.000000 +0000
+++ DAP.py	2025-08-12 16:33:31.603482 +0000
@@ -613,13 +613,11 @@
         self.file_to_bp[file].append(new_id)
         self.bp_info[new_id] = (file, line, condition)
         self.pending_breakpoints = True
         return new_id
 
-    def _update_breakpoint_ids_after_request(
-        self, dex_bp_ids: list, response: dict
-    ):
+    def _update_breakpoint_ids_after_request(self, dex_bp_ids: list, response: dict):
         dap_bp_ids = [bp["id"] for bp in response["body"]["breakpoints"]]
         if len(dex_bp_ids) != len(dap_bp_ids):
             self.context.logger.error(
                 f"Sent request to set {len(dex_bp_ids)} breakpoints, but received {len(dap_bp_ids)} in response."
             )

[SLTozer]

Technically the specification only explicitly says "The breakpoints returned are in the same order as the elements of the breakpoints (or the deprecated lines) array in the arguments." for source breakpoints*. However, I'd be very surprised if any debugger chose to do it differently, given that the response is not guaranteed to contain sufficient information to otherwise map the requested breakpoints to the received breakpoints - it would effectively be a useless feature otherwise.

*Function and instruction breakpoints have the wording "The [response] array elements correspond to the elements of the breakpoints array.", which I take to mean that the ordering should be the same, but it's not as explicit as the source breakpoints case.

[OCHyams]

Ah cool, thanks for the info. I've updated the comments to be more certain

[walter-erquinigo]

This LGTM overall. I'll let @SLTozer do the final approval