This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] keep-variable command
- From: Jim Blandy <jimb at red-bean dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: Andrew STUBBS <andrew dot stubbs at st dot com>, gdb-patches at sources dot redhat dot com
- Date: Wed, 16 Nov 2005 15:28:27 -0800
- Subject: Re: [PATCH] keep-variable command
- References: <437B44E1.8090008@st.com> <u7jb873tj.fsf@gnu.org>
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?