From: Andrew STUBBS <andrew.stubbs@st.com>
To: GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fixup internal variables' endian (again)
Date: Fri, 31 Mar 2006 14:16:00 -0000 [thread overview]
Message-ID: <442D0677.30208@st.com> (raw)
In-Reply-To: <20060330151255.GA29860@nevyn.them.org>
[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]
Daniel Jacobowitz wrote:
> 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.
Ah well, there's always another, more devious, way to do everything.
But, as you say, once the symbol table is loaded there ought to be no
endian issues unless the user brings it on themselves.
The patch solves the problem where built-in types are set before the
file is loaded, which is what I wanted to fix.
>> 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.
Well, I've tested it on x86 and sh4, and on both those platforms you can
'set endian ..' as much as you like and the floats are always shown
correctly. On a Sparc the numbers do come through garbled in the wrong
endian.
> Could you put spaces around the equals signs, please.
>
> OK with that change.
Thanks, committed with that change.
The final patch is attached.
Andrew Stubbs
[-- Attachment #2: endian.patch --]
[-- Type: text/plain, Size: 3174 bytes --]
2006-03-31 Andrew Stubbs <andrew.stubbs@st.com>
* 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-02-01 23:14:10.000000000 +0000
+++ src/gdb/value.c 2006-03-31 11:10:21.000000000 +0100
@@ -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,46 @@ struct value *
value_of_internalvar (struct internalvar *var)
{
struct value *val;
+ int i, j;
+ gdb_byte temp;
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.
+
+ Internal variables usually hold simple scalar values, and we can
+ correct those. More complex values (e.g. structures and floating
+ point types) are left alone, because they would be too complicated
+ to correct. */
+
+ if (var->endian != TARGET_BYTE_ORDER)
+ {
+ gdb_byte *array = value_contents_raw (val);
+ struct type *type = check_typedef (value_enclosing_type (val));
+ switch (TYPE_CODE (type))
+ {
+ case TYPE_CODE_INT:
+ case TYPE_CODE_PTR:
+ /* Reverse the bytes. */
+ for (i = 0, j = TYPE_LENGTH (type) - 1; i < j; i++, j--)
+ {
+ temp = array[j];
+ array[j] = array[i];
+ array[i] = temp;
+ }
+ break;
+ }
+ }
+
return val;
}
@@ -809,6 +844,7 @@ set_internalvar (struct internalvar *var
long. */
xfree (var->value);
var->value = newval;
+ var->endian = TARGET_BYTE_ORDER;
release_value (newval);
/* End code which must not call error(). */
}
@@ -877,7 +913,8 @@ 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-01 23:14:10.000000000 +0000
+++ src/gdb/value.h 2006-03-30 11:17:29.000000000 +0100
@@ -245,6 +245,7 @@ struct internalvar
struct internalvar *next;
char *name;
struct value *value;
+ int endian;
};
\f
prev parent reply other threads:[~2006-03-31 10:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-03 21:39 Andrew STUBBS
2006-03-30 0:17 ` Daniel Jacobowitz
2006-03-30 14:16 ` Andrew STUBBS
2006-03-30 16:25 ` Daniel Jacobowitz
2006-03-31 14:16 ` Andrew STUBBS [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=442D0677.30208@st.com \
--to=andrew.stubbs@st.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox