From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64944 invoked by alias); 2 Oct 2015 16:01:18 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 64366 invoked by uid 89); 2 Oct 2015 16:01:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp09.uk.ibm.com Received: from e06smtp09.uk.ibm.com (HELO e06smtp09.uk.ibm.com) (195.75.94.105) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 02 Oct 2015 16:01:16 +0000 Received: from /spool/local by e06smtp09.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 Oct 2015 17:01:13 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp09.uk.ibm.com (192.168.101.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 2 Oct 2015 17:01:12 +0100 X-MailFrom: uweigand@de.ibm.com X-RcptTo: gdb@sourceware.org Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 424541B0806B for ; Fri, 2 Oct 2015 17:01:11 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t92G1BW431129732 for ; Fri, 2 Oct 2015 16:01:11 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t92G1BEJ004957 for ; Fri, 2 Oct 2015 10:01:11 -0600 Received: from oc7340732750.ibm.com (icon-9-164-177-222.megacenter.de.ibm.com [9.164.177.222]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t92G1BFi004949; Fri, 2 Oct 2015 10:01:11 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 26875123D8; Fri, 2 Oct 2015 18:01:10 +0200 (CEST) Subject: Re: Debugger support for __float128 type? To: joseph@codesourcery.com (Joseph Myers) Date: Fri, 02 Oct 2015 16:01:00 -0000 From: "Ulrich Weigand" Cc: gcc@gcc.gnu.org, gdb@sourceware.org In-Reply-To: from "Joseph Myers" at Oct 02, 2015 03:41:24 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20151002160110.26875123D8@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15100216-0037-0000-0000-000004191DD4 X-SW-Source: 2015-10/txt/msg00009.txt.bz2 Joseph Myers wrote: > On Fri, 2 Oct 2015, Ulrich Weigand wrote: > > I see. Well, one could add a DW_ATE_decimal_interchange_float for > > completeness, if necessary. > > Since both DPD and BID are interchange encodings, that doesn't actually > determine things without some way to say which was used (that is, both > DW_ATE_decimal_float and DW_ATE_decimal_interchange_float would rely on > platform-specific information to determine the format). I don't know if > DW_ATE_decimal_float is being used anywhere for something that's not an > interchange format. Ah, yes. I missed that both DPD and BID are defined as interchange formats. This suggestion doesn't make sense then ... > > As an alternative to specifying the well-defined interchange format, > > another option might be to simply add a second DWARF attribute, > > e.g. DW_AT_encoding_variant, to floating-point and related base types. > > This would simply be an integer with platform-specific semantics. > > So DWARF producers could simply describe a type as: > > this is a floating-point number of size N encoded as defined by > > platform ABI encoding variant #V > > Do you want entirely platform-specific semantics? Or would it be better > to define standard values to mean it's an IEEE interchange format (or, for > decimal floating point, to specify whether it's DPD or BID), plus space > for future standard values and space for platform-specific values? Hmm, I had been thinking of leaving that entirely platform-specific. I guess one could indeed define some values with well-defined standard semantics; that would assume DWARF would want to start getting into the game of defining floating-point formats -- not sure what the position of the committee would be on this question ... [ Back when DW_ATE_decimal_float was added, the initial proposal did indeed specify the encoding should follow IEEE-754R, but that was removed when the proposal was actually added to the standard. ] > Would existing consumers safely ignore that attribute (so that producers > could safely specify IEEE interchange encoding for float, double etc. if > applicable, without breaking existing consumers)? Yes, existing consumers should simply ignore attributes they are not aware of. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com