From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1189 invoked by alias); 17 Nov 2005 03:55:38 -0000 Received: (qmail 1181 invoked by uid 22791); 17 Nov 2005 03:55:36 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 03:55:36 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Ecas0-0000sN-IE; Wed, 16 Nov 2005 22:55:32 -0500 Date: Thu, 17 Nov 2005 09:56:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Eli Zaretskii , Andrew STUBBS , gdb-patches@sources.redhat.com Subject: Re: [PATCH] keep-variable command Message-ID: <20051117035532.GD3057@nevyn.them.org> Mail-Followup-To: Jim Blandy , Eli Zaretskii , Andrew STUBBS , gdb-patches@sources.redhat.com References: <437B44E1.8090008@st.com> <8f2776cb0511161528y372fde8cuaa7ddecf863f277a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f2776cb0511161528y372fde8cuaa7ddecf863f277a@mail.gmail.com> User-Agent: Mutt/1.5.8i 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/msg00265.txt.bz2 On Wed, Nov 16, 2005 at 03:28:27PM -0800, Jim Blandy wrote: > 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? :) I haven't even looked at the implementation yet; I'd like to talk about the concept first. For one thing, why is this a command at all? If we support keeping convenience variables across symbol file reloads, then why not do it by default for all convenience variables? I doubt having them disappear has ever been considered a feature. > 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. This is a bit complicated by the fact that the objfile may define a type named "int", so some care is in order... > 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. If true, this does improve things a bit. Of course, pointers are just as much of a problem. > - 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. Alternatively, we could add code to duplicate the types recursively onto a convenience variable obstack. GDB doesn't have much of a notion of "type compatibility". It might not work 100% right for things like C++ operator overloading, but for that we'd need to do type merging anyway. > - 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? This is a pre-existing disaster zone. We have similar problems for resetting breakpoints, IIRC (or else will eventually). -- Daniel Jacobowitz CodeSourcery, LLC