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

[Wu Zhou]

Hi Daniel,

Thanks for your comment.

Quoting Daniel Jacobowitz <drow@false.org>:

> On Sun, Jul 23, 2006 at 01:47:58AM -0400, Wu Zhou wrote:
>> My point is to keep these usage so as they are consistent with how
>> flaot/double is handled.  What is your idea on this?
>
> I think it would be more useful to search for all reference to decimal
> float, than it would be to exactly parallel the float/double support.

OK.  I will buy your point.  :-)     The revised patch adopt this preference.

>> But in big-endian machine, this might be not needed. I will try a test
>> on ppc64.

I made some modification to my patch.  It now works on both x86  
(little endian) and ppc64 (big endian) platforms. All 125 tests pass  
on these two platforms. I didn't do any test on cross-debugging though.

Here are some explanation to my revised patch, wishing that it can  
clarfiy the situation somehow.

I am now still use  array of bytes (gdb_byte val[16]) to represent  
decimal float in gdb.  The reason is that we can't assume that the  
gdb-building compiler supports the decimal extension to C language  
standard. If we can, that will be much easier, we can just use that to  
represent decimal float in gdb.

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):

static void
exchange_dfp (const gdb_byte *valaddr, int len, gdb_byte *dec_val)
{
   int index;

   if (gdbarch_byte_order (current_gdbarch) == 1)
     for (index = 0; index < len; index++)
       dec_val[index] = valaddr[len - index - 1];
   else
     for (index = 0; index < len; index++)
       dec_val[index] = valaddr[index];

   return;
}

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?

Attached below is the revised patch. Please review and comment.  Thanks a lot!


-------------- next part --------------
A non-text attachment was scrubbed...
Name: dfp-0801.patch
Type: text/x-patch
Size: 54069 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20060801/9b875305/attachment.bin>