Re: [PATCH:MI] Return a subset of a variable object's children

André Pönitz
2008-05-05T09:56:07Z

On Thursday 01 May 2008 08:27:10 you wrote:
> > > Are you arguing against the general concept of variable objects?
> >
> > Erm... yes. Could be seen as such.
>
> With respect, I'm not sure that you know what you are talking about.
>
> The concept of variable objects predates MI and was take from Insight. It hasn't
> been developed overnight but over a long time by experienced Gdb developers,
> i.e, not the likes of me.

[With respect, I never was very fond of "proof by authority". Anyway, maybe
I should have mentioned "for my usage pattern" or "in my environment"
a bit more often. Sorry for that. Having said that, it's not uncommon that
new approaches render venerable code once deviced by venerable people
obsolete. For me it looks like the new Python interface has a huge potential
in this direction...]

> > > ...
> > > Presumably your one-shot 'children listing' requires all values to be
> > > printed each time. Variable objects work by just printing the values
> > > which have changed.
> >
> > I am fully aware of that. It has a very limited utility, though...
> >
> > I basically have to fill, say, 20 lines in the typical 'Locals & Watchers'
> > view.
> >
> > With a one-shot approach I can fire off 20 simple request, getting back
> > 20 simple results (say, a total of 1000 bytes of data) compare them with
> > the previous results myself, re-populate the view, mark changes etc.
> > No big deal as it happens at most once per user interaction. Easy and
> > predictable.
>
> How do you know if an expression is still in scope? How do you know that
> an original variable is not currently shadowed by another with the same name?
> How do you know how many elements are in an array, members in a structure?
> These are some of the questions that variable objects address.

Well, given that I have a 'program counter position' in each stack frame
on the current stack and that I do 'one-shot' evaluations I would expect
an expression to be evaluated in that context. Not being able to access
shadowed variables does hurt _me_ not much. It's definitely less harmful
than, say, getting no local variable information for constructor bodies.

Apart from that, I do not even know whether a C++ object has already
been constructed and whether it's safe to access it's members.
Lately a coworker had a funny case (gdb 6.5 on MinGW IIRC) that accessing
a variable in one stack frame and a reference to it in another yielded
different values (same address, non-reproducable but witnessed by
half a dozen people). I also better do a stack down and up before
asking any hard questions about the current frame on MinGW as the
information then just has a tendency to look better. Not to mention
that I grow accustomed to ignore any reports for frames at line 150
in stl_algobase.h. Etc...

I am not complaining. At all. Gdb is much more reliable and fun to work
with than some other debuggers. Believe me, If I had the impression I
could do your job (or even a part of that part that I am aware of) I would
have probably tried ;-)

So really no offense meant. I am just trying to illustrate my point that I
do not expect a 100% perfect solution, and that I am therefore willing
to trade _the potential_ of getting a 100% perfect solution (which I
consider a non-achievable illusion anyway) for an easy-to-use solution
that is not too far off. I mean, nobody uses _debugger output_ to actually
_steer_ mission critical applications. The debugger is just a means to collect
information. If one piece of information is missing or even wrong, well, so
be it. The application itself can still be fixed. Mission accomplished ;-)

> > With the 'update notifications' I get an unpredictable amount of data
> > (there could be an array with a few thousand children after all, all
> > being changed, stalling my communication line for an unpredicatable
> > amount of time),
>
> This is what we're currently discussing: ways to ensure that thousands of
> variable objects aren't created when viewing arrays with thousands of elements.
>
> > _and_ the data I get is insufficient as it, for instance,
> > does not tell me that a std::string has changed somewhere in the middle.
> > So I need to do a few 'one-shot evaluations' anyway to get the desired
> > results. All in all, less satisfactory.
>
> And maybe the Python interface can address this.

Indeed. But deploying the Python interface "for everything" starting with
listing the locals, running custom visualizers on all of them etc basically
means "no need for varobjects anymore". Which fits, more or less,
into my (limited, as you noticed) view of the world ;-)

Regards,
Andre'