From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64019 invoked by alias); 1 Oct 2015 17:23:21 -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 63988 invoked by uid 89); 1 Oct 2015 17:23:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 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; Thu, 01 Oct 2015 17:23:19 +0000 Received: from /spool/local by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 1 Oct 2015 18:23:16 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 1 Oct 2015 18:23:14 +0100 X-MailFrom: uweigand@de.ibm.com X-RcptTo: gdb@sourceware.org Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 257B117D8059 for ; Thu, 1 Oct 2015 18:25:10 +0100 (BST) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t91HNEBh29425826 for ; Thu, 1 Oct 2015 17:23:14 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t91HNDld023174 for ; Thu, 1 Oct 2015 11:23:13 -0600 Received: from oc7340732750.ibm.com (dyn-9-152-213-225.boeblingen.de.ibm.com [9.152.213.225]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t91HNDse023171; Thu, 1 Oct 2015 11:23:13 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 132825FB4; Thu, 1 Oct 2015 19:23:13 +0200 (CEST) Subject: Re: Debugger support for __float128 type? To: joseph@codesourcery.com (Joseph Myers) Date: Thu, 01 Oct 2015 17:23:00 -0000 From: "Ulrich Weigand" Cc: gcc@gcc.gnu.org, gdb@sourceware.org In-Reply-To: from "Joseph Myers" at Sep 30, 2015 08:12:17 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20151001172313.132825FB4@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15100117-0021-0000-0000-000004421283 X-SW-Source: 2015-10/txt/msg00003.txt.bz2 Joseph Myers wrote: > On Wed, 30 Sep 2015, Ulrich Weigand wrote: > > > - Extend the official DWARF standard in some way > > I think you should do this. > > Note that TS 18661-4 will be coming out very soon, and includes (optional) > types > > * _FloatN, where N is 16, 32, 64 or >= 128 and a multiple of 32; > > * _DecimalN, where N >= 32 and a multiple of 32; > > * _Float32x, _Float64x, _Float128x, _Decimal64x, _Decimal128x > > so this is not simply a matter of supporting a GNU extension (not that > it's simply a GNU extension on x86_64 anyway - __float128 is explicitly > mentioned in the x86_64 ABI document), but of supporting an ISO C > extension, in any case where one of the above types is the same size and > radix as float / double / long double but has a different representation. Ah, thanks for pointing these out! 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. 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. However, for the extended types, the standard does not define a storage size or even a particular encoding, so it's not quite clear how to handle those. In theory, two different extended types could even have the same size ... On the other hand, in practice on current systems, it will probably be true that if you look at the set of all of the basic and extended (binary) types, there will be at most two different encodings for any given size, one corresponding to the interchange format of that size, and one other; so mapping those to DW_ATE_float vs. DW_ATE_interchange_float might suffice. I'm not sure how to handle an extended decimal format that does not match any of the decimal interchange formats. Does this occur in practice at all? > (All the above are distinct types in C, and distinct from float, double, > long double even if the representations are the same. But I don't think > DWARF needs to distinguish e.g. float and _Float32 other than by their > name - it's only the case of different representations that needs > distinguishing. The _Float* and _Float*x types have corresponding complex > types, but nothing further should be needed in DWARF for those once you > can represent _Float*.) 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. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com