From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73102 invoked by alias); 1 Oct 2015 20:40:53 -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 73078 invoked by uid 89); 1 Oct 2015 20:40:52 -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,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Oct 2015 20:40:42 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1Zhkec-0003ih-Mz from joseph_myers@mentor.com ; Thu, 01 Oct 2015 13:40:38 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Thu, 1 Oct 2015 21:40:37 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1Zhkea-00057N-0H; Thu, 01 Oct 2015 20:40:36 +0000 Date: Thu, 01 Oct 2015 20:40:00 -0000 From: Joseph Myers To: Ulrich Weigand CC: , Subject: Re: Debugger support for __float128 type? In-Reply-To: <20151001172313.132825FB4@oc7340732750.ibm.com> Message-ID: References: <20151001172313.132825FB4@oc7340732750.ibm.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2015-10/txt/msg00004.txt.bz2 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. > 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. > 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? I don't know, but I doubt it. > 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. -- Joseph S. Myers joseph@codesourcery.com