From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 83D623858D3C for ; Thu, 13 Apr 2023 16:13:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 83D623858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=us.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=us.ibm.com Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33DFnHm4000575; Thu, 13 Apr 2023 16:13:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : from : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version : subject; s=pp1; bh=xERNee6mskN+rcXnNXYcoF+OW7lNuyQD5LUhbaBELwU=; b=EF9J44oIisMjgnw//zJk4VqjobJ8t4X7Urq3IUc1SzAD/J1ienNfO8Hbk7HrFYqpk7pJ Rq0WrmgAi5Jpa7vsFedNDqlp1DT3XJkOQfhX+LEwun77lAFeGwRVH4ESBWmmF6kgVCvG s+rCvE2VrSEOvIVSpXIy04oF30uRzd8wqt7SCNh2vw15/hkqAJFK/z5eUiMTIMBM+7Kg 3EjVjP1p7UOVoZrSeMAmFepBvwy79A9j1Kmvuf5qF1Twx+NJQ/VxCU3OJX6eYn1+aWAs Xz9pDQZcqmLOvO2BPZXdCLUTgDF4t/qA7dgTuU29Q83PJlHF9Zh0UQG5hRQqJzpQzpKh rA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3pxmqcrw11-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Apr 2023 16:13:07 +0000 Received: from m0098419.ppops.net (m0098419.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 33DFoSr0003803; Thu, 13 Apr 2023 16:13:07 GMT Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3pxmqcrw0m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Apr 2023 16:13:07 +0000 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 33DETLO7002001; Thu, 13 Apr 2023 16:13:06 GMT Received: from smtprelay02.dal12v.mail.ibm.com ([9.208.130.97]) by ppma03dal.us.ibm.com (PPS) with ESMTPS id 3pu0ku3c2y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Apr 2023 16:13:06 +0000 Received: from smtpav03.wdc07v.mail.ibm.com (smtpav03.wdc07v.mail.ibm.com [10.39.53.230]) by smtprelay02.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 33DGD38x25756010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Apr 2023 16:13:04 GMT Received: from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ABCFA5805D; Thu, 13 Apr 2023 16:13:03 +0000 (GMT) Received: from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 19C2A58054; Thu, 13 Apr 2023 16:13:03 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.150.219]) by smtpav03.wdc07v.mail.ibm.com (Postfix) with ESMTP; Thu, 13 Apr 2023 16:13:02 +0000 (GMT) Message-ID: <33972784460b21164a6581664f647c4edc03c1f9.camel@us.ibm.com> From: Carl Love To: Tom Tromey , Carl Love via Gdb-patches Cc: Ulrich Weigand , Kevin Buettner , cel@us.ibm.com Date: Thu, 13 Apr 2023 09:13:02 -0700 In-Reply-To: <87fs936f1o.fsf@tromey.com> References: <184c0edcf067acccdf71d4dcdd66447bb5d93d4c.camel@us.ibm.com> <1b5d214a6208c422963e58c27c98f81af9601628.camel@us.ibm.com> <87fs936f1o.fsf@tromey.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) X-TM-AS-GCONF: 00 X-Proofpoint-GUID: HiRTJcKIwTTH1hEbaJPQVLsQfyEzoZvy X-Proofpoint-ORIG-GUID: MBbdLRlNqbiciYsBzue72OgRy2EYJtYO Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 1 URL was un-rewritten MIME-Version: 1.0 Subject: RE: [PATCH ver 2] PowerPC: fix _Float128 type output string X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-13_11,2023-04-13_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 clxscore=1011 lowpriorityscore=0 impostorscore=0 suspectscore=0 mlxscore=0 malwarescore=0 bulkscore=0 priorityscore=1501 adultscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304130139 X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 2023-04-13 at 08:18 -0600, Tom Tromey wrote: > > > > > > "Carl" == Carl Love via Gdb-patches < > > > > > > gdb-patches@sourceware.org> writes: > > Carl> PowerPC supports two 128-bit floating point formats, the IBM > long double > Carl> and IEEE 128-bit float. The issue is the DWARF information > does not > Carl> distinguish between the two. There have been proposals of how > to extend > Carl> the DWARF information as discussed in > Carl> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194 > > Carl> but has not been fully implemented. > > Could it be? I didn't read the issue but it's often better to put in > the effort to fix the problem in the compiler. Normally once these > workarounds go into gdb, they can never be removed. Yup, that is the problem right now with GCC. Even if we could get it fixed in GCC today, the GCC hack is already in released distro versions. GDB will have to deal with it for sometime after it gets fixed in GCC. This issue was addressed in the GCC community several years ago from my understanding. Bugs have been filed with regards to the fact that the GCC hack is not transparent to GDB, but there doesn't seem to be much traction to address the issue yet. > > Carl> This patch fixes 74 regression test failures in > Carl> gdb.base/whatis-ptype-typedefs.exp on PowerPC with IEEE float > 128 as the > Carl> default on GCC. It fixes one regression test failure in > Carl> gdb.base/complex-parts.exp. > > I don't really understand how this patch works. > > It took me a while to understand that maybe the issue is that the > association between a gdb type and a float format is done by name and > size, and because this is a typedef, the association is done instead > by > the underlying type -- which is then wrong. > > However, doesn't copy_type also copy the TYPE_FLOATFORMAT field? > So where would this get reset? > > Or maybe this isn't the problem at all, but then I don't understand > what > it would be. The following is from the private discussion I had with Ulrich while developing the patch. Perhaps it will help, the GCC-generated dwarf info including the hack provides the following two type records: 1) name: _Float128 type: base floating-point type (TYPE_CODE_FLT) size: 16 format: floatformats_ieee_quad and 2) name: "long double" type: typedef (TYPE_CODE_TYPEDEF) target-type: _Float128 (i.e. type 1) above) What the patch does is to keep 1) as-is, and replace 2) by 2') name: "long double" type: base floating-point type (TYPE_CODE_FLT) size: 16 format: floatformats_ieee_quad where the name is taken from 2), and the rest of the record is taken from 1). - what the actual problem is, namely the presence of a record like 2) above -which really cannot happen normally as "long double" is defined to be a base type according to the C language, so it can normally never be a typedef; - and what the patch does, namely replacing that weird typedef with a "normal" type definition for "long double", where the actual type information is taken/copied from target type of the weird typedef. > > Carl> +# The DWARF info currently does not distinquish between IEEE > 128-bit floating > Carl> +# point values and the IBM 128-bit floating point format. GCC > has an internal > Carl> +# hack that uses the _Float128 base typdef for IEEE 128-bit > float values. The > Carl> +# following method is used to "fix" the long double typedef so > the _Float128 > Carl> +# name is not printed. > Carl> +Function( > Carl> + comment=""" > Carl> +Return true if the typedef record needs to be replaced.". > Carl> + > Carl> +Return 0 by default""", > > I think the comment field could be reworded to be more clear. > I guess the idea is that some typedefs are replaced by their target > type, but given the typedef's name. The patch only replaces the typedef with information from the "target type", which is a base type, when GCC has added the typedef to identify the IEEE 128-bit floating point value. That is the GCC hack so we can identify an IEEE 128-bit value since there is no way to specify that in the DWARY ifno at this time. I will see if I can make that clearer in the comment. > > Carl> +bool > Carl> +linux_dwarf2_omit_typedef_p (struct type *target_type, > Carl> + const char *producer, const char > *name) > > I think this can be 'static'. OK, I will take a look at that change. Thanks for the input. Carl