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

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

Daniel, thanks for your comments.

Quoting Daniel Jacobowitz <drow@false.org>:

> On Tue, Aug 01, 2006 at 05:54:55AM -0400, Wu Zhou wrote:
>> The order of these bytes are now big-endian, i.e. the first byte is
>> the most significant one.  But it is maken to be the same as the
>> endianess of the target through routine exchange_dfp (in dfp.c). If
>> the target is big-endian, no reversion is needed; if it is
>> little-endian, reversion is needed. This is done through the checking
>> of gdbarch_byte_order (current_gdbarch):
>
> This is what confuses me.  Why is it always big-endian in GDB, if it is
> target-endian in the target?  I would have expected it to be
> host-endian in GDB and target-endian in the target.
>
>                 i386 target            ppc64 target
>  i386 host      no byteswap            need byteswap
>  ppc64 host     need byteswap          no byteswap

I don't take this kind of configuration into consideration yet. And  
exchange_dfp is also not for cross platform debugging. it is to handle  
the transfer between the byte array representation of dfp values  and  
gdb's value system.

> Or is it always big-endian?  I looked through libdecnumber and I
> couldn't see any reason for i386 to use little endian ordering in
> the decimal128 type.

decimal128 is defined like this in libdecnumber:

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

It is always big-endian.

When parsing dfp constant in our patch, we are also using a byte array  
to store its value. It is big-endian too:

   struct {
        gdb_byte val[16];
        struct type *type;
   } typed_val_decfloat;

But when transfering them into gdb's value system  
(value_from_decfloat), we need to do endianess transfer in little  
endian machine. This is why exchange_dfp is needed.

>> static void
>> exchange_dfp (const gdb_byte *valaddr, int len, gdb_byte *dec_val)
>> {
>>   int index;
>>
>>   if (gdbarch_byte_order (current_gdbarch) == 1)
>
> The 1 should be BFD_ENDIAN_LITTLE.

Yes. It is.  Thanks!

>> Maybe this can't support cross-debugging (I am not sure though).  But
>> I am planning to take this into consideration.  I have one question
>> first: which data structure  is used to describe the host's byte-order
>> information? Anyone is kind to tell me?

I had a try on ppc64. but remote debugging on ppc64 do not work very  
well. I need to look into the reason.

> There isn't one in GDB right now.  We can add one using autoconf if
> it's really necessary.
>
> Let's straighten this out first, and then I'll take a look at the
> actual patch.


Regards
- Wu Zhou