P.S. What would be really nice to have in IVariableDMData is a
getType() method: In the UI we need to be able to extract persistable
information about stack frames for comparison purposes. Right now we
use only the function name, but it would be better if we could use the
name combined with argument types (to distinguish between overloaded
methods).
-Pawel
Pawel Piech wrote:
I suppose this is a good example of the GDB bias in the DSF
interfaces. IVariableDMData has two methods: getName() and getValue(),
because these are the two pieces of data returned by GDB for the
-stack-list-args command. But for the variable data to be really
useful, the full _expression_ information needs to be retrieved using the
_expression_ service. In fact, the UI implementation currently doesn't
even use the IVariableDMData.getValue(). IMO, it would be acceptable
to just deprecate this method.
I think you can do two things to simplify the implementation:
1) Implement IVariableDMData to only return the getName(), return a
null value for getValue(). This way, your implementaiton of
getVariableDMData() wouldn't require any target access.
2) Implement IVariableDMContext and IExpressionDMContext using the same
object, then delegate the getVariableDMData() call to the _expression_
service, this way the caching will be simple. At the API level we
didn't want to introduce too many dependencies between the interfaces,
so that for example we could replace the IExpressions service with
something like IExpressions2, without having to deprecate methods in
other services. But this doesn't mean that you can't mix and match
these interfaces within your implementation.
Cheers,
Pawel
ken.ryall@xxxxxxxxx wrote:
DSF folks,
I’m working on getting local variables to show up in the Variables
View. After getting the list of variables from the symbol data I
produce a list of IVariableDMData from iStack.getLocals. These seem to
get consumed by the code in VariableVMNode.
GetLocalsUpdateElementsInSessionThread. For each of them it asks for
their name and then calls the _expression_ service to create a new
_expression_ from that name. The resulting ExpressionsDMCs are then used
to drive the view.
This bothers me because I’m first getting the information about all the
variables for a stack frame and handing their names to the _expression_
service which will then look them up all over again in order to
evaluate the expressions. I can do some smart caching to reduce the
impact of this but it seems like there ought to be more direct route
from iStack.getLocals to the list of ExpressionDMCs that are eventually
used, maybe a way to create an ExpressionDMC directly from a
VariableDMC?
Please let me know if I’m missing something.
Thanks,
Ken
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
