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 <email@example.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.
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 <firstname.lastname@example.org>
Hi Ken, I totally agree with everything you're saying, it's just a really tough challenge: to design a standard debug model implementation in components, such that they can be selectively replaced to provide custom functionality... a very worthy goal though.
Still what I'm struggling with right now is the question of "other tools" and interoperability between models. What are the specific use-cases for other tools accessing the debug model? And what features require debug models to collaborate with each other?
I will take a stab at what I think Ken is getting at: I would think the use case would be any other vendor that wanted to build something on top of a debugger and have it work with multiple debuggers. So in theory they write their tool and then can run it on top of anyones embedded debugger (CDT or WorkBench or EDGE or ...). Say for example an RTOS vendor that wanted to write kernel awareness of some kind that listened for events and then iterated global variables displaying their data structures on a target stop. Another example would be semiconductor vendors who want to add views and such that are specific to features of their chips and have it run on multiple debuggers. We are asked about this all the time. More than once I have heard "We can just write an Eclipse plugin right?" Sure provided the framework is there...