Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@red-bean.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Andrew STUBBS <andrew.stubbs@st.com>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH] keep-variable command
Date: Thu, 17 Nov 2005 01:07:00 -0000	[thread overview]
Message-ID: <8f2776cb0511161528y372fde8cuaa7ddecf863f277a@mail.gmail.com> (raw)
In-Reply-To: <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?


  reply	other threads:[~2005-11-16 23:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-16 15:54 Andrew STUBBS
2005-11-16 20:26 ` Eli Zaretskii
2005-11-17  1:07   ` Jim Blandy [this message]
2005-11-17  9:56     ` Daniel Jacobowitz
2005-11-17 15:07       ` Andrew STUBBS
2005-11-17 12:42     ` Andrew STUBBS
2005-11-17 12:26   ` Andrew STUBBS
2005-11-17 19:33     ` Eli Zaretskii
2005-11-17 19:36       ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8f2776cb0511161528y372fde8cuaa7ddecf863f277a@mail.gmail.com \
    --to=jimb@red-bean.com \
    --cc=andrew.stubbs@st.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox