From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29563 invoked by alias); 5 Sep 2006 02:34:57 -0000 Received: (qmail 29553 invoked by uid 22791); 5 Sep 2006 02:34:56 -0000 X-Spam-Check-By: sourceware.org Received: from ausmtp05.au.ibm.com (HELO ausmtp05.au.ibm.com) (202.81.18.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 05 Sep 2006 02:34:54 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp05.au.ibm.com (8.13.6/8.13.6) with ESMTP id k852bG3J4866168 for ; Tue, 5 Sep 2006 12:37:17 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.250.242]) by sd0208e0.au.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k852c5Q9060424 for ; Tue, 5 Sep 2006 12:38:11 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k852Yf43023030 for ; Tue, 5 Sep 2006 12:34:41 +1000 Received: from [9.181.133.72] ([9.181.133.72]) by d23av01.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k852YbcB022939; Tue, 5 Sep 2006 12:34:38 +1000 Message-ID: <44FCE239.3060904@cn.ibm.com> Date: Tue, 05 Sep 2006 02:34: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> <44FA97FA.1070100@cn.ibm.com> <20060903164410.GA7408@nevyn.them.org> In-Reply-To: <20060903164410.GA7408@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/msg00015.txt.bz2 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