How to keep vars
leonp at plris.com
Thu Jun 11 23:04:47 BST 2009
Just to remind - the only simple thing I asked was for the debugger interface
to remember that my structure X was expanded previously!
That is all!
On Thursday June 11 2009, Andre Poenitz wrote:
> On Thu, Jun 11, 2009 at 09:35:14PM +0200, Andreas Pakulat wrote:
> > > It is surely possible with any debugger as long as the GUI remembers
> > > what is open and re-create it as needed.
> > Well, the problem here is to know wether an item in the tree still exists
> > in the actual application. Which means we'd have to ask gdb for each
> > variable on all open subtree's if it still exists.
> One can just assume it's gone and delete/recreate it. That's wasteful
> but robust, and from what I can tell pretty much the best approach the
> current MI implementation "offers". The MI variables are not very well
> suited to handle C++ at all. (Who is _really_ interested in what MI
> considers a "child" of a std::vector? - not to mention that intermediate
> public/ protected/private level that MI spits out).
> > And as far as I know the last GDB MI version that KDevelop3 was
> > adjusted to use was anything but fast when retrieving tons of
> > variables.
> The expensive part does not really seem to be the number of commands,
> but the number of roundtrips through gdb, i.e. the times where you need
> to wait for a result of a response before formulating the next question.
> I've never seen a roundtrip below 30ms, even on the fastest machines,
> and things start feeling sluggish at ~150ms per step...
> > Hence doing that can be really expensive, especially if the
> > debugger doesn't tell you when a variable goes out of scope, you have
> > to do this refetching on each single step.
> Yes, would be nice if MI variables did their job, but at least from
> my perspective they don't..
> kdevelop mailing list
> kdevelop at kdevelop.org
More information about the KDevelop