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 Jacobowitz wrote:
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.

OK, that makes sense: note that this is needed precisely when converting from a target decimal float to a host decimal128. That is a better time to do the conversion.

Yes. It should be a better time.


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.

This, however, is not correct. Libdecnumber will presumably change to use host endianness. GDB will fetch numbers in target endianness. If you're using a native i386 debugger, then you won't need to swap; but if you're using an i386 <-> powerpc debugger, then you will. The swap will need to be in the same place, just with a different condition.

Yes. Swapping is still needed in cross debugging. I will give some more thought to this, to see if I can work out a solution in the near future.


I would recommend that you always store the bytes in struct value in
target endianness.  Then, have two functions which convert between a
"struct value" and a "decimal128".  Then it should be clear which one
has which representation.

Then, for instance, you can use decimal128 in typed_val_decfloat, and
in the argument of value_from_decfloat.  And that function can be
responsible for the exchange.  Similarly, in print_decimal_floating,
you have bytes in target endianness; you can convert them to a "struct
value", which will have the same bytes, and convert the value to a
decimal128 which you can print.

The only part of that which is tricky is converting the bytes back to
a struct value.  You could write a new function, value_from_bytes,
to do that; just like value_from_longest.

Thanks for these valuable suggestion.

Regards
- Wu Zhou


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