CDT/Obsolete/MultiCoreDebugWorkingGroup/calls/minutes/2010

2010 Multicore Debug Workgroup Minutes of Meetings

December 14, 2010

Attendees

1. Mikhail Khodjaiants (CodeSourcery)
2. Stan Shebs (CodeSourcery)
3. John Cortell (Freescale)
4. Chris Recoskie (IBM)
5. Aaron Spear (Mentor Graphics)
6. Ken Ryall (Nokia)
7. Shaiju (Tensilica)
8. Dobrin Alexiev (TI)
9. Patrick Chuong (TI)
10. Bill Swanson (Tilera)
11. Pawel Piech (Windriver)
12. Doug Schaefer (Windriver)
13. Onur Akdemir
14. Marc Khouzam (Ericsson)
15. Dominique Toupin (Ericsson)

Minutes

What about the Multi-core association working group?

• Chaired by Aaron Spear from Mentor
• Current focus is on Tracing
• Interest in Debug as well but wider than Eclipse
• Good for such things as protocols, synchronization between different debuggers, etc

Things for Indigo

• Pin & Clone (Patrick)
• Grouping & Hiding & Commands on containers (Dobrin)
• Multi-process (Marc)
• Start of Visualizer view effort (Bill, Marc, group)

Visualizer view

• Need to start to discuss what this view should do to make sure it addresses what we need.
• Bill will start a wiki to put up ideas and suggestions, like the kind of environment, the types of visualization
• Marc to open bugzilla for visualizer view discussion
• We will need a good framework to provide a way to do the visualization
• Visualizer view will need to handle multiple targets/launches. It should switch the type of display as the user chooses a different launch.
• Sub tasks
  • We may need to move the run control buttons to the main toolbar to be able to have different views use them. Or should we have them in each of the driving views? Do we need a bug to track this? Patrick can prototype this.
  • Need to have platform support the concept of the Debug View set its selection based on another view that is a debug context provider. Need some service to translate the debug context of one view into something consumable by other views.

Breakpoint management for 'multi-core' targets

• Current CDT breakpoint support is very limited
• We need to create a breakpoint for a specific target/core/process/thread
  • There is support for thread-specific, but only after creation
• Freescale has a mode that restricts the breakpoints creation to the active context, if this option is chosen by the user
• Breakpoints view should somehow show quickly where a breakpoints is installed
• Maybe the visualizer view could also be used to show breakpoint with respects to cores/processes/threads
• TI uses breakpoint grouping and filtering in the Breakpoints view to improve the situation
• TI applies breakpoints to the current multi-selection of the Debug view to control where they are set, that info is then stored in breakpoint attributes for re-creation
• We need a unified solutions for enhanced breakpoint support

Status

• Pin&Clone
  • Support is now part of platform
  • Patch posted for CDT for the different debug views. Feedback would be good. Patch can be found in Bug 331781
• Grouping and Hiding
  • Limited progress. Patch for discussion should be posted this week. Bug 240208
• Multi-process
  • Demo of DSF-GDB status
    • With GDB 7.2 and the patch posted at Bug 237306, we can freely start multiple processes and attach to multiple running processes in the same debug session.
    • The UI workflow is unclear. How do we specify the details for each new process to be started?
    • It would be nice to use a view of all processes and double-click on one to attach
    • RSE target view could be used for this as well, but that would be outside CDT
  • Demo of EDC
    • It uses different launches but shows them under the same top-level node in the Debug view
    • The top-level node is the target
    • When a new launch is run for the same target, it is automatically shown under the same top-level node
    • A new launch to the same target automatically re-uses the same connection to the target
    • Allows to have full settings for each process through a launch UI since it is a fully launch
    • Launches persists settings so they can be re-used
    • To avoid the heaviness of launches, the user usually won't use the launch UI but will use quick buttons and double-clicks that will trigger the launch automatically. The launch UI remains available for advanced cases of configuration. But underneath it all, each process is a different launch.
    • Source lookup was enhanced to allow the user to choose a launch's individual source lookup info, or the superset of all common-launches source lookup info.

Other

