Community
Participate
Working Groups
Build Identifier: I20110613-1736 A dsf debug session needs to persist its user defined data so that any preferences changed by the user can be saved and restored across sessions. Examples are: 1. Format applied to a variable 2. Cast defined for a variable 3. User defined register groups In order to be able to persist such data, we need to be able to identify the DMContext object for whose attributes have changed, and store the changed attributes in a way that we can restore them to the same DMContext object in the next debug session. A fully qualified persistent name for a given DMContext can be created as follows: Define a service which accepts a DMContext and asynchronously returns its fully qualified name in the data request monitor. This name is in dot notation, similar to the format used by DMContext.toString(). The service will traverse the ancestor hierarchy of the dmcontext and for each object, will issue an async query for the name of the object. Querying the name of an object differs for each DMContext type, so each type will have an adapter which can perform this query. Such adapters need to implement IDMContextNameAdapter, and each launch type can override the adapters through its launch delegate. The user can also override the service implementation through the launch delegate. The default service and adapters work similar to IDMContext.toString(). Reproducible: Always
Created attachment 206932 [details] Service which returns a fully qualified name for a given IDMContext
This would help solving bug #306554.
Usage of this service for bug 306554 can be as follows: 1. When user applies a cast to a IVariableDMContext, we query for the persistent name of the variable dm context using this service. 2. There can be another service defined IContextPersistence which supports a set of persistent attributes for each DMContext. 3. We set the applied cast as an attribute in the set, which will be persisted to a storage container when the launch is shutdown. The IContextPersistence also offers a subclassable storage container which can be overridden for different launch types for vendor specific storage. The default storage container will be the launch config. 4. When the debug session is restarted, and this variable comes up in the Variables view, the IContextPersistence service is queried for a set of attributes for the persistent name. If the set of attributes contains a "cast to type" attribute, the cast is re-applied to the variable. This service can also be extended by vendors to go beyond the IDMContext hierarchy and include target specific segments in the fully qualified name. Example: The IContextNameProvider service can be subclassed by multicore launches so that two same name registers from different cores can have different fully qualified names rooted at the core name, so the register view can show different bit patterns for the same register name, depending on which core the register comes from. The core might not be represented in the dmcontext hierarchy, but might be available in the launch as a parent of this register.
I agree that is a sorely missed functionality. I've been thinking for a long time about a different approach to solve the same problem: Instead of creating a new service for this purpose, I was going to use the IElementPropertiesProvider to retrieve values of well known properties (e.g ILaunchVMConstants.PROP_FRAME_FUNCTION), then use these for persistent identification of elements. There would be some challenges with this approach, as the IElementPropertiesProvider is associated with a IVMContext and with a specific view, so it would be more difficult to access properties of a thread if a stack frame is currently selected in Debug view. On the upside, there would be no new APIs to define. If you'd be interested in trying this approach, let me know and I'll give you some support.
(In reply to comment #4) > Instead of creating a new service for this purpose, I was going to use the > IElementPropertiesProvider to retrieve values of well known properties (e.g > ILaunchVMConstants.PROP_FRAME_FUNCTION), then use these for persistent > identification of elements. I don't have enough experience to really judge between the two approaches. Could you specify what you see as the pros and cons of the IElementPropertiesProvider approach versus a new service approach?
(In reply to comment #5) > (In reply to comment #4) > > Instead of creating a new service for this purpose, I was going to use the > > IElementPropertiesProvider to retrieve values of well known properties (e.g > > ILaunchVMConstants.PROP_FRAME_FUNCTION), then use these for persistent > > identification of elements. > > I don't have enough experience to really judge between the two approaches. > > Could you specify what you see as the pros and cons of the > IElementPropertiesProvider approach versus a new service approach? The main trade-off I think I pointed out already. The new service approach creates a new API that debuggers will have to implement, so it's more work for clients, but it's simpler to implement.
(In reply to comment #6) Marc, what do you think of the implementation in the contributed patch? Would you apply it as is?
(In reply to comment #7) > (In reply to comment #6) > Marc, what do you think of the implementation in the contributed patch? Would > you apply it as is? I haven't had any time to even look at it :-O And I won't until December. If someone else has time, that would be great.
Can you give a rough outline of how to use IElementPropertiesProvider for persistent names? I will try to create a solution based on that outline and add a patch.
(In reply to comment #9) > Can you give a rough outline of how to use IElementPropertiesProvider for > persistent names? I will try to create a solution based on that outline and add > a patch. I'll try, though I didn't get to it today...
Will the solution as outlined below work? To create a fully qualified name for a stackframe object using IElementLabelProvider, we will have to create a name based on the hierarchy indicated in LaunchVMProvider. The hierarchy in LaunchVMProvider is as follows: launch node |- container (process) node |- thread node |- stackframe node So the fully qualified name can be of the form: /<container name>/<thread name>/<frame name> Each node is an IElementLabelProvider, so given a stackframe dm context, we need to traverse up its parent hierarchy and get the corresponding vm provider. For a stackframe dm context, we need the StackFramesVMNode so that we can query it for the value of IElementPropertiesProvider.PROP_NAME, then for each parent in the hierarchy, we need to get the corresponding VMNode and query it for PROP_NAME. So for each parent VMNode, we can call its method public void update(final IPropertiesUpdate[] updates), and when the update is done, we can retrieve the value of PROP_NAME. Am not able to find two APIs: 1. Given a dmcontext, how to find out the corresponding VMNode, 2. Given a VMNode, how to find out its corresponding VMNode parent.
One use of the fully qualified name of a dmcontext will be to persist the cast applied to a local variable. Currently the cast applied is persisted during the debug session, but the key generated is just <dsf session id>.<variable expression>. This key is generated in method DsfCastToTypeSupport.createCastedExpressionMemento(...). This method receives an IExpressionDMContext object and returns a persistable String key. Since this method is a part of the DMContext layer, will it be ok to query the GDBVariableVMNode which is part of an upper layer (i.e. VMContext)?
(In reply to comment #10) > (In reply to comment #9) > > Can you give a rough outline of how to use IElementPropertiesProvider for > > persistent names? I will try to create a solution based on that outline and add > > a patch. > I'll try, though I didn't get to it today... OK, I think I have to take back my suggestion. I tried prototyping it for a couple of hours and found a lot of hurdles. Some of the issues: 1) DsfCastToTypeSupport not only takes DM contexts instead of VM contexts, it also uses synchronous methods, so any kind of polling of properties throu IElementPropertiesProvider is not workable. I looked at replacing them with new async methods, and it's doable, but it'd require more work in the VariableVMNode, which is understandable. 2) There's no reliable way to get at the selection in debug view. I looked at adding an AbstractDMVMVMNode.getDebugContext(), which is fine, except it may not always be reliable (as in an editor expression hover). 3) We don't have official vm context interfaces (i.e. no IStackFrameVMContext), so there's no simple way to identify a stack frame in a debug context. Could look at (IDMVMContext.getDMContext() instanceof IStackFrameDMContext), but its also not guaranteed to be 100% reliable. 4) Using IElementPropertiesProvider would also be quite cumbersome. I.e. need to create VMPropertiesUpdate and call the properties provider, etc. All of these hurdles could be overcome, but I can't honestly say that it'd be worth the effort. I.e. your service based approach is simpler and more direct. I don't have time to test and commit it now, but if there's any other committer that could look at it, I give it my +1. (Thank you for the contribution).
