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,

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?



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