Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-cloud-dev] Ongoing Initiative on Hardware Breakpoints in VS Code and Eclipse Theia
Hi everyone,

Thank you very much, Mark, for sharing your input on the discussion on extending the DAP for hardware breakpoints! This really got the ball rolling.

We've received some very constructive feedback and I'm wondering whether you have any further requirements worth raising at this point (anyone in this group). So please make sure you raise your additional requirements or concerns on the Github discussion, or mention that you're ok with what has been identified as missing in the DAP

Currently, the suggestion is to
  • Rely on the message that the DA can specify for unverified breakpoints to communicate that the limit of hardware breakpoints is succeeded. This seems OK to me, we can add additional view sections / views to show more detail on the overall availability, if necessary.
  • Potentially add a property allowing users to force a certain type of breakpoint (hardware or software). Would that be sufficient for normal source breakpoints, or would we also need that for Data and Instruction Breakpoints? I guess we also need a dedicated property in type Breakpoint to communicate from the DA back which type of breakpoint was actually set.
  • Potentially add properties in the DataBreakpoint to allow specifying an "address range", "size" and "bus master".
Please let me know what you think or add your thoughts on the Github discussion.

Thanks and best wishes,

Philip


On Wed, Nov 22, 2023 at 5:55 PM Philip Langer <planger@xxxxxxxxxxxxxxxxx> wrote:
Hi everyone,

As a result of the ongoing discussions on our proposal for HW breakpoints in the DAP [1], the maintainers of the protocol have expressed interest in enhancing support for embedded development in DAP and DAP-supporting clients. To move forward, they're seeking concrete examples / scenarios from a user perspective to better understand what is missing in DAP and evaluate how the protocol should be extended without introducing an 'unbounded' configuration scheme.

I'm happy to help gather and process those examples, but your expertise in embedded development is invaluable in this context. So I'm looking for concrete examples that highlight the specifics of hardware breakpoint configuration. Think about the typical configuration properties and hardware-specific properties. Would you be able to provide sketches of such example configurations for your companies' hardware or screenshots with configurations from your companies' current tooling, etc.?
If you have examples or insights that could help shape our proposal, please share them (here, with me directly, or chime in on Github [1], as you prefer).

Your contributions will not only strengthen our case but also ensure the protocol extension meets the needs of our community!

Looking forward to your responses and thank you in advance!

Best wishes,

On Fri, Nov 17, 2023 at 3:17 PM Philip Langer <planger@xxxxxxxxxxxxxxxxx> wrote:
Hi everyone,

Thank you for your valuable feedback on the proposal for HW breakpoint support in the DAP!

We've consolidated the feedback and got approval from all contributors to open an issue in the DAP Github repo.

If you are interested in this DAP extension, please show your support by upvoting this Github issue and feel free to chime in for the discussion on Github!

Thank you and best wishes,

Philip


On Sun, Oct 29, 2023 at 9:28 PM Philip Langer <planger@xxxxxxxxxxxxxxxxx> wrote:
Based on Asim's summary, I've created a proposal for the Github issue [1] to be opened in the DAP spec repo [2].

Please let me know what you think and feel free to edit! I'm happy to give you edit rights, if you send me your Google account.
If you are OK with the proposal, please just add a comment with +1 on the Google doc, so I know when we have the critical mass to open the issue.

Thanks and best wishes,

Philip



On Sun, Oct 29, 2023 at 9:19 PM Philip Langer <planger@xxxxxxxxxxxxxxxxx> wrote:
Hi all,

As mentioned in our last CDT Cloud meeting [1], we're diving into an exciting initiative with the goal of enabling support for hardware breakpoints and custom breakpoint data! Our plans include opening a GitHub issue to extend the Debug Adapter Protocol, paving the way for support in both VS Code and Eclipse Theia.

Asim (Gunes) has been kind enough to draft a more detailed summary of the discussions we had over the last few weeks on this topic. Check out the summary [2] for more details.

We'd love to hear your thoughts, so if you're interested in this topic, let's keep the conversation going on this mailing list and also feel free to comment directly in the document linked above. We'll be sending updates in this thread.

Best wishes,

Philip

[2] https://docs.google.com/document/d/12s0wCOU_hZ1IOltfRyBAPYCsXdPq_UT7vGN_uMuvhGw/edit

--
Dr. Philip Langer

CEO | Principal Software Architect
EclipseSource


EclipseSource Services GmbH
Schwindgasse 20 / 2-3
1040 Wien

General Manager: Dr. Philip Langer
Registered Office: Schwindgasse 20 / 2-3, 1040 Wien; Handelsgericht Wien, FN 421413a


Back to the top