From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id oEliNtVyOWQztSsAWB0awg (envelope-from ) for ; Fri, 14 Apr 2023 11:35:49 -0400 Received: by simark.ca (Postfix, from userid 112) id CB9CA1E221; Fri, 14 Apr 2023 11:35:49 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=sqYkWBJu; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 55B151E0D3 for ; Fri, 14 Apr 2023 11:35:49 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7F9803858401 for ; Fri, 14 Apr 2023 15:35:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7F9803858401 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1681486547; bh=urktyQMX/vW5klgkFBhD2SXqT2MhXAMnR3HNyLTj8DA=; h=To:Cc:Date:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=sqYkWBJuWYQ1V9p0RxzoQ7OpFdPw1g0NzBhfVM97qezPcsjajBgBs7rsHGzv/g7mX 8tm519PdVNmn0R8fXIytk+jd1OZg3AzWBaPATkKo1Ugw3d5pamBusNyOrH/k/7Ice2 uB+qb3rAKp/y33MqgHmsRnd1uMY4FtG8iO0liYGY= 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 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 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> 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-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Carl Love via Gdb-patches Reply-To: Carl Love Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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