• What about filtering of the debug view? This should be achievable once we have general Grouping and Hiding feature.
• There is interest in a Global Breakpoints feature that will allow to set a breakpoint in a piece of code, without specifying which process/core/thread. This feature will be available from GDB using a Linux Kernel module, sometime next year.

November 30, 2010

Attendees

1. Norman Yi (Analog Devices)
2. Mikhail Khodjaiants (CodeSourcery)
3. Stan Shebs (CodeSourcery)
4. John Cortell (Freescale)
5. Chris Recoskie (IBM)
6. Abeer Bagul (Tensilica)
7. Anand Bhange (Tensilica)
8. Pete Macliesh (Tensilica)
9. Shaijup (Tensilica)
10. Dobrin Alexiev (TI)
11. Patrick Chuong (TI)
12. Bill Swanson (Tilera)
13. Randy Rohrbach (Windriver)
14. Doug Schaefer (Windriver)
15. Marc Khouzam (Ericsson)
16. Dominique Toupin (Ericsson)

Minutes

Tilera's Grid view demo (Bill)

• Bill showed Tilera's development environment, focusing on the Grid view.
• There is a Monitor view which presents somewhat of a summary of the information of the DebugView
• The DV uses the standard layout of Launch->process->threads->stack frames
• Grid view
  • 
  • Threads are shown in the grid view based on their location on the hardware
  • Selecting a thread in the Grid view will change the active selection of the DV
  • In fact, the Grid view and the DV are kept in sync at all times. This implies also that a selection change in the DV will update the selection in the Grid view.
  • The synchronization of the DV with the Grid view for the active debug context is done by faking selection events (deltas).
  • It is possible to select a range within the Grid view using the mouse. The active context of the DV will be chosen arbitrarily within the selected range.
  • View provides Resume/Step/Suspend buttons that apply to the active context, as is done in the DV.
  • Hovering over the Grid view provides information about the threads and hardware.
  • To avoid having threads move around much too fast in the view, it only reports changes when a thread actually stays in the same location for a certain minimum amount of time. This is done by a 'tile monitor' process that sits between Eclipse and the target.
• It was mentioned that using the DebugSelectionProvider and DebugSelectionListner API of the platform should allow us to keep the synchronization between two views providing the active context at the same time,
  • We need to confirm that the platform properly supports having multiple selectionProviders at the same time.
  • It would be good to get a small prototype with 2 or 3 active selectionProviders including the DV
  • Is the DV already a selectionListener? It is believed so, but should be verified
  • Is there a impact to the Pin&Clone feature from having multiple selectionProviders?
• One suggestion put forth was to have a feature to allow to select a variable and to show its content on the Grid view
• Tilera is interested in having a view like the Grid view in open-source
• Bill explained that the main issues with contributing the Grid view to open-source, is that the current implementation is not generic. We would need an generic API to allow for different layout for such a view
• There was interest from almost everyone in the call in getting this view part of open-source. Some people may be able to directly help.
• There were still questions about how PTP handles such a view since they have something similar, but no one from PTP was on the call
• There was a concern about potential existing patents on the Tilera's Grid view. We need to confirm that no such thing would prevent us from implementing this type of view, before actually starting the work.

Pin&Clone feature

• Patrick gave a demo of the Pin&Clone feature as proposed right now. The lable/icon indicator was not working because of a recent change requested by the platform.
• Pin&Clone also supports a multi-selection pinning. This means that a view pinned to more than one context, would change when the active context changes to any of the context part of its pin set.
• Pinning will also work for 'groups' once such a concept is implemented
• The main use-case of this feature is to compare data of different contexts, and keep comparing as execution progresses
• Depending on the situation, the context to be pinned to may be a parent of the one that is currently active. Ultimately, for CDT, the decision of which context in the hierarchy should be the one used for pinning, should be a backend decision (for DSF, it should be the services making that decision)
• It is unclear how to store the pinned context so that it can be found again for a new debugging session.
• The patch for the platform is close to being approved (it was actualy committed the day after the meeting!)
• Once the platforms allows for the pin&clone feature, we can implement it in CDT. There was a concern that it may be too advanced for some users; it was suggested to use an ActionSet or a Preference to enable the feature

Grouping Demo

