From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94667 invoked by alias); 30 Sep 2015 17:33:57 -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 94486 invoked by uid 89); 30 Sep 2015 17:33:55 -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=unavailable version=3.3.2 X-HELO: e06smtp13.uk.ibm.com Received: from e06smtp13.uk.ibm.com (HELO e06smtp13.uk.ibm.com) (195.75.94.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 30 Sep 2015 17:33:52 +0000 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 30 Sep 2015 18:33:48 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 30 Sep 2015 18:33:45 +0100 X-IBM-Helo: d06dlp01.portsmouth.uk.ibm.com X-IBM-MailFrom: uweigand@de.ibm.com X-IBM-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 BA43D17D8042 for ; Wed, 30 Sep 2015 18:35:40 +0100 (BST) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t8UHXjdM23068888 for ; Wed, 30 Sep 2015 17:33:45 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t8UGXj4c001022 for ; Wed, 30 Sep 2015 10:33:45 -0600 Received: from oc7340732750.ibm.com (dyn-9-152-213-225.boeblingen.de.ibm.com [9.152.213.225]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t8UGXjti001014; Wed, 30 Sep 2015 10:33:45 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 9D78513CC; Wed, 30 Sep 2015 19:33:44 +0200 (CEST) Subject: Debugger support for __float128 type? To: gcc@gcc.gnu.org, gdb@sourceware.org Date: Wed, 30 Sep 2015 17:33:00 -0000 From: "Ulrich Weigand" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20150930173344.9D78513CC@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15093017-0013-0000-0000-00000597F2FE X-SW-Source: 2015-09/txt/msg00038.txt.bz2 Hello, I've been looking into supporting __float128 in the debugger, since we're now introducing this type on PowerPC. Initially, I simply wanted to do whatever GDB does on Intel, but it turns out debugging __float128 doesn't work on Intel either ... The most obvious question is, how should the type be represented in DWARF debug info in the first place? Currently, GCC generates on i386: .uleb128 0x3 # (DIE (0x2d) DW_TAG_base_type) .byte 0xc # DW_AT_byte_size .byte 0x4 # DW_AT_encoding .long .LASF0 # DW_AT_name: "long double" and .uleb128 0x3 # (DIE (0x4c) DW_TAG_base_type) .byte 0x10 # DW_AT_byte_size .byte 0x4 # DW_AT_encoding .long .LASF1 # DW_AT_name: "__float128" On x86_64, __float128 is encoded the same way, but long double is: .uleb128 0x3 # (DIE (0x31) DW_TAG_base_type) .byte 0x10 # DW_AT_byte_size .byte 0x4 # DW_AT_encoding .long .LASF0 # DW_AT_name: "long double" Now, GDB doesn't recognize __float128 on either platform, but on i386 it could at least in theory distinguish the two via DW_AT_byte_size. But on x86_64 (and also on powerpc), long double and __float128 have the identical DWARF encoding, except for the name. Looking at the current DWARF standard, it's not really clear how to make a distinction, either. The standard has no way to specifiy any particular floating-point format; the only attributes for a base type of DW_ATE_float encoding are related to the size. (For the Intel case, one option might be to represent the fact that for long double, there only 80 data bits and the rest is padding, via some combination of the DW_AT_bit_size and DW_AT_bit_offset or DW_AT_data_bit_offset attributes. But that wouldn't help for PowerPC since both long double and __float128 really use 128 data bits, just different encodings.) Some options might be: - Extend the official DWARF standard in some way - Use a private extension (e.g. from the platform-reserved DW_AT_encoding value range) - Have the debugger just hard-code a special case based on the __float128 name Am I missing something here? Any suggestions welcome ... B.t.w. is there interest in fixing this problem for Intel? I notice there is a GDB bug open on the issue, but nothing seems to have happened so far: https://sourceware.org/bugzilla/show_bug.cgi?id=14857 Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com