From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2771 invoked by alias); 30 Mar 2006 15:13:02 -0000 Received: (qmail 2750 invoked by uid 22791); 30 Mar 2006 15:13:00 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 30 Mar 2006 15:12:59 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FOypT-000896-Nd; Thu, 30 Mar 2006 10:12:55 -0500 Date: Thu, 30 Mar 2006 16:25:00 -0000 From: Daniel Jacobowitz To: Andrew STUBBS Cc: GDB Patches Subject: Re: [PATCH] Fixup internal variables' endian (again) Message-ID: <20060330151255.GA29860@nevyn.them.org> Mail-Followup-To: Andrew STUBBS , GDB Patches References: <4408847C.9040907@st.com> <20060329232241.GD9916@nevyn.them.org> <442BBD9A.5020104@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <442BBD9A.5020104@st.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes 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: 2006-03/txt/msg00363.txt.bz2 On Thu, Mar 30, 2006 at 12:14:34PM +0100, Andrew STUBBS wrote: > Having taken some time looking into this I thought that doing a brain > dump might be useful to other people. It's not that structs 'are too > complicated to correct' - AFAICT they are almost always right because > they require target memory to exist. The user has to go out of their way > to confuse the debugger before they are wrong. Sorry, what I was trying to imply is that this might be a property of the current GDB implementation, and for C, but I don't think it's a reliable assumption into the future. Creating a non-lazy internal variable of struct type is as simple as: (gdb) print args (gdb) set $foo = $1 You don't need a target for that; a symbol file will do. And it will last after disconnecting from one target and connecting to another. You can do it without reading from the symbol file's memory too: set $bar = (struct captured_main_args){1} Vector registers have struct types, too, but without a symbol file you currently can't get at that type. So, if you've got a symbol file and the endianness is set wrong, you can do this. I guess that counts as going out of their way, but it doesn't match what you wrote originally, which was that you could never produce such internalvars. > As to the second point, why shouldn't people fix up broken values? If it > is displayed incorrectly then that is a bug and the comment says that > this is the place to fix it. People wouldn't have to 'add floating point > support' as such, merely reverse the byte order of some binary data. Except that's just not enough. It depends on the floatformat. We'd need for each architecture to specify the big and little endian floatformats, instead of the current endianness floatformat. Well, or define a new gdbarch hook; investigating the supported floatformats it might work for everything but ARM. OK, I take it back, it's easier than it looks. > It > just so happens that the only scalar data not currently handled is > floating point (AFAIK). Have you looked at the TYPE_CODE_* values? TYPE_CODE_ENUM, TYPE_CODE_FLAGS, TYPE_CODE_FLT, TYPE_CODE_REF, TYPE_CODE_BOOL, TYPE_CODE_RANGE, and I'm not sure about sets/bitstrings, but those aren't used much now. > I don't actually know of a host/target where > this is a problem, but I'm sure there are some out there. Where switching endianness affects the floating point format? Everything but ARM FPA, as far as I know. > Updated patch attached. I also noticed that I was using both type and > enclosing_type - I don't think there was any reason for that so both now > use enclosing type. Good catch. > + for (i=0, j=TYPE_LENGTH (type) - 1; i < j; i++, j--) Could you put spaces around the equals signs, please. OK with that change. -- Daniel Jacobowitz CodeSourcery