From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19874 invoked by alias); 22 Nov 2005 05:38:26 -0000 Received: (qmail 19541 invoked by uid 22791); 22 Nov 2005 05:38:25 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 Nov 2005 05:38:23 +0000 Received: by zproxy.gmail.com with SMTP id l1so967947nzf for ; Mon, 21 Nov 2005 21:38:21 -0800 (PST) Received: by 10.36.177.11 with SMTP id z11mr3685883nze; Mon, 21 Nov 2005 21:38:21 -0800 (PST) Received: by 10.37.2.35 with HTTP; Mon, 21 Nov 2005 21:38:21 -0800 (PST) Message-ID: <8f2776cb0511212138g2adef40cr1632365c00e3bebc@mail.gmail.com> Date: Tue, 22 Nov 2005 08:43:00 -0000 From: Jim Blandy To: Andrew STUBBS Subject: Re: [PATCH] keeping convenience variables (take 2) Cc: gdb-patches@sources.redhat.com In-Reply-To: <4381DC75.80800@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4381DC75.80800@st.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00403.txt.bz2 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.=20 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?=20 Could they? I understand that changing architectures or=20 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.