Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

DSDP/DD/Face-to-face Alameda 14-18-May-2007

< DSDP‎ | DD

The purpose of this meeting is to continue work on the DSF/GDBmi reference implementation staffed by Ericsson. This meeting will be very technical in nature and will focus on coding rather than presentations. The meeting is open to all, but please see the prerequisites below.


Monday May 14 2007 to Friday May 18 2007


Marina Village Inn
1151 Pacific Marina
Alameda, CA 94501
Water Front Room with Queen or King at special rate of 99$. The room has to be booked by phone and you need to specify you are visiting Wind River. This hotel is a short walk from the Alameda campus.
+1 800 345-0304 or +1 510 523-9450
Hotel Link Map


Wind River Corporate Headquarters
500 Wind River Way
Alameda, CA, 94501

Please come to the front desk in building 500, and ask for Pawel Piech, or for DSDP/DSF meeting.


  • Installed on laptop Linux SUSE Enterprise Server 9 or 10
  • Install Java 5, Eclipse 3.3 M6, CDT 4.0(head from CVS), DSF 0.9(head from CVS), GDB 6.6 all on Linux
  • Read DSF documentation
  • Make the connection work between DSF and GDB
  • Understand the DSF API (reading the code)
  • Attend the phone conference on May 3 to ensure the above steps where successfully done

A Windows configuration could be use on non-Linux laptop:

  • Java 5, Eclipse 3.3 M6, CDT 4.0(head from CVS), DSF 0.9(head from CVS), MinGW GDB 5.2.1 (could also try with 6.3.2) all on Windows



DSF and GDB/MI architecture knowledge transfer

Incompatibilities between DSF and the functionality provided by GDB

  • Is GDB going to support out-of-band events indicating threads starting/exiting?
  • In expression/variable managment, what is the cost of creating/deleting variables.
  • When sending CLI commands, is there anyway to have GDB return the equivalent GDB/MI result, or generate an out-of-band event corresponding to data changed?

Tuesday, Wednesday, Thrusday

Coding workshop: break up into groups of 2 to 4 and tackle design and implementation of a DSF service. Possible tasks for workshop:

  1. Complete the expression service implementation in order to populate the variables and watch views
  2. Extend the run control service to support multiple threads
  3. Implement the memory service and connect the memory view to it


DSF Development Formalities:

  • Filing Bugs
  • Subscribing to bug email notifications
  • Unit tests
  • Coding conventions
    • Keeping consistent coding style within modules
    • TODO's
  • Compiler warnings



  • Pawel Piech, Wind River
  • Randy Rohrbach, Wind River
  • Ted Williams, Wind River
  • Alf Larsson, Ericsson (CPP)
  • Veenu Khanna Verma, Ericsson (TSP)
  • Francois Chouinard, Ericsson (TSP)
  • Dominique Toupin, Ericsson (R&D PM&T)
  • Conor White, Ericsson (R&D PM&T)
  • Jim Blandy, CodeSourcery
  • Eugene Tassarov, Wind River
  • Stuart Fullmer, MontaVista

Other names will be added as we get confirmation.

Documentation to help get familiar with Eclipse Debugging and DSF

Unfortunately there is a long and steep learning curve when starting to develop debuggers for Eclipse. On the upside there is a lot of excellent documentation to help with this task. I recommend looking at these materials in the order listed below.
Article describing the Eclipse launch framework and a walk-through example of how to use it. Launch framework is a rather un-usual feature of Eclipse debugger, which causes some confusion to a lot of new Eclipse users and developers. Understanding the launch framework is essential in making sense of the overall debugger framework.
This article walks through creating a simple debugger with basic features using the "standard" eclipse debug model. Although the provisional "flexible hierarchy" interfaces introduced in Eclipse 3.2 make it possible to by-pass the standard model and this is what DSF does, understanding the standard debug model is still essential for backward compatibility and interoperability with third party tools.
Presentation from a tutorial on Eclipse debugging from EclipseCon 2007. It contains a presentation with a very broad overview (214 slides) of debugger features, as well as a few examples on general debugger features, memory view, and flexible hierarchy. This tutorial is a lot to digest at one time, but it's also a very valuable resource in learning to use the debug framework.
DSF online documentation. The documents under this link are somewhat out of date with respect to specific package and class names, but in principle they are very relevant.
  • White Paper - Paper describing goals technology goals and principles
  • Services Model - Design document describing the framework for declaring and using services in DSF.
  • Concurrency Model - Design document describing the threading model of DSF
  • Data Model - Design document describing the data model to be used with DSF. This document is least complete of the design document, but it does touch on some of the important topics. It is best to study the flexible hierarchy framework and examples before looking at the DSF Data Model.
  • GDB/MI Implementation Setup Guide - A brief list of steps to install and run DSF GDB/MI implementation.
