From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15126 invoked by alias); 17 Nov 2005 19:42:30 -0000 Received: (qmail 15118 invoked by uid 22791); 17 Nov 2005 19:42:28 -0000 Received: from fra-del-02.spheriq.net (HELO fra-del-02.spheriq.net) (195.46.51.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 19:42:28 +0000 Received: from fra-out-01.spheriq.net (fra-out-01.spheriq.net [195.46.51.129]) by fra-del-02.spheriq.net with ESMTP id jAHJgObQ005709 for ; Thu, 17 Nov 2005 19:42:24 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-01.spheriq.net with ESMTP id jAHJgNMn030516 for ; Thu, 17 Nov 2005 19:42:24 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id jAHJgL8b018602 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Nov 2005 19:42:21 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 237C5DA41; Thu, 17 Nov 2005 19:42:19 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 470E247566; Thu, 17 Nov 2005 19:45:18 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 0743575994; Thu, 17 Nov 2005 19:45:17 +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 773C84755E; Thu, 17 Nov 2005 19:45:17 +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 CGZ48026 (AUTH "andrew stubbs"); Thu, 17 Nov 2005 19:42:17 GMT Message-ID: <437CDC7D.1010404@st.com> Date: Thu, 17 Nov 2005 19:54:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Fixup convenience variables on endian switch References: <437B4291.3050006@st.com> <20051117034505.GA3057@nevyn.them.org> <437C79F7.9080404@st.com> <8f2776cb0511171058y365da93y26bc50eaa43d928d@mail.gmail.com> <20051117190240.GA19136@nevyn.them.org> In-Reply-To: <20051117190240.GA19136@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/msg00300.txt.bz2 Daniel Jacobowitz wrote: >>So you only really need to preserve convenience variables whose types >>are builtin types, and don't go away when symbol tables are reloaded. >>Wouldn't it be simpler just to have clear_internalvars only clear >>variables whose types belong to objfiles? Unless I am mistaken even builtin types have to be refreshed. It is a long time since I did this work, but I'm sure they are not as simple as you make out. At least, they didn't use to be ... this work originally comes from a 5.3 baseline. > I think you've switched patches - this is about updating variables on > an endianness switch, not clearing them when we reload. I think that > one way or another, we ought to preserve the values or discard the > convenience variables; leaving them corrupted fails my "can I explain > this behavior to a user" test. The current behaviour is to leave them corrupted. >>Or you could define a hook that runs a user-defined command when the >>architecture changes. Then your script could define a command that >>sets up your variables, and have GDB run that command when the >>architecture is known. We'd have to think about the best time to run >>the hook, but I'm sure something reasonable could be worked out. This doesn't actually seem easier - I have already done the work one way and it is totally reliable for builtin types (once configured for each host anyway). It also makes the user interface considerably less friendly and then there's there's Daniel's test to be passed - the user will say "why can't it Just Work?" > Just seems nasty. Why not preserve things that we know how to > preserve, and clear anything we don't? We know how to preserve > scalars by reading them into a LONGEST, and floats by reading them into > a DOUBLEST. Structures require complicated recursion and unions are > intractable. I would prefer we didn't actually clear the value - we currently get it back if the endian switches again. The more I think about this the more I think it might be nice to preserve the value of difficult types in the background, should the endian switch back (or type return from the dead), and present the value to the user as a message '$v = void ' (or '$v = void '). Just a thought .... Andrew