This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] keep-variable command


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?  :)

Let me answer Eli's questions first:

On 11/16/05, Eli Zaretskii <eliz@gnu.org> wrote:
> > +types are lost so their value would become meaningless.  This can be avoided
> > +using the @samp{keep-variable} command below.
>
> It's possible this is something I never knew about: is it actually
> correct that _all_ convenience variables are deleted when `file' is
> used?  The explanation above about their types being lost doesn't make
> sense to me; can you explain?  For example, if I define a variable
> that holds an integer number, why would its type become meaningless?

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.

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.

But Andrew's going way farther than that: he's actually trying to keep
convenience variables whose types definitely belong to the symfile
that's being reloaded.  Very ambitious.

Okay, back to Andrew's patch.

- 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.

- 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?

Do you really need all this?  Can you tell us more about the situation?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]