Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Talk:DSDP/DD/DebugModel"

(Requirements Discussion)
Line 16: Line 16:
  
 
-Pawel
 
-Pawel
 +
 +
 +
==Design discussion==
 +
Pawel,
 +
 +
For now just a couple thoughts:
 +
 +
The new platform model is wonderfully flexible but a model for C/C++
 +
debuggers needs to provide enough common structure to make it reusable
 +
across back-ends. Otherwise there is not much to leverage and other tools
 +
don't have a way to address debugger stuff. The more common elements we can
 +
put into the model, the more we can collaborate.
 +
 +
A debug model for C/C++ should as much as possible allow the back-end to
 +
provide as rich a debug experience as it can. That's not to say that the
 +
model has to let every back-end interact exactly the way it wants to, some
 +
glue and various adjustments will usually be necessary.
 +
 +
A debug model should address the most common debugger use cases and let
 +
back-ends opt out and do their own thing when they do something wildly
 +
different. But in those cases the benefits of the model should also provide
 +
an incentive for people to adjust their debugger back-ends to better match
 +
the model.
 +
 +
Looking forward to a more in-depth discussion later on.
 +
 +
- Ken Ryall <ken.ryall@nokia.com>
 +
----

Revision as of 18:48, 17 May 2006

Requirements Discussion


Pawel,

Assuming the proposed requirements target more than one (Oceanian) monitoring system it would be good to define the place for it within the Eclipse project. Is it an extension of the platform model or an implementation of it that allows to plug in different back ends?

-Mikhail Khodjaiants <mikhailk@qnx.com>:


I didn't really think that far ahead here. I figured we would start out defining the requirements for our fictional debugger, which more/less represents the requirements of all of our different commercial debuggers. After that I thought we would move onto the design discussion.

That said, this is a page dedicated to discussing the client's requirements for the Debug Model interfaces, and from my point of view, any toolkit that will make it easier to implement these Debug Model interfaces. So in case of the debugger for the citizen monitor of Oceania, the next logical step is to evaluate its requirements, and see if it the Debug Model interfaces fit these requirements, and if any existing toolkit fulfills the requirements, and if not, can the interfaces and toolkits be modified to meet these needs, and/or should new ones be created?

Jumping ahead a little bit. Everyone in this discussion has a commercial debugger that shares some of the requirements with this one, and some of us found that the traditional Debug Model interfaces were too restrictive, so we've implemented solutions that circumvent it, and later we persuaded the Platform to make them more flexible to meet our needs. Same is true with the toolkit, some of us used the toolkit to implement a debugger solution, and some of us found that the available toolkit doesn't meet our requirements, and decided not to implement the whole debugger instead. In other words, I think the next steps after the requirements discussion are:

  • An evaluation of the existing Debug Model and toolkit against our requirements.
  • Ideas on how to best change/supplement existing Debug Model and toolkit so that it meets our requirements.

-Pawel


Design discussion

Pawel,

For now just a couple thoughts:

The new platform model is wonderfully flexible but a model for C/C++ debuggers needs to provide enough common structure to make it reusable across back-ends. Otherwise there is not much to leverage and other tools don't have a way to address debugger stuff. The more common elements we can put into the model, the more we can collaborate.

A debug model for C/C++ should as much as possible allow the back-end to provide as rich a debug experience as it can. That's not to say that the model has to let every back-end interact exactly the way it wants to, some glue and various adjustments will usually be necessary.

A debug model should address the most common debugger use cases and let back-ends opt out and do their own thing when they do something wildly different. But in those cases the benefits of the model should also provide an incentive for people to adjust their debugger back-ends to better match the model.

Looking forward to a more in-depth discussion later on.

- Ken Ryall <ken.ryall@nokia.com>


Copyright © Eclipse Foundation, Inc. All Rights Reserved.