From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120469 invoked by alias); 6 Sep 2017 18:01:09 -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 120428 invoked by uid 89); 6 Sep 2017 18:01:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=deciding, proportion, life 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; Wed, 06 Sep 2017 18:01:01 +0000 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v86HxiN0058083 for ; Wed, 6 Sep 2017 14:01:00 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ctjgkg4q0-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 06 Sep 2017 14:01:00 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 6 Sep 2017 19:00:54 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 6 Sep 2017 19:00:52 +0100 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v86I0pAr16318492; Wed, 6 Sep 2017 18:00:51 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 80AD1A4053; Wed, 6 Sep 2017 18:57:10 +0100 (BST) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 70D44A4040; Wed, 6 Sep 2017 18:57:10 +0100 (BST) Received: from oc3748833570.ibm.com (unknown [9.152.213.178]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 6 Sep 2017 18:57:10 +0100 (BST) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 53811D83591; Wed, 6 Sep 2017 20:00:51 +0200 (CEST) Subject: Re: [RFC][00/19] Target FP: Precise target floating-point emulation To: eliz@gnu.org Date: Wed, 06 Sep 2017 18:01:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <83vakx0zr1.fsf@gnu.org> from "Eli Zaretskii" at Sep 05, 2017 09:25:06 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17090618-0020-0000-0000-000003B600D5 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17090618-0021-0000-0000-0000424700E8 Message-Id: <20170906180051.53811D83591@oc3748833570.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-06_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709060255 X-SW-Source: 2017-09/txt/msg00159.txt.bz2 Eli Zaretskii wrote: > > Date: Tue, 5 Sep 2017 20:20:30 +0200 (CEST) > > From: "Ulrich Weigand" > > > > This patch series addresses this problem by converting GDB to perform > > all floating-operations by precisely emulation target arithmetic, > > using the MPFR library. > > In native debugging as well? Currently, yes. However, this can be fine-tuned as we like using the new setup; we could fall back to host arithmetic in some cases. Making that decision based on native vs. remote debugging does not appear to be the correct choice here, in particular given the problems pointed out in my original mail with *native* debugging if FP types larger than "long double" are used (like __float128). However, we could make a decision based on the particular target *format* (e.g. whether it is equivalent to one of the available host formats). The question is whether this is worthwhile the additional complication of code (and possibly test cases). > If so, wouldn't that make GDB significantly slower in that case? Of course, considering just one single arithmetic operation, a call to MPFR is orders of magnitude slower than just doing the operation in host format (often a single instruction). But that is not the only question; the other question is how frequent those operations are in the first place. And from what I can tell, all the "hot", performance critical paths in GDB do not perform any FP operations at all in the first place. Those are only done in response to UI actions specifically involving FP values. For example, the whole of the gdb.base test suite appears to be doing less 100 instances of any base FP operation. (This does not count FP parsing or printing, which are a bit more frequent -- but for those operations the performance difference between a native printf/scanf and the corrsponding MPFR printf/scanf is much less in proportion.) So there is no overall wall-clock performance difference visible. Now, I'm sure one can construct cases where FP arithmetic operations occur much more frequently -- but I'd prefer to see a case where it actually matters in real life before deciding to implement the more complicated solution described above. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com