Re: [PATCH] Fixup internal variables' endian (again)

[Daniel Jacobowitz <drow@false.org>]

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