Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Freeze invisible GDB variable objects

On 08/20/2014 01:35 PM, Raphael Zulliger wrote:
On 08/14/2014 03:26 PM, Mikhail Khodjaiants wrote:
On 14/08/2014 8:29 AM, Raphael Zulliger wrote:
Right now, as I'm writing this, I realize that CDT already does something like that. E.g. when initially expanding a struct (e.g.
MyOtherObject), then CDT does only execute '-var-evaluate-expression' on the visible items (m_Array1, OthrMember2and m_OthrMember3in this
example). Then, when I scroll down in the Expression View, so that m_OthrMember4 appears, CDT executes another "-var-evaluate-expression"
for var2.m_OthrMember4, right when that member starts appearing. I might study that code to find out more...

This is one of the basic features of the all views that belong to the Eclipse Debug Platform. Update requests are sent to the backend only
for the elements visible in the view.
That's true. But in this case, the "update request" is performed on the Root-TreeItem (e.g. the "MyObject" (see previous mail) expression
that is the struct instance). This happens after every single-step (or similar) operation (it's the suspend event that causes this, if I
remember correctly). That root item doesn't care about visibility of children. It simply forwards the "update request" to GDB (-var-update)
which in turn updates all children, unless someone taught it to do otherwise (by -var-set-frozen commands). Btw: This happens even if the
root item is collapsed. Therefore: Every expression that has been expanded some time ago consumes resources on every single-step & co operation.

I did some further "research" and I think I can now clarify my question a bit: What I'm currently trying to do is to execute a
"-var-set-frozen 1" or "-var-set-frozen 0" on each child of a MIVariableManager.MIRootVariableObject right before the "-var-update" happens
(in MIVariableManager.MIRootVariableObject.update). Of course I would only execute that command if not already done before. The only missing
thing is, that IVariableManager.MIRootVariableObject.update somehow needs to know which children are visible and which are not.

Therefore, I'm currently trying to figure out:
  - Where should I place code that checks which children TreeItems are visible? (ExpressionVMProviderModelProxyStrategy?
GDBExpressionVMProvider? ...)
  - What would be a good way to pass this information to MIVariableManager? (By dedicated public members of MIVariableManager?)

I think an alternative question is "is this TreeItem collapsed or not" - I recall writing scary code to detect this with CDI,
but I don't know how do to it with DSF.

- Volodya

Vladimir Prus
CodeSourcery / Mentor Graphics

Back to the top