• Dobrin gave a nice demo (similar to the one given at the CDT summit) to show the grouping/hiding feature that he is trying to contribute to CDT
• There would be a way to group/ungroup/hide any part of the context hierarchy
• Operations can be performed on a group (resume/step/suspend)
• The concept of groups does not need to be supported by the backend. In such a situation, the backend services would loop over all element of the group to perform the operation
• Dobrin also showed how TI uses the launch to allow the user to select which types of nodes are going to be shown in the DV

Other

• Stan Shebs, one of the GDB maintainers, mentioned that there is interest from GDB to support "multi-core" debugging
• With that in mind, he asked that if people ran across scalability limitations in GDB itself, we should report them to the GDB mailing list (gdb@sourceware.org). This will enable the GDB community to address those issues, which will surely eventually affect eclipse when using GDB.
• One the topic of scalability, it was mentioned that the Expressions view is not very efficient; every expression is queried not matter what the context is, an in many cases the expressions don't apply to the current context.

November 16, 2010

Attendees

1. Norman Yi (Analog Devices)
2. John Cortell (Freescale)
3. Abeer Bagul (Tensilica)
4. Anand Bhange (Tensilica)
5. Pete Macliesh (Tensilica)
6. Patrick Chuong (TI)
7. Dobrin Alexiev (TI)
8. Bill Swanson (Tilera)
9. Pawel Piech (WindRiver)
10. Doug Schaefer (WindRiver)
11. Marc Khouzam (Ericsson)
12. Dominique Toupin (Ericsson)

Minutes

• Level of expected contributions from interested parties
  • Patrick and Dobrin have time allocated to this
  • Marc has time allocated for this
  • Pete can have someone help on UI work
  • Other commitments will clarify as the effort takes shape

• Conference calls
  • We will continue with this time slot (11am Ottawa time) every two weeks or so. We will adjust the frequency depending on the progress.

• Current status
  • TI (Patrick and Dobrin) are working on open-sourcing some of their multi-core features
    • Pin & Clone effort (Patrick)
      • He has posted a small patch for platform which would allow other projects (e.g., CDT) to implement Pin and Clone. He is waiting for the platform team to review the patch in detail.
      • Patrick was ready to give a demo but we ran out of time. We will have the demo at the next conference call.
      • After the demo, we can start discussing and potentially bringing to the cdt-dev list the question of having this feature committed to CDT (pending the approval of the small platform patch)
      • Worked tracked in Bug 327263. Anyone can try out the feature as follows:
        1. Checkout the platform org.eclipse.debug and org.eclipse.debug.ui plugins
        2. Apply the latest patch available in Bug 327263
        3. Save the test plugin also attached to Bug 327263, and import it into your workspace.
        4. Start cloning and pinning debug views using the new buttons added to each view!
    • Recursive set of container context in DSF/DSF-GDB (Dobrin)
      • The approach is to use the Debug View with a recursive set of containers, where the backend debugger remains the top-level entity.
      • Worked tracked in Bug 240208
      • Issues with deltas when enabling recursive containers
      • Does anyone have a use-case where a container would also have a stack frame under it? Currently no, so we won't pursue this at this time.
      • Dobrin will demo his progress at the next conference call
      • TI's uses cases all focus on 10 to 50 contexts in the debug view. They currently feel that dealing with more than 100 contexts requires a new approach.

• Discussions on Tilera's Grid view:
  • The view has proven useful, but mostly when knowledge about the underlying hardware was relevant to the problem being debugged.
  • Tilera saw that software designers still view their software as a generic grouping of processes and threads, as shown in the Debug View.
  • Different users approach different problems in different ways. We should give users different views, etc, to tackle problems and let them choose what suits their needs.
  • Concerns were voiced about having two selection providers (Debug View and Grid view), but Bill confirmed he was able to get it to work. A demo will be given at the next call.
  • Someone asked if PTP had to deal with multiple selection providers for their views. We did not know the answer to this.

• Filtering of information is essential to multi-core debugging. Grouping and hiding are trying to address this.

• Clean up wiki page to help people add their use-cases of interest, to help keep focus on the problems we face. [Marc]

• Code Reviews would be valuable. With people actively working on this effort, we could code review each others work.

• We will need to allocate time to do proper documentation for the features we will implement in this effort.