From: Jim Blandy <jimb@red-bean.com>
To: Andrew STUBBS <andrew.stubbs@st.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] keeping convenience variables (take 2)
Date: Tue, 22 Nov 2005 08:43:00 -0000 [thread overview]
Message-ID: <8f2776cb0511212138g2adef40cr1632365c00e3bebc@mail.gmail.com> (raw)
In-Reply-To: <4381DC75.80800@st.com>
I may be missing something, be patient:
If I understand the original motivation for this, you don't actually
need to keep around any values that aren't using the builtin types.
Or at least, that could be using the built-in types; it wasn't clear
whether they actually did.
I'm uncomfortable with this whole "print type name and then re-parse
later" approach. I think it's a real kludge. And the fact that it
doesn't seem really necessary for the problem that originally
motivated the change is a red flag, it seems to me.
I can certainly see that it's useful to keep the convenience variables
around across symfile selections and endianness switches; I just think
we should find a better way to handle the types than this.
If the convenience variables you set up in your script, holding
addresses and such, don't refer to the builtin types, why don't they?
Could they? I understand that changing architectures or
architectural variants affects the builtin types, but it seems more
feasible to track those changes than to try to track objfile-based
types as they disappear and reappear.
next prev parent reply other threads:[~2005-11-22 5:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-21 22:05 Andrew STUBBS
2005-11-22 4:58 ` Eli Zaretskii
2005-11-22 8:43 ` Jim Blandy [this message]
2005-11-22 19:27 ` Andrew STUBBS
2005-12-10 4:46 ` [RFC] Alternate approach to keeping convenience variables Daniel Jacobowitz
2005-12-10 5:07 ` Jim Blandy
2005-12-10 8:24 ` Daniel Jacobowitz
2005-12-10 22:20 ` Jim Blandy
2005-12-11 18:12 ` Eli Zaretskii
2005-12-11 19:17 ` Eli Zaretskii
2006-01-23 22:29 ` Jim Blandy
2006-01-24 11:44 ` Andrew STUBBS
2006-01-24 18:41 ` Jim Blandy
2006-01-24 18:43 ` Daniel Jacobowitz
2006-01-24 19:16 ` Jim Blandy
2006-01-24 19:24 ` Daniel Jacobowitz
2006-01-25 0:13 ` Jim Blandy
2006-01-24 19:45 ` Andrew STUBBS
2006-01-04 12:17 ` Andrew STUBBS
2006-01-04 17:00 ` Jim Blandy
2006-01-04 17:48 ` Andrew STUBBS
2006-01-04 18:37 ` Jim Blandy
2006-01-22 21:04 ` Daniel Jacobowitz
2006-01-22 21:31 ` Daniel Jacobowitz
2006-01-23 22:46 ` Jim Blandy
2006-01-27 17:53 ` Eli Zaretskii
2006-01-27 18:12 ` Jim Blandy
2006-01-27 18:29 ` Eli Zaretskii
2006-01-27 18:41 ` Joel Brobecker
2006-02-01 23:14 ` Daniel Jacobowitz
2006-02-02 4:18 ` Eli Zaretskii
2006-02-06 22:14 ` 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=8f2776cb0511212138g2adef40cr1632365c00e3bebc@mail.gmail.com \
--to=jimb@red-bean.com \
--cc=andrew.stubbs@st.com \
--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