From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 8E2513858C54 for ; Fri, 14 Apr 2023 15:35:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8E2513858C54 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 (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33EFDJPu001160; Fri, 14 Apr 2023 15:35:26 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 : mime-version : content-transfer-encoding : subject; s=pp1; bh=urktyQMX/vW5klgkFBhD2SXqT2MhXAMnR3HNyLTj8DA=; b=JVsdRZ5GkzXvj0CTPGLqOffjp8kAlQjDJDoSJBhgp7/ADv3hmYw2MhBjRHB7RBNNl6U9 nXQfLfdshBMUP94jBVBOWfRS3wp22UIOmKKoAJcNt8SQlsCFLXBMeMmi+YNVYtKb4Ijy PfNvWCwM2y214DATjyGda2o8cL2fh8NJlLuiGt0m3zmgl+ajrIiIgrBoMwbC0nTDf2HL JkhVMJLBVznsMSYa/gdqMpOd237F9cb1CJAAlHTARY4crfiovigZ7qDowdZCthWIWzNa mSbQf3IecHSMYfED1Cj73SsTisrSaRMDm8nw+ATaA/wFQzGBEE61RZzUIadMUvCBoigp Ag== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3py999rwgs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Apr 2023 15:35:26 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 33EFDSFc002348; Fri, 14 Apr 2023 15:35:25 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3py999rwg5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Apr 2023 15:35:25 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 33EDc3Tn029817; Fri, 14 Apr 2023 15:35:25 GMT Received: from smtprelay04.dal12v.mail.ibm.com ([9.208.130.102]) by ppma02dal.us.ibm.com (PPS) with ESMTPS id 3pu0fr1kqs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Apr 2023 15:35:25 +0000 Received: from smtpav01.wdc07v.mail.ibm.com (smtpav01.wdc07v.mail.ibm.com [10.39.53.228]) by smtprelay04.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 33EFZL432097890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Apr 2023 15:35:22 GMT Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C292D58065; Fri, 14 Apr 2023 15:35:21 +0000 (GMT) Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 29D6758063; Fri, 14 Apr 2023 15:35:21 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.150.219]) by smtpav01.wdc07v.mail.ibm.com (Postfix) with ESMTP; Fri, 14 Apr 2023 15:35:21 +0000 (GMT) Message-ID: <0039ecebd46d4638c1f93a5e7964d4bc54cfae85.camel@us.ibm.com> From: Carl Love To: Tom Tromey , gdb-patches@sourceware.org Cc: Ulrich Weigand , Kevin Buettner , cel@us.ibm.com Date: Fri, 14 Apr 2023 08:35:20 -0700 In-Reply-To: <87wn2e4lys.fsf@tromey.com> References: <184c0edcf067acccdf71d4dcdd66447bb5d93d4c.camel@us.ibm.com> <1b5d214a6208c422963e58c27c98f81af9601628.camel@us.ibm.com> <87fs936f1o.fsf@tromey.com> <33972784460b21164a6581664f647c4edc03c1f9.camel@us.ibm.com> <87wn2e4lys.fsf@tromey.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: VWxjx3O_EyeBOAOvSY4iwZpi3ImpjVlz X-Proofpoint-GUID: pKncJJly2rlMZtn8aIxtD5AydE1EXoPj 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-14_08,2023-04-14_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 priorityscore=1501 impostorscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 clxscore=1015 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304140137 X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: Tom: On Fri, 2023-04-14 at 07:44 -0600, Tom Tromey wrote: > > > > > > "Carl" == Carl Love via Gdb-patches < > > > > > > gdb-patches@sourceware.org> writes: > > > However, doesn't copy_type also copy the TYPE_FLOATFORMAT field? > > > So where would this get reset? > > Carl> the GCC-generated dwarf info including the hack provides > Carl> the following two type records: > > Carl> 1) name: _Float128 > Carl> type: base floating-point type (TYPE_CODE_FLT) > Carl> size: 16 > Carl> format: floatformats_ieee_quad > > Carl> and > > Carl> 2) name: "long double" > Carl> type: typedef (TYPE_CODE_TYPEDEF) > Carl> target-type: _Float128 (i.e. type 1) above) > > Carl> What the patch does is to keep 1) as-is, and replace 2) by > > Carl> 2') name: "long double" > Carl> type: base floating-point type (TYPE_CODE_FLT) > Carl> size: 16 > Carl> format: floatformats_ieee_quad > > Carl> where the name is taken from 2), and the rest of the > Carl> record is taken from 1). > > Sorry for going in circles on this, but I still don't really get it. > > From what I can see, the difference between (2) and (2') is just that > one is a typedef and one is not. Where does this matter? > OK, I think I know what you are not getting. When the user wants to know the type of a variable, it gets the name from the base type. For example in the test program gdb/testsuite/gdb.base/whatis-ptype-typedefs.c, we have the declaration: typedef long double long_double_typedef; On PowerPC, if GCC is using IEEE float 128-bit for the long double format, the test case uses the ptype command to get the type of the variable long_double_typedef, i.e. ptype v_long_double_typedef2 without the patch, GDB returns the base type name, in this case GDB prints: type = _Float128 Note the type the user specified of "long double" and the GDB test case is expecting the result to be "long double". This results in the 74 test failures on PowerPC with when GCC uses IEEE float 128-bit. The "_Float128" is printed because the "long double" is typedef pointing at the base type "_Float 128". GDB tells the user the type of the variable is something that the user didn't specify which is very confusing to them, and to the testcase. This is where the GCC "hack" for identifying the "long double" as an IEEE 128-bit float value rather than the IBM 128-bit float value is not transparent to GDB. The GCC hack created this typedef for "long double", which should never be a typedef since it is a base type in C. The patch basically undoes the GCC hack by making the type for "long double" a proper base type again using the info from the _Float128 base type and the correct name "long double". Now, the GDB ptype command prints the proper type name and the rest of the type info is there that GDB needs. The comment in gdb/gdbarch_components.py mentions that with the patch the proper name is printed, but yea I can see where that wasn't completely obvious to you. Does that help? Carl