This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]