From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2061 invoked by alias); 12 Jul 2006 20:39:20 -0000 Received: (qmail 2051 invoked by uid 22791); 12 Jul 2006 20:39:19 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 12 Jul 2006 20:39:15 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G0lUG-0008AD-Fl; Wed, 12 Jul 2006 16:39:12 -0400 Date: Wed, 12 Jul 2006 20:39:00 -0000 From: Daniel Jacobowitz To: Wu Zhou Cc: gdb-patches@sourceware.org Subject: Re: [RFC] decimal float point patch based on libdecnumber: gdb patch Message-ID: <20060712203912.GR24622@nevyn.them.org> Mail-Followup-To: Wu Zhou , gdb-patches@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 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/msg00130.txt.bz2 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? 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. > Index: expression.h > =================================================================== > 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" and ":"). */ > OP_F90_RANGE, > > + /* OP_DECDOUBLE is followed by a type pointer in the next exp_element > + 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? > Index: c-valprint.c > =================================================================== > 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, format, 0, stream); > + } > + else > + { > + print_decimal_floating (valaddr + embedded_offset, type, stream); > + } > + break; > + > case TYPE_CODE_METHOD: > { > struct value *v = 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. -- Daniel Jacobowitz CodeSourcery