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

[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

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.

> 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.

> 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?

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.

-- 
Daniel Jacobowitz
CodeSourcery