Started to fixup cppdebugger in trunk/kdevelop

[Vladimir Prus]

On Tuesday 10 February 2009 23:23:03 Andreas Pakulat wrote:
> On 09.02.09 09:16:13, Vladimir Prus wrote:
> > So, the plan is that after each thread/frame change or stop, KDevelop
> > should ask GDB about local variables in the current scope,
>
> This is -stack-list-locals in gdb mi,
> right?

Yeah, that's the only command in current GDB.

> > 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
>
> Where variable object is what one can do manually with -var-create in
> gdb mi?

Yes.

> > Now, the problem is that GDB-side solution is not coded yet, so what do
> > we do now? I think that:
>
> Yeah, I noticed 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.
>
> No, in fact what I did is re-use variables and variable-items all the
> time. And I'm not removing variables at all right now. So if a variable
> goes out of scope while stepping its not removed.

Ouch.

> The question is: Is it easier/efficient enough, to simply remove all
> variables that are not used for a watch each time we have a frame or
> thread change. Or should we keep the existing code to re-use Variable's
> and VariableItem's and check which of them are not in the list of locals
> on each frame/thread change?

I think until GDB solution is implement, it's fine to remove all non-watch
variables on thread and frame change. Please note that whilst comparing
threads for equality is just comparing their ids, comparing frames for
equality is not as easy -- frame level obviously cannot be used for that
purpose. KDevelop3 used to issue "info frame" command and extract
a more reliable id from that -- we still have that code somewhere.

When GDB solution is implemented, tweaking kdevelop will be easy.

- Volodya