Bugzilla – Full Text Bug Listing
| Summary: | Make global step actions retargettable | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Nobody - feel free to take it <nobody> | ||||
| Component: | Debug | Assignee: | Darin Wright <darin.eclipse> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P2 | CC: | dalexiev, John_Wiegand, mimrisek, oyvind.harboe | ||||
| Version: | 3.0.1 | ||||||
| Target Milestone: | 3.2 M6 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 79872 | ||||||
| Attachments: |
|
||||||
|
Description
Nobody - feel free to take it
Consider for 3.1, time permitting. Jared, please investigate this one. Since we already have the notion of IStep, we don't need to define a new "retargettable" interface. I beleive the actions should still update/enable based on selection change in the debug view and debug events being fired. When the action is invoked, it shold first ask the active part for its "IStep" adapter to operate on. If present, use it, otherwise, use the current selection in the debug view. One thing to think about is what happens when the selection in the debug view has an enablement of "false", but the active part has an enablement of "true". (I'm not sure that can happen). From the original request, we may not have to worry about such a situation - i.e. we only worry about using the alternate step adapter when the current selection in the debug view also supports stepping. Mikhail, can you verify this requirement? Mikhail, can you please verify that DW's suggestion fulfills your requirements? Sorry for delay.
>I beleive the actions should still
>update/enable based on selection change in the debug view and debug events
>being fired.
I am not sure about this. Why the action enablement can't be based on the same
IStep adapter provided by the active part? The priority should be given to the
active part's adapter. This will solve the problem you mentioned.
Another minor inconsistency is that IRunToLineTarget is defined in the UI
plugin and IStep is in the core. I would suggest to have "retargettable"
interfaces in UI and leave it to the debugger implementors to define additional
core interfaces, for example, IInstructionStep. In CDT we have IRunToLine and
IRunToAddress defined as debug model additions and RunToLineAdapter selects the
corresponding adapter depending on the active part.
What about the other global actions like resume/suspend/terminate? I still think we can re-use the interfaces from core, without introducing new API. Moving to M7. Probably. I can't think of an example right now, but it is possible to have some "exotic" views. Yep - but as long as the vew provides an adapter, it can delegate in whatever way it wants. The IStep interface is not limited to debug elements - it is stand alone. Pending PMC approval. Proposed implementation, requiring PMC approval: When a retargettable "step" action is created or whenever the active part changes, the action will ask the active part for its IStep adapter. If the active part has an adapter, that part will be targeted, otherwise the action will target the debug view. The action will update as it does now (i.e. in response to debug events, and selection change events). The performance impact should be negligable, as the action will only need to adjust/set its source when the active part changes (i.e. it does not need to lookup the source each time the action is invoked). The same pattern should be applied to the following actions: step over, step into, step return, resume, suspend, terminate. This was discussed and approved by the PMC last Wed. Sorry about the communication failure. Created attachment 20531 [details]
patch
I've attached a patch for a work in progress. It provides a retargettable
action for the "step over" action. I have some reservations with this approach
as the step actions, etc., already perform a lot updating in response to
selection changes in the debug view and in response to debug events. This
causes the actions to additionally udpate when a selection change occurrs in
any view/editor, causing jobs to be scheduled to run in the background,
adapters to be retrieved, etc.
Comments and feedback welcome. If this feature is not critical for 3.1 we may want to defer. Propose to defer for post 3.1 consideration. There may be other workarounds for this problem: * The disassembly view could set a property on the underlying/associated debug model to step in the different mode, when it has focus. * The disassembly view could bind an action to the action definition ids of the step commands to override the handler for the step action. I would like to revisit this issue post 3.1 This is fixed in 3.2. There are new interfaces for the debug actions - @see IAsynchronousStep, etc. Marking fixed. Verified |