Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search


Note: The contents of this page is obsolete, but it may still contain some interesting tid-bits.

This a page for discussing content of the CDT/designs/MultiCoreDebug page. See Wikipedia Talk Page Guidelines for guidelines on editing this page.

Multi-context debugging: Restart

Hi All, Shortly before and at EclipseCon I received a lot of questions about the effort to improve the multi-context debugging experience in Eclipse. If I had the time, I explained what the current situation of this DD sub-group is:

  1. About a year and a half ago, I prototyped an enhancement to the platform debugger views to allow the user to create multiple instances of views and to pin them to the active context (see bug 145635).
  2. At the meeting in Toronto in January '07 I demonstrated my prototype and we had a lively discussion about its benefits and short comings.
  3. We decided that the bug 145635 prototype was too radical as a workflow change to introduce in Platform without considerable discussion. It also was not a complete solution to the multi-context workflow problem and there were some implementations issues with it.
  4. I promised to write up a proper proposal for the pin and clone workflow changes in 3.4 time frame which could be properly evaluated and potentially contributed to platform Debug.
  5. As I considered the multi-context workflow issue, I realized that there are a lot of issues to consider and I tried to write a proposal that would try to address these issues (in two parts). I wrote the first part of the proposal and posted it to wiki.
  6. I received a lot of excellent feedback on the first document, and it quickly became clear that I tried to cut too many corners in writing the proposal because I omitted use cases, mixed functional description with design and didn't have enough content.
  7. I never got to writing the second part of the proposal as my commitments for DSF and Wind River commercial work took priority. I put the effort on hold until after ganymede release effort is under control.

This brings us to this point in time, where the multi-context effort is stalled, but I get the sense that there is a lot of demand to re-start this discussion. I personally don't have a lot of time to allocate to this effort at the moment, and I think I need to have a clear idea of what changes features are needed before I ask my management for time to work on it. Therefore, I would like to re-start the multi-context group in the way that I should have started it in the first place. As a community that has a vested interest in this problem we need to

  1. Define the use cases, and identify the use cases which are most important.
  2. Identify the problems with executing the use cases.
  3. Come up with ideas to fix the problems and improve the multi-context debugging user experiecene.

In the past discussions about multi-context debugging, we used a combination of wiki and the mailing list. This was somewhat confusing and required some cut-and-paste action just to make sure that the edits were seen. To avoid this, I would like to use the Wiki page as the center of this discussion. To facilitate this I ask that anyone that wishes to participate in this discussion add this page to their wiki watch list and configure your wiki preferences to email yourself when the watchlist is updated. This should hopefully minimize the need to use the mailing list just to tell everyone that the wiki page was updated. The last section on the page is a "Comments" section, however I hope that we can produce this document as a community and I hope that everyone that wishes to participate in it will just edit the document directly.

I started on this process tonight by adding some general use cases for multi-threaded debugging. As I have time I will contribute more content, but I hope to see others contribute to it as well. I also welcome any feedback and suggestions as far as this process itself.

- 18:54, 3 April 2008 (EDT)

Debugging Without the Debug View

I think debugging without the debug view is interesting outside the discussion of multi-context debugging. The same user interface for context switching, showing a debug toolbar, etc., should apply to "single context" debugging as well as "multi-context debugging". - Darin Wright, June 24th, 2008

I agree that this is an important workflow to consider even without multiple contexts. Although I think that multiple contexts make it more relevant because screen space becomes even more precious. 16:53, 24 June 2008 (EDT)

I was wondering if we might want to use hover as a way to create a debug toolbar. For example, when you stop at a breakoint and there is no debug view, hovering over the current instruction could show a debug toolbar with an action to add the debug actions to the top level toolbar. It might also be interesting to have a floating debug toolbar such that it does not take up more top level toolbar space (and is only visible when debugging). However, I'm not sure the workbench currently supports floating toolbars. - Darin Wright, June 24th, 2008

A toolbar hover would be an interesting thing to prototype, but I don't think we can get away without giving the user some way to add these buttons to the top level toolbar. I completely agree though that the toolbar space is an issue and I hope that the Eclipse community in general would welcome additional user controls over what buttons are shown there. 16:54, 24 June 2008 (EDT)

When debugging without the debug view, I think one will often be in a non-debug perspective (for example, just in the Java perspective). This will drive the need for a lightweight method of displaying variables. - Darin Wright, June 24th, 2008

Yes! I also think that the debugger somehow needs to become more editor-centric. The editor is where I want to spend most of my time, whether when writing code, merging patches, or debugging. I just don't know how to do this. As a JDT user, I don't find the hover or the inspect action very useful... so I think we'd need to invent something new here. 16:54, 24 June 2008 (EDT)

Use cases

Synchronized operations on multiple cores

This use case is worth to be mentioned because, alongside with the usual multi-context requirements, an additional infrastructure and a special UI support are required. 11:45, 23 June 2008 (EDT)

Thanks Mikhail, I added this to the list of use cases as use case 3.4. 16:38, 24 June 2008 (EDT)

Problems with workflow

Breakpoints in the multi-context environment

Currently there is no way to distinguish whether a breakpoint belongs to the active context or not if there is more than one running debug sessions. It will be even more problematic to do it in the multi-context environment. 11:45, 23 June 2008 (EDT)

I added this as well as item "D.d" in the Problems section.


Hi Pawel. Some of these proposals are for features highly desired here. Could you tell me the status of this project? Is there a time frame? Are there any prototypes of these proposals? 09:23, 17 July 2008 (EDT)

Launching a multi-context debug session

With RSE, there is a list of processes running. It would be nice to be able to have a multi-selection of Processes and be able to right-click Debug As... to trigger a debug session for all these processes.

Back to the top