From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50909 invoked by alias); 5 Sep 2017 18:20:42 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 50894 invoked by uid 89); 5 Sep 2017 18:20:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-7.6 required=5.0 tests=BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*Ad:U*uweigand, 13-14, faithfully X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Sep 2017 18:20:36 +0000 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v85IJ8iE046704 for ; Tue, 5 Sep 2017 14:20:35 -0400 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 2csvwp57k4-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 05 Sep 2017 14:20:35 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 5 Sep 2017 19:20:32 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 5 Sep 2017 19:20:30 +0100 Received: from d06av24.portsmouth.uk.ibm.com (mk.ibm.com [9.149.105.60]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v85IKUan23331040 for ; Tue, 5 Sep 2017 18:20:30 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C063B42041 for ; Tue, 5 Sep 2017 19:17:01 +0100 (BST) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ACA2442042 for ; Tue, 5 Sep 2017 19:17:01 +0100 (BST) Received: from oc3748833570.ibm.com (unknown [9.164.150.234]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP for ; Tue, 5 Sep 2017 19:17:01 +0100 (BST) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 0964DD8086F; Tue, 5 Sep 2017 20:20:30 +0200 (CEST) Subject: [RFC][00/19] Target FP: Precise target floating-point emulation To: gdb-patches@sourceware.org Date: Tue, 05 Sep 2017 18:20:00 -0000 From: "Ulrich Weigand" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17090518-0040-0000-0000-000003D5CD8D X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17090518-0041-0000-0000-000025D652BB Message-Id: <20170905182030.0964DD8086F@oc3748833570.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-05_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=49 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709050267 X-SW-Source: 2017-09/txt/msg00100.txt.bz2 [RFC][00/19] Target FP: Precise target floating-point emulation GDB currently performs all floating-point operations (arithmetic, conversion, printing and scanning) using the largest standard host floating-point type (typedef'd as DOUBLEST). While this used to be mostly OK for typical native debugging sessions (since the host DOUBLEST is large enough to faithfully represent all target data types) -- except possibly for some rounding differences --, this can cause serious issues if that assumption doesn't hold: - When remote debugging a target that has a data type larger than the host DOUBLEST, e.g. "long double" on s390 is IEEE-128, which cannot be represented in a DOUBLEST on a x86 host. - Even in native debugging, if there is some non-standard type that does not fit into "long double", e.g. __float128 on x86 and ppc64. This patch series addresses this problem by converting GDB to perform all floating-operations by precisely emulation target arithmetic, using the MPFR library. In general, the idea of the patch series is to completely eliminate DOUBLEST from the GDB source base, and instead hold all floating-point values always in target binary format in a byte buffer. A new file target-float.{c,h} then implements all required operations on those byte buffers. Note that this is very similar to how GDB today already handles *decimal* floating-point values. In fact, the new target-float operations support both binary and decimal types with the same interface, which will allow to consolidate most handling of BFP and DFP throughout GDB into single FP code paths. Once this refactoring is complete, the only remaining use of DOUBLEST will be in target-float.c, where it can then be replaced by MPFR. (Use of MPFR is still optional, with a fall-back to the old DOUBLEST code if MPFR is not available. We may want to re-think this and make MPFR required --- it should be available everywhere where GDB can be built today.) The patch series is laid out as follows: 00-02: Some preliminary clean up of binary FP handling. 03: Some preliminary clean up of decimal FP handling. 05-07: Simplify and fix binary FP printing. 08: Remove DOUBLEST from expression parsing and binary FP scanning. 09-12: Introduce target-float.{c,h} and move operations there. 13-14: Remove some remaining uses of DOUBLEST in the code base. 15-17: Final (trival) clean up patches. 18: Remove doublest.{c,h} and dfp.{c,h}. 19: Switch target-float.c to use MPFR if present. Any comments welcome, in particular from the affected target and language maintainers! Tested by building with --enable-targets=all and running the test suite without regressions on x86_64-linux, powerpc64le-linux, and s390x-linux. Bye, Ulrich