From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60030 invoked by alias); 1 Oct 2015 16:16:50 -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 60017 invoked by uid 89); 1 Oct 2015 16:16:50 -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: e06smtp06.uk.ibm.com Received: from e06smtp06.uk.ibm.com (HELO e06smtp06.uk.ibm.com) (195.75.94.102) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Thu, 01 Oct 2015 16:16:49 +0000 Received: from /spool/local by e06smtp06.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 1 Oct 2015 17:16:45 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp06.uk.ibm.com (192.168.101.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 1 Oct 2015 17:16:42 +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 d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id A586C219005C for ; Thu, 1 Oct 2015 17:16:11 +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 t91GGfRA23396550 for ; Thu, 1 Oct 2015 16:16:41 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 t91FGgSf020861 for ; Thu, 1 Oct 2015 09:16:42 -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 t91FGglr020850; Thu, 1 Oct 2015 09:16:42 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 3D31813CC; Thu, 1 Oct 2015 18:16:41 +0200 (CEST) Subject: Re: Debugger support for __float128 type? To: mark.kettenis@xs4all.nl (Mark Kettenis) Date: Thu, 01 Oct 2015 16:16:00 -0000 From: "Ulrich Weigand" Cc: gdb@sourceware.org In-Reply-To: <201509302242.t8UMg5j1017796@glazunov.sibelius.xs4all.nl> from "Mark Kettenis" at Oct 01, 2015 12:42:05 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20151001161641.3D31813CC@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15100116-0025-0000-0000-0000045E5010 X-SW-Source: 2015-10/txt/msg00002.txt.bz2 Mark Kettenis wrote: > > 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. Right, that's the current situation on PowerPC. (On Intel, long double is the 80-bit IEEE extended type, padded to either 12 bytes (32-bit) or 16 bytes (64-bit), while __float128 is IEEE quad-precision.) > I fear that the idea that it is possible to determine the floating > point type purely from the size is fairly deeply engrained into the > GDB code base. Fixing this won't be easy. The easiest thing to do > would probably be to define a separate ABI where long double is IEEE > quad-precision. But the horse is probably already out of the barn on > that one... Actually, I think the GDB side should be reasonably straight-forward to fix. We can already decide on the correct floating-point format right when a type is initially defined, and the lenght-based detection of the format is only done for those types initially defined without a format. Currently, most of the "GDB-internal" types already provide the format (or can be easily fixed to do so), but the types defined by debug info do not. However, there's no reason why e.g. dwarf2read couldn't be changed to simply set the floating-point format directly, if there were enough information in DWARF that could be used by some new architecture-specific routine to detect the appropriate format. > Making the decision based on the name is probably the easiest thing to > do. Butq keep in mind that other OSes that currently don't support > IBM long doubles and where long double is the same as double, may want > to define long double to be IEEE quad-precision floating point on > powerpc. Right. So there's three somewhat separate issues: - Code explicitly uses the new __float128 type. Since the __float128 type can only come from debug info, once we detect the format based on debug info, this should be good. It also should always be safe to recognize __float128 by name, since it will always be the 128-bit IEEE format. - We have a "long double" type provided by debug info of the current executable. Again, if we can detect the format from debug info, everything should work even if "long double" is defined differently on different OSes. (It could be 64-bit IEEE, 128-bit IBM long double, or 128-bit IEEE, I guess.) As long as we cannot reliably detect the format from debug info, we'll have to fall back on the built-in type (as below). - We debug an executable whose debug info does *not* provide "long double", but the user uses the "long double" built-in type provided by GDB. In this case, we'd ideally want to detect the OS/ABI and set the built-in type accordingly. When we decide to switch the definition of long double on Linux/PowerPC at some point in the future, ideally there would be some way to detect this new ABI in the executable (some header bit, maybe). There's still time to define this. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com