This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] decimal float point patch based on libdecnumber: gdb patch
- From: Wu Zhou <woodzltc at cn dot ibm dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 21 Aug 2006 07:07:36 -0400
- Subject: 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