Daniel Jacobowitz wrote:
> So, just minor comments.
> 
>> +  /* 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.  */
> 
> How do you feel about replacing those last two paragraphs with:
> 
>     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.
> 
> I don't think we really want someone to fix this by adding floating
> point support.

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.

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. It
just so happens that the only scalar data not currently handled is
floating point (AFAIK). I don't actually know of a host/target where
this is a problem, but I'm sure there are some out there.

In fact, it might be as simple as:

          {
          case TYPE_CODE_INT:
          case TYPE_CODE_PTR:
+#ifdef ENDIAN_SENSITIVE_FLOATS
+	 case TYPE_CODE_FLOAT:
+#endif
            /* Reverse the bytes.  */
            for (i=0,j=TYPE_LENGTH (value_enclosing_type (val))-1; i<j;
i++,j--)

Anyway, at the end of the day it's just a comment, your text works, and
if anybody wants to fix something they don't need a comment to give them
permission.

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.

Andrew