From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14035 invoked by alias); 3 Mar 2006 18:04:07 -0000 Received: (qmail 14027 invoked by uid 22791); 3 Mar 2006 18:04:07 -0000 X-Spam-Check-By: sourceware.org Received: from fra-del-01.spheriq.net (HELO fra-del-01.spheriq.net) (195.46.51.97) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 03 Mar 2006 18:04:05 +0000 Received: from fra-out-01.spheriq.net (fra-out-01.spheriq.net [195.46.51.129]) by fra-del-01.spheriq.net with ESMTP id k23I41JB017357 for ; Fri, 3 Mar 2006 18:04:01 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 k23I3w9j002504 for ; Fri, 3 Mar 2006 18:04:01 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 k23I3vZM028181 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 3 Mar 2006 18:03:57 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 17FFCDA46 for ; Fri, 3 Mar 2006 18:03:57 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 5CBC1474B1 for ; Fri, 3 Mar 2006 18:07:45 +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 CHI14119 (AUTH stubbsa); Fri, 3 Mar 2006 18:03:55 GMT Message-ID: <4408847C.9040907@st.com> Date: Fri, 03 Mar 2006 21:39:00 -0000 From: Andrew STUBBS User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: GDB Patches Subject: [PATCH] Fixup internal variables' endian (again) Content-Type: multipart/mixed; boundary="------------000003090703060408070408" 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.2.01 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/msg00082.txt.bz2 This is a multi-part message in MIME format. --------------000003090703060408070408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1322 Hi all, This is a rework of a patch I submitted last autumn. I have updated it to fit with the new convenience variable preservation and rethought the requirements. The patch fixes up the endian of all integer and pointer internal variables and leaves all other types alone. My understanding is that an internal variable cannot contain anything other than a built-in type. Any other value is merely a memory reference. Indeed, value_of_internalvar() goes out of it's way to ensure that values loaded from memory are never saved long term. The result is that there is no point in attempting to do anything with the endian of these values because they will always be of the same endian as the target/program being debugged. The upshot is that, although it is possible to contrive an example [1] that causes gdb to print values in the wrong endian, in the normal case, in which the user does not change the endian except upon connection to the target, the values will always be presented as they expect. Including internal variables written prior to connection. [1] Once connected to the target, write data in endian A, create a variable referencing that data, type 'set endian B' and the print the data - it comes out reversed. If I have something wrong here please point it out. Thanks Andrew Stubbs --------------000003090703060408070408 Content-Type: text/plain; name="endian.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="endian.patch" Content-length: 3380 2006-03-03 Andrew Stubbs * value.h (struct internalvar): Add field 'endian'. * value.c (lookup_internalvar): Initialise endian. (value_of_internalvar): Flip the endian of built-in types if required. (set_internalvar): Set the endian. (show_convenience): Access the value through value_of_internalvar(). Index: src/gdb/value.c =================================================================== --- src.orig/gdb/value.c 2006-03-03 17:16:03.000000000 +0000 +++ src/gdb/value.c 2006-03-03 17:16:20.000000000 +0000 @@ -755,6 +755,7 @@ lookup_internalvar (char *name) var = (struct internalvar *) xmalloc (sizeof (struct internalvar)); var->name = concat (name, (char *)NULL); var->value = allocate_value (builtin_type_void); + var->endian = TARGET_BYTE_ORDER; release_value (var->value); var->next = internalvars; internalvars = var; @@ -765,12 +766,49 @@ struct value * value_of_internalvar (struct internalvar *var) { struct value *val; + int i, j; + gdb_byte temp; + gdb_byte *array; val = value_copy (var->value); if (value_lazy (val)) value_fetch_lazy (val); VALUE_LVAL (val) = lval_internalvar; VALUE_INTERNALVAR (val) = var; + + /* Values are always stored in the target's byte order. When connected to a + target this will most likely always be correct, so there's normally no + need to worry about it. + + However, internal variables can be set up before the target endian is + known and so may become out of date. Fix it up before anybody sees. + + Since internal variables cannot hold complex types, such as structs, + unions, arrays and strings - those are always held in target memory and + the variable just holds a reference, there is no need to worry about + those either. + + Floating point values vary differently across endianness - many targets + just keep them the same. If they do no work correctly on your host/target + then add support as required here. */ + if (var->endian != TARGET_BYTE_ORDER) + { + array = value_contents_raw (val); + switch (TYPE_CODE (value_type (val))) + { + case TYPE_CODE_INT: + case TYPE_CODE_PTR: + /* Reverse the bytes. */ + for (i=0,j=TYPE_LENGTH (value_enclosing_type (val))-1; ivalue); var->value = newval; + var->endian = TARGET_BYTE_ORDER; release_value (newval); /* End code which must not call error(). */ } @@ -877,7 +916,7 @@ show_convenience (char *ignore, int from varseen = 1; } printf_filtered (("$%s = "), var->name); - value_print (var->value, gdb_stdout, 0, Val_pretty_default); + value_print (value_of_internalvar (var), gdb_stdout, 0, Val_pretty_default); printf_filtered (("\n")); } if (!varseen) Index: src/gdb/value.h =================================================================== --- src.orig/gdb/value.h 2006-02-20 18:39:55.000000000 +0000 +++ src/gdb/value.h 2006-03-03 15:11:42.000000000 +0000 @@ -245,6 +245,7 @@ struct internalvar struct internalvar *next; char *name; struct value *value; + int endian; }; --------------000003090703060408070408--