From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11555 invoked by alias); 21 Aug 2006 11:07:48 -0000 Received: (qmail 11542 invoked by uid 22791); 21 Aug 2006 11:07:47 -0000 X-Spam-Check-By: sourceware.org Received: from e33.co.us.ibm.com (HELO e33.co.us.ibm.com) (32.97.110.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 21 Aug 2006 11:07:39 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7LB7b0L024124 for ; Mon, 21 Aug 2006 07:07:37 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7LB7aI5241556 for ; Mon, 21 Aug 2006 05:07:36 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7LB7agK031561 for ; Mon, 21 Aug 2006 05:07:36 -0600 Received: from imap.linux.ibm.com (imap.raleigh.ibm.com [9.37.253.145]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7LB7akf031551; Mon, 21 Aug 2006 05:07:36 -0600 Received: by imap.linux.ibm.com (Postfix, from userid 48) id 47D73190C5DE; Mon, 21 Aug 2006 07:07:36 -0400 (EDT) Received: from 9.181.133.72 ([9.181.133.72]) by imap.linux.ibm.com (Horde MIME library) with HTTP; Mon, 21 Aug 2006 07:07:36 -0400 Message-ID: <20060821070736.tr378yu70gk8s8cc@imap.linux.ibm.com> Date: Mon, 21 Aug 2006 16:08:00 -0000 From: Wu Zhou To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org Subject: Re: [RFC] decimal float point patch based on libdecnumber: gdb patch MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00145.txt.bz2 Daniel, thanks for your comments. Quoting Daniel Jacobowitz : > 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=20=20 exchange_dfp is also not for cross platform debugging. it is to handle=20=20 the transfer between the byte array representation of dfp values and=20=20 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=20=20 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=20=20 (value_from_decfloat), we need to do endianess transfer in little=20=20 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) =3D=3D 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=20=20 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