From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28433 invoked by alias); 2 Oct 2015 15:18:01 -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 28422 invoked by uid 89); 2 Oct 2015 15:18:01 -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: e06smtp05.uk.ibm.com Received: from e06smtp05.uk.ibm.com (HELO e06smtp05.uk.ibm.com) (195.75.94.101) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 02 Oct 2015 15:18:00 +0000 Received: from /spool/local by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 Oct 2015 16:17:57 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 2 Oct 2015 16:17:55 +0100 X-MailFrom: uweigand@de.ibm.com X-RcptTo: gdb@sourceware.org Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id B262F219005F for ; Fri, 2 Oct 2015 16:17:54 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t92FHt2m40829016 for ; Fri, 2 Oct 2015 15:17:55 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 t92FHsuG022364 for ; Fri, 2 Oct 2015 09:17:55 -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 t92FHsfK022353; Fri, 2 Oct 2015 09:17:54 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id C9DCF123D8; Fri, 2 Oct 2015 17:17:53 +0200 (CEST) Subject: Re: Debugger support for __float128 type? To: joseph@codesourcery.com (Joseph Myers) Date: Fri, 02 Oct 2015 15:18:00 -0000 From: "Ulrich Weigand" Cc: gcc@gcc.gnu.org, gdb@sourceware.org In-Reply-To: from "Joseph Myers" at Oct 01, 2015 08:40:35 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20151002151753.C9DCF123D8@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15100215-0021-0000-0000-00000444DE0A X-SW-Source: 2015-10/txt/msg00007.txt.bz2 Joseph Myers wrote: > On Thu, 1 Oct 2015, Ulrich Weigand wrote: > > > The _DecimalN types are already supported by DWARF using a base type with > > encoding DW_ATE_decimal_float and the appropriate DW_AT_byte_size. > > Which doesn't actually say whether the DPD or BID encoding is used, but as > long as each architecture uses only one that's not a problem in practice. I see. Well, one could add a DW_ATE_decimal_interchange_float for completeness, if necessary. > > For the interchange type, it seems one could define a new encoding, > > e.g. DW_ATE_interchange_float, and use this together with the > > appropriate DW_AT_byte_size to identify the format. > > It's not clear to me that (for example) distinguishing float and _Float32 > (other than by name) is useful in DWARF (and if you change float from > DW_ATE_float to DW_ATE_interchange_float that would affect old debuggers - > is the idea to use DW_ATE_interchange_float only for the new types, not > for old types with the same encodings, so for _Float32 but not float?). > But it's true that if you say it's an interchange type then together with > size and endianness that uniquely determines the encoding. So my thinking here was: today, DWARF deliberately does not specify the details of the floating-point encoding format, so that it doesn't have to get into all the various formats that exist on all the platforms supported by DWARF. That is why a DW_ATE_float encoding simply says; this is a floating-point number of size N encoded as defined by the platform ABI. The new DW_ATE_interchange_float encoding would say instead; this is a floating-point number of size N encoded as defined by the IEEE interchange format. On platforms where the ABI-defined format actually *is* the interchange format, a DWARF producer would be free to use either DW_ATE_float or DW_ATE_interchange_float. This decision could of course take into consideration compatibility requirements with older debuggers etc. However, having two encoding definitions would allow platforms to use both the interchange format and one additional platform-defined non-interchange format of the same size, if needed. > > Well, complex types have their own encoding (DW_ATE_complex_float), so we'd > > have to define the corresponding variants for those as well, e.g. > > DW_ATE_complex_interchange_float or the like. > > And DW_ATE_imaginary_interchange_float, I suppose. Right. 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 (If the attribute isn't present, we'd default to variant 0, which is just the current encoding.) This would allow an arbitrary number of platform-specific encodings, any of which might or might not be IEEE-defined formats ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com