From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8791 invoked by alias); 16 Nov 2005 23:28:32 -0000 Received: (qmail 8776 invoked by uid 22791); 16 Nov 2005 23:28:29 -0000 Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.205) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 16 Nov 2005 23:28:29 +0000 Received: by zproxy.gmail.com with SMTP id l1so2257491nzf for ; Wed, 16 Nov 2005 15:28:27 -0800 (PST) Received: by 10.37.15.74 with SMTP id s74mr6995884nzi; Wed, 16 Nov 2005 15:28:27 -0800 (PST) Received: by 10.37.2.35 with HTTP; Wed, 16 Nov 2005 15:28:27 -0800 (PST) Message-ID: <8f2776cb0511161528y372fde8cuaa7ddecf863f277a@mail.gmail.com> Date: Thu, 17 Nov 2005 01:07:00 -0000 From: Jim Blandy To: Eli Zaretskii Subject: Re: [PATCH] keep-variable command Cc: Andrew STUBBS , gdb-patches@sources.redhat.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <437B44E1.8090008@st.com> 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/msg00256.txt.bz2 On 11/16/05, Andrew STUBBS 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 wrote: > > +types are lost so their value would become meaningless. This can be a= voided > > +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 =3D 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?