From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54715 invoked by alias); 1 Oct 2015 09:46:07 -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 54631 invoked by uid 89); 1 Oct 2015 09:46:06 -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 autolearn=unavailable version=3.3.2 X-HELO: villa.puc.rediris.es Received: from villa.puc.rediris.es (HELO villa.puc.rediris.es) (130.206.18.7) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 01 Oct 2015 09:46:05 +0000 Received: from [150.214.244.11] (helo=gra-lx1.iram.es) by villa.puc.rediris.es with esmtpa (Exim 4.80) (envelope-from ) id 1ZhaQt-0000sg-0b; Thu, 01 Oct 2015 11:45:55 +0200 Received: by gra-lx1.iram.es (Postfix, from userid 1210) id D4E7F180019A; Thu, 1 Oct 2015 11:45:36 +0200 (CEST) X-Envelope-From: paubert@iram.es Date: Thu, 01 Oct 2015 09:46:00 -0000 From: Gabriel Paubert To: Mark Kettenis Cc: uweigand@de.ibm.com, gcc@gcc.gnu.org, gdb@sourceware.org Subject: Re: Debugger support for __float128 type? Message-ID: <20151001094536.GA27423@visitor2.iram.es> References: <20150930173344.9D78513CC@oc7340732750.ibm.com> <201509302242.t8UMg5j1017796@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201509302242.t8UMg5j1017796@glazunov.sibelius.xs4all.nl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -0.2 (/) X-Spamina-Spam-Report: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: inria.fr] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-SW-Source: 2015-10/txt/msg00001.txt.bz2 On Thu, Oct 01, 2015 at 12:42:05AM +0200, Mark Kettenis wrote: > > Date: Wed, 30 Sep 2015 19:33:44 +0200 (CEST) > > From: "Ulrich Weigand" > > > > 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 > > Perhaps you should start with explaining what __float128 actually is > on your specific platform? And what long double actually is. > > I'm guessing long double is a what we sometimes call an IBM long > double, which is essentially two IEEE double-precision floating point > numbers packed together and that __float128 is an attempt to fix > history and have a proper IEEE quad-precision floating point type ;). > And that __float128 isn't actually implemented in hardware. An IBM mainframe might want to discuss this point with you :-). See pages 24-25 of http://arith22.gforge.inria.fr/slides/s1-schwarz.pdf Latencies are decent, not extremely low, but we are speaking of a processor clocked at 5GHz, so the latencies are 2.2ns for add/subtract, 4.6ns for multiplications, and ~10ns for division. To put things in perspective, how many cycles is a memory access which misses in both L1 and L2 caches these days? > The reason people haven't bothered to fix this, is probably because > nobody actually implements quad-precision floating point in hardware. > And software implementations are so slow that people don't really use > them unless they need to. Like I did to nomerically calculate some > asymptotic expansions for my Thesis work... Which would probably run much faster if ported to a z13. Gabriel