ken.ryall@xxxxxxxxx wrote:
Pawel,
Thanks, that’s a good idea, I’ll start working in that direction.
Which led to another thought: Since each variable for a stack frame has
to be uniquely identified by name I need to come up with a notation to
distinguish between variables with the same name from different scopes
within the same function. It looks like IVariableVMData.getName is only
used to create the _expression_ and not for display so I suppose I could
encode additional info about the variable into the string returned by
IVariableVMData.getName.
We've talked about this issue in the past at Wind River, and I think
within context of DSF too, but neither GDB nor Wind River debugger
allow for evaluating variables in different scopes in the same
function, it's only been a theoretical discussion. In any case, the
way we thought it should be handled is that the context which is given
to the _expression_ service should include the exact address at which to
evaluate the given _expression_. However, we never crated an interface
for an address context, or tried to implement this.
Encoding the scope into the _expression_ name is probably a lot more
practical solution.
Cheers,
Pawel
Ken
From: ext Pawel Piech
<pawel.piech@xxxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Fri, 5 Jun 2009 01:17:07 +0200
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] DSF Variable-_expression_ API Question
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 Variable-_expression_ API Question 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
|