From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13036 invoked by alias); 23 Jul 2006 05:48:12 -0000 Received: (qmail 13018 invoked by uid 22791); 23 Jul 2006 05:48:09 -0000 X-Spam-Check-By: sourceware.org Received: from e5.ny.us.ibm.com (HELO e5.ny.us.ibm.com) (32.97.182.145) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 23 Jul 2006 05:48:02 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6N5lxIk009188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 23 Jul 2006 01:47:59 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6N5lxR1106410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 23 Jul 2006 01:47:59 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6N5lx1S003703 for ; Sun, 23 Jul 2006 01:47:59 -0400 Received: from imap.linux.ibm.com (imap.raleigh.ibm.com [9.37.253.145]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6N5lxLY003700; Sun, 23 Jul 2006 01:47:59 -0400 Received: by imap.linux.ibm.com (Postfix, from userid 48) id E87D645C032; Sun, 23 Jul 2006 01:47:58 -0400 (EDT) Received: from 9.125.0.161 ([9.125.0.161]) by imap.linux.ibm.com (Horde MIME library) with HTTP; Sun, 23 Jul 2006 01:47:58 -0400 Message-ID: <20060723014758.9rm87choaoc8cw08@imap.linux.ibm.com> Date: Sun, 23 Jul 2006 05:48: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=GB2312; 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-07/txt/msg00316.txt.bz2 Hi Daniel, Thanks for reviewing this patch. Quoting Daniel Jacobowitz : > On Thu, Jun 22, 2006 at 07:36:17AM +0800, Wu Zhou wrote: >> >> Appended is the patch. I had tested it with the latest gcc-4.2 cvs tree >> on x86, with option "--enable-decimal-float". All the 121 tests passed. >> Please review and comment. Thanks a lot. > > Sometimes you use DECDBL and sometimes you use DECDOUBLE and sometimes > you use DECFLOAT and sometimes you use DECFLT. Let's pick one or the > other and use it everywhere. This makes it easier to search for > code that knows about decimal float. "decfloat" might be more > readable? I was using these different names because I wa simulating what=20=20 float/double/long double are using. DECDBL is not used anywhere, but decdbl is. :-) It is only used in write_exp_elt_decdblcst and its reference. That is=20=20 to simulate write_exp_elt_dblcst. I am not very sure why gdb named it=20=20 dbl though. DECDOUBLE is used in OP_DECDOUBLE and value_from_decdouble. This is=20=20 to simulate OP_DOUBLE and value_from_double. All three kinds of float=20=20 constants and variables are handled by them. So I am using them for=20=20 DECDOUBLE too. DECFLT is only used in TYPE_CODE_DECFLT. This is to simulate=20=20 TYPE_CODE_FLT, which is used to refer to types of float, double, long=20=20 double at the same time. The length can differentiate them. DECFLOAT is used in parsing and fundamental type representation=20=20 dwarf2read.c and C language handling. such as FT_DECFLOAT,=20=20 FT_DBL_PREC_DECFLOAT and FT_EXT_PREC_DECFLOAT. This is the same what=20=20 FLOAT is used in these scanario. My point is to keep these usage so as they are consistent with how=20=20 flaot/double is handled. What is your idea on this? > Why is reverse_dfp necessary? It says GDB uses the opposite endianness > from decNumber, but I don't see why. This might be a related problem, > but are you accomodating target endianness when you read values from > the target? If not, a cross debugger will do the wrong thing. We are using an array of gdb_byte to represent decimal values. The=20=20 first byte is the most significant. This might be not the same as the=20=20 underlying byte order of the architecuture. In this kind of=20=20 situation, reverse_dfp is needed to do conversion. But in big-endian machine, this might be not needed. I will try a test=20=20 on ppc64. I am now also thinking that the place where reverse_dfp is defined is=20=20 not very good. Maybe we can put them into decimal_to_string /=20=20 decimal_from_string. Then other gdb code don't need to know the=20=20 existence of that. BTW, I am not very sure what you means by saying "are you accomodating=20=20 target endianness when you read values from the target?". I guess you=20=20 mean that I _need_ to accommodate the endianness when reading values=20=20 from the target, right? Then putting some code into=20=20 decimal_from_string / decimal_to_string to convert the byte order if=20=20 needed is right what you want to see, right? Any advices? >> Index: expression.h >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> RCS file: /cvs/src/src/gdb/expression.h,v >> retrieving revision 1.18 >> diff -u -r1.18 expression.h >> --- expression.h 17 Dec 2005 22:33:59 -0000 1.18 >> +++ expression.h 21 Jun 2006 23:08:51 -0000 >> @@ -327,6 +327,11 @@ >> /* A F90 array range operator (for "exp:exp", "exp:", ":exp"=20=20= =20 >> and ":"). */ >> OP_F90_RANGE, >> >> + /* OP_DECDOUBLE is followed by a type pointer in the next exp_eleme= nt >> + and a dec long constant value in the following exp_element. >> + Then comes another OP_DECDOUBLE. */ >> + OP_DECDOUBLE, >> + > > A comment on the format of the data would be nice here. Is it in > target byte order? The first byte is the most significant byte. I don't have code to=20=20 make it into the target byte order yet. reverse_dfp can partially do=20=20 that. But it need to be more general. And I am planning to add some=20=20 code into decimal_to_string / decimal_from_string to test the target=20=20 byte order and determine if the conversion is needed. What is your=20=20 thought? >> Index: c-valprint.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> RCS file: /cvs/src/src/gdb/c-valprint.c,v >> retrieving revision 1.39 >> diff -u -r1.39 c-valprint.c >> --- c-valprint.c 18 Jan 2006 21:24:19 -0000 1.39 >> +++ c-valprint.c 21 Jun 2006 23:08:52 -0000 >> @@ -442,6 +442,17 @@ >> } >> break; >> >> + case TYPE_CODE_DECFLT: >> + if (format) >> + { >> + print_scalar_formatted (valaddr + embedded_offset, type,=20=20=20 >> format, 0, stream); >> + } >> + else >> + { >> + print_decimal_floating (valaddr + embedded_offset, type, stream); >> + } >> + break; >> + >> case TYPE_CODE_METHOD: >> { >> struct value *v =3D value_at (type, address); > > You don't need the braces in this; please omit them when you don't need > to. It saves a level of indentation, which generally makes them easier > to read. Thanks. I will delete them when I update my patch. Regards - Wu Zhou