Presentation further describing the DSF Data/View model. This presentation was given at the last DD meeting in Toronto on January 10th, 2007. It gives an overview of the DSF integration with flexible hierarchy framework.
Examples of use of DSF framework features. Studying these examples is the easiest way to get started on understanding and using DSF.
GDB/MI documentation


I made the mistake of not taking notes as we went along, so I'm in the unfortunate position of writing this summary as a retrospective. If anyone has additional notes or comments, please add them to this section.


Architectural discussions
After making sure that everyone had the DSF plugins checked out into their workspace, we proceeded with the architectural discussions. There were a couple of diagrams in the agenda, but most of the discussion centered around stepping through code and drawing white-board diagrams.
GDB discussions
Jim Blandy, a GDB maintainer from CodeSourcery, gave an high-level presentation of embedded debugging with GDB and answered (a lot of) questions about GDB. His main points were:
  • GDB in general is open to 'incremental' patches as long as they are not too architecture specific and as long as they don't violate the architectural boundaries, which took a lot of refactoring effort to establish.
  • With respect to MI interface in general, given current GDB design, there are a lot of improvements that can be made at relatively little effort. Also, GDB is looking for someone who could commit to long term maintenance of the MI interface.
  • With respect to our specific questions about MI interface in the agenda Jim had the following comments:
    Is GDB going to support out-of-band events indicating threads starting/exiting? 
    GDB currently generates such events for the CLI interface. It could be extended to generate similar notifications in the MI interface.
    In expression/variable management, what is the cost of creating/deleting variables? 
    GDB maintains a table of "open" variables. Creating/deleting a var object simply adds/removes an entry in this table. Thus a client could continually create/delete variables without incurring much overhead beyond the additional communication processing.
    When sending CLI commands, is there anyway to have GDB return the equivalent GDB/MI result, or generate an out-of-band event corresponding to data changed? 
    After some discussion, we concluded that in order to properly support a CLI interface GDB would need to generate out-of-band events for all state changes, such as: running events, breakpoints changed events, register/memory/variable write events, etc. At first sight, Jim couldn't see any architectural problems with such a change.
  • Couple of additional questions came up about GDB capabilities:
    Is GDB going to support multi-core debugging? 
    There is some progress in re-architecting GDB towards this goal, but this feature is still long way off.
    Is GDB going to support debugging individual threads? I.e. suspending a single thread while other threads are still running? 
    There are architectural issues with this and currently this capability is not being developed.


On Tuesday we started on the coding camp part of the meeting. I spent the first half of the day introducing the exercises, and we got started on actual coding in the afternoon. Per request of the participants we tackled only the first exercise and we split it into two parts:

  1. Feature in MIStack service to retrieve the list of local variables.
  2. Implementation of MIExpressions service to evaluate the expressions and retrieve their types, formatted values, and sub-expressions.

The first task was considerably simpler and by the end of the day Veenu submitted a patch implementing retrieving local variables in the stack service. The expression service at this time progressed to the point where it could retrieve the type of an expression.


We started the day by merging the patch from Veenu and continued the expression service development. A lot of discussion centered around the sequence of data flow between the variables view UI and the locals and expressions services. By the end of this day the expression service was capable of creating GDB variable objects, retrieving their type and retrieving correctly-formatted values.


