From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16053 invoked by alias); 17 Nov 2005 19:02:51 -0000 Received: (qmail 16045 invoked by uid 22791); 17 Nov 2005 19:02:48 -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 19:02:48 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Ecp1s-00050b-7N; Thu, 17 Nov 2005 14:02:40 -0500 Date: Thu, 17 Nov 2005 19:25:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Andrew STUBBS , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Fixup convenience variables on endian switch Message-ID: <20051117190240.GA19136@nevyn.them.org> Mail-Followup-To: Jim Blandy , Andrew STUBBS , gdb-patches@sources.redhat.com References: <437B4291.3050006@st.com> <20051117034505.GA3057@nevyn.them.org> <437C79F7.9080404@st.com> <8f2776cb0511171058y365da93y26bc50eaa43d928d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f2776cb0511171058y365da93y26bc50eaa43d928d@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/msg00291.txt.bz2 On Thu, Nov 17, 2005 at 10:58:51AM -0800, Jim Blandy wrote: > On 11/17/05, Andrew STUBBS wrote: > > The problem I am actually trying to solve is that we have addresses and > > such set up by a script that is sourced before the endian of the target > > they will be used with is known. > > 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? 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. > 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. 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. -- Daniel Jacobowitz CodeSourcery, LLC