Re: [RFC] decimal float point patch based on libdecnumber: gdb patch

[Wu Zhou <woodzltc@cn.ibm.com>]

Daniel,

Sorry for replying late.  I guess I finally find the root cause why exchange_dfp is needed on 
little_endian machines.

It is like this.  The structures decimal32, decimal64 and decimal128 are big-endian in current 
libdecnumber implementation:

typedef struct
{
   uint8_t bytes[DECIMAL128_Bytes];      /* decimal128: 1, 5, 12, 110 bits */
} decimal128;

But variables/constants of _Decimal32, _Decimal64 and _Decimal128 (which are the DFP extension to c 
language types) in the memory are stored in little-endian on x86, and big-endian on ppc64.  So the 
byte swapping is needed on x86.

Ben Elliston is planning to change the memory layout of decimal32/decimal64/decimal128 to host byte 
order in later libdecnumber/gcc.  Then the byte swapping will not be needed in gdb.  But that is 
when GCC gets to stage 1 again, which might be around the end of this year.

So one option is for us to keep the byte swapping code in gdb, and when the byte order in 
libdecnumber is changed to host byte order, we can easily delete them.

Another option is to wait for the byte order in libdecnumber to be changed, and we can revisit this 
patch after that.

Yet another option is to switch back to my original patch, which uses own's code, instead that of 
libdecnumber, to do the conversion between decimal value and printable string.

Which one do you prefer?

Regards
- Wu Zhou

Daniel Jacobowitz wrote:
> On Mon, Aug 21, 2006 at 11:58:14PM +0800, Wu Zhou wrote:
>> But as far as I know, the endianess of struct "value" in the target memory 
>> is architecture depedent. To name a example, in value_from_decfloat, we 
>>  need to set the raw content of val to the dfp constant user inputed, I am 
>> using this:
>>   memcpy (value_contents_raw (val), decbytes, len);
>>
>> decbytes is big-endian on all both x86 and ppc64 platforms.  But the 
>> value_contents_raw (val) is little endian on x86 / x86_64 system, and big 
>> endian on ppc64.  So exchange_dfp is needed.
> 
> No, that's not right.  The format of the byte buffer in struct value is
> supposed to match the target representation of the object being
> described.  If this is always big endian on the target, it should be
> big endian in GDB too.
> 
> You can think of it like this:
> 
> struct A
> {
>   char a, b, c, d, e, f, g, h;
> };
> 
> The first byte in the value buffer is supposed to match "char a", no
> matter what the target endianness is.
> 
> Does that help, or am I not understanding the problem?
>