[PATCH] keep-variable command

[Daniel Jacobowitz]

On Wed, Nov 16, 2005 at 03:28:27PM -0800, Jim Blandy wrote:
> On 11/16/05, Andrew STUBBS <andrew.stubbs@st.com> wrote:
> > I feel certain that there is something somebody will not like about this
> > implementation, but I hope we can sort it out.
> 
> How did you know?  :)

I haven't even looked at the implementation yet; I'd like to talk about
the concept first.

For one thing, why is this a command at all?  If we support keeping
convenience variables across symbol file reloads, then why not do it by
default for all convenience variables?  I doubt having them disappear
has ever been considered a feature.

> It wouldn't, necessarily; certainly GDB still knows the meaning of
> 'int' given only the current architecture and the current language.  I
> don't see any reason we couldn't keep a convenience variable if all
> its types belonged to objfiles (according to type->objfile) that we
> were going to keep around.

This is a bit complicated by the fact that the objfile may define a
type named "int", so some care is in order...

> I believe if you say "set var $foo = 1", then $foo's type is one of
> the builtin type objects, whose objfile is NULL.  There's no reason to
> throw away convenience variables all of whose types were like this.

If true, this does improve things a bit.  Of course, pointers are just
as much of a problem.

> - Converting types to strings needs to be done in a
>   language-independent manner.  It's a shame that types don't seem to
>   point to a language.  But it would be better to use LA_PRINT_TYPE
>   than to build the name by hand.

Alternatively, we could add code to duplicate the types recursively
onto a convenience variable obstack.  GDB doesn't have much of a notion
of "type compatibility".  It might not work 100% right for things like
C++ operator overloading, but for that we'd need to do type merging
anyway.

> - Types can be local to some scope.  Even if you print out a type's
>   name, how can you discover what scope to re-parse it in?  Right now
>   you're just getting whatever happens to be in
>   expression_context_block, right?

This is a pre-existing disaster zone.  We have similar problems for
resetting breakpoints, IIRC (or else will eventually).

-- 
Daniel Jacobowitz
CodeSourcery, LLC