Skip to main content
Jump to: navigation, search

DSDP/DD/DSF CodingCamp MemoryServiceExcercise

< DSDP‎ | DD
Revision as of 16:50, 9 May 2007 by (Talk | contribs) (Design Considerations)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


  • Implement the memory service.
  • Implement adapters which extract data from the memory service and implement the platform APIs for populating the memory view.


Memory Service

Missing functionality
A new MI-based service implementation needs to be created and added to the service startup and shutdown procedures
A memory context object needs to be created, and added to the context returned by the container and execution contexts held by the clients
Methods for reading and writing memory need to be implemented

Standard debug model APIs

In org.eclipse.debug.core.model, IMemoryBlock, IMemoryBlockExtension, IMemoryBlockRetrieval, IMemoryBlockRetrievalExtension
Missing functionality
Implementation of the interfaces which reads data from the DSF memory service
Tracking of which memory values were modified.

Reference Code and Documentation

CDT provides an implementation of the standard model memory APIs with org.eclipse.cdt.debug.internal.core.CMemoryBlockRetrievalExtension and org.eclipse.cdt.debug.internal.core.model.CMemoryBlockExtension. This is a good reference and place to cut+paste from to implement these APIs quickly.

Also the MI implementation of the CDI interacts with the MI back end using the org.eclipse.cdt.debug.mi.core.cdi.MemoryManager object. This is a good reference for using the MI commands to read and write memory.

Design Considerations

The memory view is somewhat different than the other debugger views in that it doesn't use the flexible hierarchy APIs to populate its contents. Instead there is a set of interfaces in the standard debug model which retrieve data from the debugger, and which were evolved over the many eclipse releases to contain all the features that various debug vendors needed. In the 3.2 release, the memory view introduced custom memory renderings that could be supplied, but these renderings still expect to use the standard model API to read the memory data. The standard model interfaces, which contain synchronous methods, need to be implemented to read data from an asynchronous interface which is the IMemory service. To accomplish this, the org.eclipse.dd.dsf.concurrent.Query object will need to be used extensively.

On the service implementaiton side, the challange is to create the optimal caching mechanism. Theoretically, the memory service should be smart enough to only request data from the back end which has not been read already. In order to accomplish this, the standard CommandCache utility will most likely not be sufficient, and instead a custom mechanism will need to be developed for caching memory values.

Alternatively, the CommandCache utility could be extended to properly manage commands for ranges of data and their results. Such work would benefit other services which retrieve ranges of data.

Back to the top