This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] keeping convenience variables (take 2)
- From: Jim Blandy <jimb at red-bean dot com>
- To: Andrew STUBBS <andrew dot stubbs at st dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 21 Nov 2005 21:38:21 -0800
- Subject: Re: [PATCH] keeping convenience variables (take 2)
- References: <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.