Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "DSDP/DD/DebugModel"
| (21 intermediate revisions by 4 users not shown) | |||
| Line 5: | Line 5: | ||
---- | ---- | ||
---- | ---- | ||
| − | + | ''"For me the definition of "a debug model" (not "the debug model") in this context is an abstraction in form of API that describes a family of debugger engines. Combined with the implementation that adapts the model into the Eclipse debug platform it will allow clients to integrate backend debuggers into Eclipse."'' | |
| − | == | + | - Mikhail Khodjaiants |
| − | + | ---- | |
| − | + | ==Objective== | |
| + | To define a set of APIs and a mechanism for extending these APIs to allow various debugger implementations to: | ||
| + | # drive content of debug views, | ||
| + | # allow users to perform operations to change the state of the debugger, | ||
| + | # allow 3rd party tools and standard clients to interact with debugger. | ||
| − | == | + | ==Requirements discussion== |
| − | + | ||
| − | + | ===Introduction=== | |
| − | * ''There should be no assumptions about the number of objects that the debugger might need to track.'' | + | OK, I guess I got over-ambitions with the literary analogy. For sake of time I'll stick to just listing out the requirements. |
| − | * ''The debugger views need to be able to rely on the external debugger process to perform filtering and sorting of the data to be presented to the user''. | + | |
| + | ===Scalability=== | ||
| + | |||
| + | * ''There should be no assumptions about the number of objects that the debugger might need to track.'' | ||
| + | * ''The debugger views need to be able to rely on the external debugger process to perform filtering and sorting of the data to be presented to the user''. | ||
| + | |||
| + | ===Connectivity between debugger and target=== | ||
| + | * ''Debug model implementation should be able to communicate with a back end over a slow connection with a large latency.'' | ||
| + | * But for local host debugging, ''It should also be able to communicate over a very fast connection without loss of efficiency''. | ||
| + | * ''There should be no assumption that there is only a single connection to the back end, because the debugger itself might be distrubted in a distributed system.'' | ||
| + | * ''It should be able to communicate over a very un-reliable connection, where the connection might be lost, then later recovered, and the debug model should be able to re-synchronize itself with current state of data on the debugged system. | ||
| + | |||
| + | ===What debug data should be presented and where=== | ||
| + | IMO this is the biggest challange for the debug model implementation, simply because different embedded debuggers can have very different visual representations. | ||
| + | * ''Debug model should allow arbitrary layouts of nodes representing debugger entities.'' | ||
| + | * ''Ideally, debug views should allow the user to reconfigure the content and layout of various debug views to suit individual preferences.'' This seems like a stretch, but the reality is that many of our users migrate from using very specialized debuggers which may have an unorthodox ways of presenting data. For such users it would be best to allow them to customize their views to match their working style. | ||
| + | |||
| + | ===Interoperability with 3rd party tools and standard clients=== | ||
| + | Even though many aspects of embedded debugging is unique to a given vendor/target configuration, etc, all of these debuggers share some common functionality found in standard debuggers (reading/writing memory, run control, stack retrieval, expression evaluation, etc). | ||
| + | * ''Debug model should define a set of public APIs to access common debugger functionality, either by supporting existing APIs (Platform, CDI, JDI) or defining new ones.'' | ||
| + | * ''If new APIs are defined, the model should have the ability to support legacy APIs: Platform, CDI, etc.'' | ||
| + | |||
| + | ===Update policies for debug data=== | ||
| + | Because of the lazy loading nature of the views, update policy has to be implemented by the model, and cannot be solved at the view level. Pushing this problem down to the model level doesn't solve all the issues, because the model itself will likely need to use lazy loading when retrieving data from a slow target, but at least it will allow for consistent information to be shown in the various views that are looking at the same data. | ||
| + | * ''Debug model should provide a standard API for configurable update policies including auto update, manual update, and timed update.'' | ||
| + | |||
| + | ===Filtering and sorting of debug data=== | ||
| + | This is another problem that cannot be solved at the view level because of lazy loading. And even at the model level, many of the models may not be able to implement sorting or filtering because they may be limited by the capabilities of the target or out of process/JNI debugger back end. | ||
| + | * ''Debug model should provide a standard API for sorting and filtering options. | ||
| + | |||
| + | |||
| + | [[Category:DSDP]] | ||
| + | [[Category:DSDP/DD|DebugModel]] | ||
Latest revision as of 12:36, 6 September 2006
This is the Debug Model Sub-group
Lead: Pawel Piech (Wind River)
Members: Mikhail Khodjaiants (QNX), Freescale, Nokia
"For me the definition of "a debug model" (not "the debug model") in this context is an abstraction in form of API that describes a family of debugger engines. Combined with the implementation that adapts the model into the Eclipse debug platform it will allow clients to integrate backend debuggers into Eclipse."
- Mikhail Khodjaiants
Contents
Objective
To define a set of APIs and a mechanism for extending these APIs to allow various debugger implementations to:
- drive content of debug views,
- allow users to perform operations to change the state of the debugger,
- allow 3rd party tools and standard clients to interact with debugger.
Requirements discussion
Introduction
OK, I guess I got over-ambitions with the literary analogy. For sake of time I'll stick to just listing out the requirements.
Scalability
- There should be no assumptions about the number of objects that the debugger might need to track.
- The debugger views need to be able to rely on the external debugger process to perform filtering and sorting of the data to be presented to the user.
Connectivity between debugger and target
- Debug model implementation should be able to communicate with a back end over a slow connection with a large latency.
- But for local host debugging, It should also be able to communicate over a very fast connection without loss of efficiency.
- There should be no assumption that there is only a single connection to the back end, because the debugger itself might be distrubted in a distributed system.
- It should be able to communicate over a very un-reliable connection, where the connection might be lost, then later recovered, and the debug model should be able to re-synchronize itself with current state of data on the debugged system.
What debug data should be presented and where
IMO this is the biggest challange for the debug model implementation, simply because different embedded debuggers can have very different visual representations.
- Debug model should allow arbitrary layouts of nodes representing debugger entities.
- Ideally, debug views should allow the user to reconfigure the content and layout of various debug views to suit individual preferences. This seems like a stretch, but the reality is that many of our users migrate from using very specialized debuggers which may have an unorthodox ways of presenting data. For such users it would be best to allow them to customize their views to match their working style.
Interoperability with 3rd party tools and standard clients
Even though many aspects of embedded debugging is unique to a given vendor/target configuration, etc, all of these debuggers share some common functionality found in standard debuggers (reading/writing memory, run control, stack retrieval, expression evaluation, etc).
- Debug model should define a set of public APIs to access common debugger functionality, either by supporting existing APIs (Platform, CDI, JDI) or defining new ones.
- If new APIs are defined, the model should have the ability to support legacy APIs: Platform, CDI, etc.
Update policies for debug data
Because of the lazy loading nature of the views, update policy has to be implemented by the model, and cannot be solved at the view level. Pushing this problem down to the model level doesn't solve all the issues, because the model itself will likely need to use lazy loading when retrieving data from a slow target, but at least it will allow for consistent information to be shown in the various views that are looking at the same data.
- Debug model should provide a standard API for configurable update policies including auto update, manual update, and timed update.
Filtering and sorting of debug data
This is another problem that cannot be solved at the view level because of lazy loading. And even at the model level, many of the models may not be able to implement sorting or filtering because they may be limited by the capabilities of the target or out of process/JNI debugger back end.
- Debug model should provide a standard API for sorting and filtering options.