Re: [PATCH] Fixup convenience variables on endian switch

[Andrew STUBBS <andrew dot stubbs at st dot com>]

Daniel Jacobowitz wrote:
> In addition to Jim's question about structures, and the overall
> question of whether this is worth doing...
>
> On Wed, Nov 16, 2005 at 02:30:41PM +0000, Andrew STUBBS wrote:
>
> > +  /* Don't do anything if the endian has not changed.
> > +     Also disregard FP types because they don't seem to vary with
> > +     endian - at least, not on i686 Linux or sparc Solaris.  */
>
>
> That's not correct.  The only reason it appears that way is because
> those targets normally support only one endian, so their gdbarch system
> only selects one set of floatformats.  Changing endianness can change
> the layout of the standard floating point types arbitrarily.

OK, so as it is floats work on x86 Linux, sparc Solaris and any other 
platform that happens to do it the same way. On other targets the 
situation is no worse (no different) than it is now.

Is there anything I can do to make this better? If there is no 
definitive way then maintainers/interested parties can always fix it per 
host as they see the problem. A comment to that effect can certainly go in.

As to the struct problem, I admit I had not considered that one. A test 
for it must go in of course.

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.

It seems like quite a lot of effort to recursively walk through a stuct. 
This is probably more because I don't know how than anything else. I am 
sure it is possible.

Also, there are unions to consider. These are even harder because the 
requirement that ints are flipped and floats remain the same (on some 
hosts) is incompatible.

I propose to add a test for struct and union types (bitfields? any 
others?) and leave them alone. Pointers to these types will continue to 
work properly of course.

Andrew