Started to fixup cppdebugger in trunk/kdevelop

[Vladimir Prus]

On Monday 09 February 2009 01:58:12 Andreas Pakulat wrote:
> On 08.02.09 23:26:17, Andreas Pakulat wrote:
> > Hi,
> > 
> > just a short "I got something useful done" message here, namely showing
> > local variables in the variable widget. There's a pretty obvious bug
> > and also variables are visible that are not defined at the "current"
> > position of execution.
> 
> Ok, fixed that bug. But one other thing thats still problematic: When
> switching from one frame to the next I'll have to remove all variables
> from the tree and I'm not quite sure what the plan was to make this
> work.
> 
> As far as I understood the old code actually kept the list of "current"
> variables around for each frame it has seen and then just switched to
> the current frame's variable list.
> 
> Is that still the current design decision, or should this be done
> differently? If so how?

First of all -- why do we ever need to try keeping variables around?
The primary goal is so that if you have expanded variable 'foo' in some
thread/frame, and then have picked 'octal' format for the first child
of that variable, and picked 'vector' rendering for the second child,
you want those choices to be preserved when you select that thread/frame
again, and in general, when you look at the 'same' variable 'foo', for
some reasonable definition of 'same'.

In KDevelop 3, the definition of 'same' was that thread and frame are
the same and the executable was not resumed in between. This definition
is not ideal -- for example if you hit a breakpoint, resume, program
works for a while and then you hit the same breakpoint, you probably
want to preserve the rendering of the variables. And KDevelop is not
in the best position to figure if a variable is same, or not, because
doing so requires knowing about debug info.

So, the plan is that after each thread/frame change or stop, KDevelop
should ask GDB about local variables in the current scope, and GDB
will do, for each variable, one of those 3 things:

  1. create new variable object for a local variable and report it. Then,
  we create new Variable instance and add it to model
  2. report a previously-created variable object as a variable that is in
  scope. This means that to the best of GDB knowledge, this variable is
  the same as variable that was already previously shown, and KDevelop
  should try to render it in exactly the same way as user wanted the last
  time. 
  3. report that a previously-created variable object will not be returned
  by further queries for local variables. This could be because the symbol
  disappeared from the program completely and the program was recompiled,
  or the symbol belongs to a shared library that is unloaded and GDB cannot
  check for symbol equality across solib unload/load, or because GDB ran out
  of memory trying to track variables.

I am not exactly sure if (3) should be done in GDB or be a policy in frontend,
but it's a detail.

For this mechanism to work, KDevelop should keep a cache of Variable object
indexed by varobj name. In fact, it already does, and Variable::findByName
returns Variable given varobj name. Not every Variable object need to be in
the model (with VariablesRoot as root) -- those not in the model won't be 
displayed. Some of the UI-relevant properties, such as hex/dec format is kept
by GDB together with other varobj data, whilst some UI properties, such as
whether a variable is expanded need to be kept by the frontend -- either inside
Variable, or in a separate map indexed by Variable (and maybe mainwindow instance).

At each step, KDevelop will issue a GDB command to get the above information.
For created varobjs, new Variable instances are created. Then, for all varobjs
reported to be in scope (both newly created and previously existing), we use
Varobj::findByName to get Variable instances, and replace the current childrens
of 'locals' item with those. 

Now, the problem is that GDB-side solution is not coded yet, so what do we do
now? I think that:

1. It's safe to assume that we'll issue a GDB command at each step to get the
list of locals.
2. We'll need to implement reuse of Variable instances as explained above, but
this really depends on GDB.

So, right now it's OK to assume that all variables are dead at each step -- which
is what you have done.

- Volodya