From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3057 invoked by alias); 17 Nov 2005 12:56:16 -0000 Received: (qmail 3046 invoked by uid 22791); 17 Nov 2005 12:56:14 -0000 Received: from lon-del-03.spheriq.net (HELO lon-del-03.spheriq.net) (195.46.50.99) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 12:56:14 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-03.spheriq.net with ESMTP id jAHCuBIc000767 for ; Thu, 17 Nov 2005 12:56:11 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-01.spheriq.net with ESMTP id jAHCu3LJ005812 for ; Thu, 17 Nov 2005 12:56:10 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id jAHCu2Fe005342 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Nov 2005 12:56:03 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 670B2DA46; Thu, 17 Nov 2005 12:55:58 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 762204747B; Thu, 17 Nov 2005 12:58:57 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3ABDE75994; Thu, 17 Nov 2005 12:58:57 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 2A03147487; Thu, 17 Nov 2005 12:58:54 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CGZ44913 (AUTH "andrew stubbs"); Thu, 17 Nov 2005 12:55:52 GMT Message-ID: <437C7D3D.1090905@st.com> Date: Thu, 17 Nov 2005 15:07:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Jim Blandy , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [PATCH] keep-variable command References: <437B44E1.8090008@st.com> <8f2776cb0511161528y372fde8cuaa7ddecf863f277a@mail.gmail.com> <20051117035532.GD3057@nevyn.them.org> In-Reply-To: <20051117035532.GD3057@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.1.07 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/msg00280.txt.bz2 Daniel Jacobowitz wrote: > 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. If it doesn't find a type for the variable it gives a message and sets the value to void. This would be irritating with a large number of variables you no longer care about. Otherwise I would agree with you. Perhaps instead of the message the value could somehow be shown as '', in which case it wouldn't matter so much. I was considering the possibility of keeping the value around on the off chance the type has come back the next time the variable is accessed. > 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. I have no idea what you just said, but if it avoids type fixup problems then that would be a good thing all round. Is it worth whatever effort it would take though? Is it instead of textual type remembering or instead of replacing the type at all? Andrew