From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13657 invoked by alias); 9 Oct 2005 20:08:19 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13644 invoked by uid 22791); 9 Oct 2005 20:08:17 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 09 Oct 2005 20:08:17 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EOhSw-0001ye-VP; Sun, 09 Oct 2005 16:08:15 -0400 Date: Sun, 09 Oct 2005 20:08:00 -0000 From: Daniel Jacobowitz To: Wu Zhou Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Decimal Floating Point support for GDB (Part 1: patch) Message-ID: <20051009200814.GB7107@nevyn.them.org> Mail-Followup-To: Wu Zhou , gdb-patches@sources.redhat.com References: <20051002205724.GB31820@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-10/txt/msg00077.txt.bz2 On Sun, Oct 09, 2005 at 01:27:10PM +0800, Wu Zhou wrote: > > I'm afraid I am not very happy with this approach :-( > > > > * c-exp.y (parse_number): Parse the decimal floating point, which > > has a suffix ('df', 'dd' or 'dl') and return STRING here. > > In fact. I am not very happy with that either. But this is what came out > of my mind at this time, provided that gcc and glibc support for DFP is > not ready yet. If the gdb-building compiler already support dfp types > (_Decimal32, _Decimal64 and _Decimal64) and sscanf (GDB uses it to parse > floating point number) could recognize and scan decimal types, I won't > adopt this method. I'd rather work with decNumber than mix host and target types. > > (gdb) p 1.2df > > evaluation of this expression requires the target program to be active > > Didn't predict that. So all string expression handling need the target > program to be active? Yes. The expression 'print "1"' calls malloc(2) in the inferior program to allocate space for the string, pokes the value into target memory, and generally leaks a bit of memory too. > > [Side effect of string handling] > > > > (gdb) p 1.2df > > $1 = "1.2" > > Predicted this. It seems that it is still acceptable. Right? Please no! "p 1.2df" should give me back either 1.2 or 1.2df. > > If we have a GDB type system representation for decimal floats, the C > > parser should use it, and for lexing purposes it should probably be a > > FLOAT. > > Okay. I didn't thought of adding a gdb type for decimal floats. Maybe I > should (It seems to be a good approach). But I am not very familar > with GDB's type system. Any clue about how to start? adding a > builtin_type for DFP and letting it have three or more fields (like sign, > coefficient, exponent...)? I will take some more looks into the code. Or just use the decNumber packed representation, in value_contents(). Take a look at all the references to FLOATFORMAT to see how we handle floating point types. We'd want to handle printing not only dfp variables, but dfp fields in structures, et cetera. -- Daniel Jacobowitz CodeSourcery, LLC