In the beginning of the day we reviewed the design of the MIExpression service and identified some weaknesses in managing the GDB variable objects. Following the design discussion we split up and we had Stuart work on the logic of tracing the variable objects, while the rest of us looked at implementing the data retrieval methods. By the end of the day, Stuart submitted a patch containing the MIExpression service implementation, which just a couple of known issues outstanding.

Also on Thursday we discussed the general problem of tracking the state of the protocol controlled by the -thread-select and -stack-select-frame commands, with the latter being needed to implement variable retrieval for different stack frames. After the design discussion Veenu started on the implementation in the CommandCache and ICommandControl components both of which need to be completed for the bug# 159694 enhancement.

At the end of the day we also talked about some of the practical formalities of contributing to DSF

  • We followed the steps on filing a bug against DSF. Nothing unusual here outside of general bug filing FAQ has, except for description of DSF components, which are:
    This is the framework component which includes the org.eclipse.dd.dsf/ui and org.eclipse.dd.dsf.debug/ui plugins.
    This component is the implementation of the DSF-debug services against the standard MI protocol. This includes plugins org.eclipse.dd.dsf.mi.core/ui.
    This component is the GDB-specific services and UI which extend the standard MI services. This includes plugins org.eclipse.dd.dsf.gdb/ui.
  • 'On watching bugs' I made a soap-box speech about using bugzilla as the primary means of task tracking/task documentation/task communication, and I requested that anyone who is a contributor subscribe to email notifications about new DSF bugs. In order to accomplish this, please add to the "Users to watch" text field at the bottom of the your bugzilla account preferences page.
  • 'On unit tests' We had a discussion about test-driven development and we eventually made a decision to adopt a policy that a given enhancement is not going to be considered complete until a corresponding unit-test is written for that feature as well, as long as it's reasonable for the given feature.
  • 'On coding conventions'
    • We don't have specific style guidelines, although this might change if style becomes a contentious issue. For now, we ask that when editing existing modules, contributors follow the style that exists in the modules already. In more general terms, we tend to follow the style found elsewhere in Eclipse.
    • I requested that code being checked in should not contain any TODOs. The logic being that what would go into a TODO comment should instead be added to a comment in bugzilla.
  • 'On Compiler warnings' Compiler warning settings are saved with DSF project files ensuring consistency. Checked-in code should not contain any warnings.


We committed the whole last day to project planning discussions. We started with general discussion of project management style and needs, and concluded the following:

  • Doug Gaff is the current Device Debugging (and thus DSF) project manager. However Doug has extensive other commitments in the DSDP project and most likely will not have sufficient time in order to continue managing the DD project with the expected increased level of activity. Wind River intends to nominate a project lead or co-lead in the next couple of weeks.
  • In order for contributing companies to build products on top of DSF there needs to be a reliable milestone project plan for DSF releases.
  • DD is a volunteer based effort that multiple companies contribute resources to. In order to create a reliable schedule, we will need a clear statement of commitment of resources from contributing companies. It is also important that contributing companies notify the project manager on timely basis when their resource commitments change.
  • Following this we identified the primary goals for the 1.0 release of DD project:
    • Debugger implementation connecting to GDB back end
      • Only the latest version of GDB is going to be supported on a Linux platform. This doesn't necessarily mean that older versions of GDB on other platform will not work, but they will not be specifically tested. If another version of GDB, such as an older revision, or a different variant such as cygwin is required by a contributor, that contributor will need to extend the GDB debugger and support it as a separate feature.
      • The minimal functionality supported by the debugger should be at least equivalent to the CDT feature set. Bug 187863 was created to track this feature. All features that need to be completed for this task are marked as dependencies for this bug.
      • As mentioned previously, along with the functionality, unit tests need to be supplied to test the components making up this implementation.
      • End-user documentation for UI features which are contributed by DSF (as opposed to platform or CDT). See Bug 187908.
    • An SDK package containing documentation on getting started with DSF. See Bug 187921.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.