Re: Variable objects and STL containers

> From: Vladimir Prus <ghostcs.msu.su>
> Date:  Tue, 05 Feb 2008 09:16:53 +0300
> 
> Technically, there is formal interface, called
iterators, provided by the
> C++ standard. I don't have the slightest confidence in
gdb not falling over
> if you try to use them, though.

That means that you actually have to call functions in the
inferior,
which might modify state you don't want to modify.  And of
course it
doesn't work at all for core dumps.

> We discussed using Python scripting for that; in fact,
I have a patch locally
> that will make 
> 
>         -var-evaluate-expression V 
> 
> for a vector print something like:
> 
>         [1,2,3]
> 
> I'm working on making those element the children of the
variable object,
> but it's not done yet.

Still this means that you'll need to write python code for
each and
every STL implementation, and play catchup whenever the
implementation
is changed.  I guess the only way to get this to work is to
connvince
the GCC people to maintain the python code together with
libstdc++.

On Tuesday 05 February 2008 14:31:07 Mark Kettenis wrote:
> > From: Vladimir Prus <ghostcs.msu.su>
> > Date:  Tue, 05 Feb 2008 09:16:53 +0300
> > 
> > Technically, there is formal interface, called
iterators, provided by the
> > C++ standard. I don't have the slightest
confidence in gdb not falling over
> > if you try to use them, though.
> 
> That means that you actually have to call functions in
the inferior,
> which might modify state you don't want to modify. 

In theory, all called functions are supposed to be const
member functions,
so should not modify anything. In practice, they might still
touch some
memory (if that does not modify logical state of the
object), and if 
we're trying to calling functions on non-yet-initialized
object,
that might corrupt things.

(And IIUC, gcc still won't tell us when a C++ object is
initialized).

> And of course it 
> doesn't work at all for core dumps.

Yes.

> > We discussed using Python scripting for that; in
fact, I have a patch locally
> > that will make 
> > 
> >         -var-evaluate-expression V 
> > 
> > for a vector print something like:
> > 
> >         [1,2,3]
> > 
> > I'm working on making those element the children
of the variable object,
> > but it's not done yet.
> 
> Still this means that you'll need to write python code
for each and
> every STL implementation, and play catchup whenever the
implementation
> is changed.

In case of std::vector in GCC, I doubt many changes are
coming.

> I guess the only way to get this to work is to
connvince 
> the GCC people to maintain the python code together
with libstdc++.

Of course that would be ideal. However, libstdc++ is not the
only
standard library, and anyway -- having the mechanism is more
important
that who gets to write python code.

- Volodya

On Tue, Feb 05, 2008 at 12:31:07PM +0100, Mark Kettenis
wrote:
> > We discussed using Python scripting for that; in
fact, I have a patch locally
> > that will make 
> > 
> >         -var-evaluate-expression V 
> > 
> > for a vector print something like:
> > 
> >         [1,2,3]
> > 
> > I'm working on making those element the children
of the variable object,
> > but it's not done yet.
> 
> Still this means that you'll need to write python code
for each and
> every STL implementation, and play catchup whenever the
implementation
> is changed.  I guess the only way to get this to work
is to connvince
> the GCC people to maintain the python code together
with libstdc++.

Right.  That's what I would like to happen; and since GCC is
both a
GNU project and widely used with GDB, I think it will be
easy to
convince them.  I envision these scripts going in
/usr/share/gdb/packages or something similar to that.

-- 
Daniel Jacobowitz
CodeSourcery