From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28060 invoked by alias); 3 Sep 2006 08:53:32 -0000 Received: (qmail 28051 invoked by uid 22791); 3 Sep 2006 08:53:31 -0000 X-Spam-Check-By: sourceware.org Received: from ausmtp04.au.ibm.com (HELO ausmtp04.au.ibm.com) (202.81.18.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 03 Sep 2006 08:53:30 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp04.au.ibm.com (8.13.6/8.13.5) with ESMTP id k83918Al257526 for ; Sun, 3 Sep 2006 19:01:08 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.250.244]) by sd0208e0.au.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k838ujnM229064 for ; Sun, 3 Sep 2006 18:56:50 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k838rLA1011404 for ; Sun, 3 Sep 2006 18:53:21 +1000 Received: from [9.125.0.191] ([9.125.0.191]) by d23av03.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k838rJjn011392; Sun, 3 Sep 2006 18:53:20 +1000 Message-ID: <44FA97FA.1070100@cn.ibm.com> Date: Sun, 03 Sep 2006 08:53:00 -0000 From: Wu Zhou User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Wu Zhou , gdb-patches@sourceware.org Subject: Re: [RFC] decimal float point patch based on libdecnumber: gdb patch References: <20060821070736.tr378yu70gk8s8cc@imap.linux.ibm.com> <20060821125031.GA16703@nevyn.them.org> <44E9D816.9070809@cn.ibm.com> <20060821160834.GA22192@nevyn.them.org> In-Reply-To: <20060821160834.GA22192@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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-09/txt/msg00013.txt.bz2 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? >