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 1D4C93858414 for ; Fri, 20 Oct 2023 18:08:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1D4C93858414 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1D4C93858414 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697825293; cv=none; b=KCyeRK9oBSHoqv1cO42fJOlghgya2G/Vk1xeQGFCr6Qr9Zn7YKgFZR9fJMEgQkzErwnnPOJQhwg5yxxuY3jWdmHbESMJhThXUZ0/N1ZBXG4N3TZxNmlGpRTf+l4fgRUt8EBe45+X7Ti69XpyXDnxWfPriTEDDSCvVFXAhHsf6Cw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697825293; c=relaxed/simple; bh=unCPRYxzAPs9dmlKRLFRfo4wE1g8qLfZWWcNAww/2lc=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:Mime-Version; b=KBlPVGoRQQez0W7ixKCzURBKflZcGGZh4OkfhzORMgPBR8n3P4lo41uA2srlIjfguS7ZFS6FNXJLBWvMC69bvqprf2KD5ebH1jk+4yrfCf8Ued2IUZk3n+u5IjybcTs7L3agSMXS9Hz/I/OpO9z6mYH0foHKiZxR4/exdwqbwc0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353728.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39KHlKCa028695 for ; Fri, 20 Oct 2023 18:08:11 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=pp1; bh=4mnMa4oGfO1m/ue6+GAu9MlZfRyCgLi81Mq77MXvUnQ=; b=klwdhRf4yHMfgTCm/WPg6KuLH+DkhO2jTT9X/G1Q/Qxd8GLperyh860rU1fFH+hw7dR0 uB2Xh7tN34Yv3R85j7uMPt3NGZEQCsKvpKQLzBnbFBhkn7f9oEWJBLk+kbEZc4ha5wqi vMcLoezFFQkM+mGEqoBp1OmqeLOJBrOakAajTD7TxXGVIBFOOh+Tvx6jQOOXqwAoJ6rK PIh+rz/GE3n6j35P6Kg3Le9GH9+sF0y/E4qwvDMz5p+97A0i1Z6iJuSIoy9/7h8aKvch PHJEVy6xxDI/HXwNG7o79Um0HlbBgrm6ZmfMgKntg+kescm11a8CTSG4h64gS2kBk93N Zw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3tux8nrneb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 20 Oct 2023 18:08:10 +0000 Received: from m0353728.ppops.net (m0353728.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 39KHlacS029597 for ; Fri, 20 Oct 2023 18:08:09 GMT Received: from ppma21.wdc07v.mail.ibm.com (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3tux8nrna2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2023 18:08:09 +0000 Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1]) by ppma21.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 39KHeO6l024205; Fri, 20 Oct 2023 18:08:07 GMT Received: from smtprelay07.dal12v.mail.ibm.com ([172.16.1.9]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3tuc296bd8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2023 18:08:07 +0000 Received: from smtpav05.dal12v.mail.ibm.com (smtpav05.dal12v.mail.ibm.com [10.241.53.104]) by smtprelay07.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 39KI86iG52298406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Oct 2023 18:08:06 GMT Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 172A058056; Fri, 20 Oct 2023 18:08:06 +0000 (GMT) Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 40A5F58052; Fri, 20 Oct 2023 18:08:05 +0000 (GMT) Received: from wecm-9-67-110-146.wecm.ibm.com (unknown [9.67.110.146]) by smtpav05.dal12v.mail.ibm.com (Postfix) with ESMTP; Fri, 20 Oct 2023 18:08:05 +0000 (GMT) Message-ID: <4e8742f920adecfedc347e386bf7f65f3ec62291.camel@linux.ibm.com> Subject: [PATCH 2/2] PowerPC, Fix-test-gdb.base-store.exp From: Carl Love To: Andrew Burgess , Carl Love , gdb-patches@sourceware.org, UlrichWeigand , keiths@redhat.com Date: Fri, 20 Oct 2023 11:08:04 -0700 In-Reply-To: <878r82hbwl.fsf@redhat.com> References: <6f9c8fa20962129048384d74f6f15d1b37d255ed.camel@us.ibm.com> <0a1d201b8868269496bcb15fd22811607e93a0c5.camel@us.ibm.com> <878r82hbwl.fsf@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-22.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: BGn5LuuEsqoUKbNRVh4d44hQ3R50fNiQ X-Proofpoint-GUID: 5A01KvpddMVUuysD6JC-w5cpeVqVOj-d X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-20_10,2023-10-19_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxscore=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 adultscore=0 spamscore=0 impostorscore=0 phishscore=0 mlxlogscore=586 clxscore=1015 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2310170001 definitions=main-2310200152 X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,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: GDB maintainers: Ver 2: In the new function, rs6000_value_from_register, moved the declaration of frame to where it gets initialized. Patch was retested on Power10. This is the second patch which fixes the 128-bit floating point register mappings. This fixes the remaining three issues with the store.exp test. Carl ----------------------------------------- rs6000, Fix test gdb.base/store.exp The test currently fails for IEEE 128-bit floating point types. PowerPC supports the IBM double 128-bit floating point format and IEEE 128-bit format. The IBM double 128-bit floating point format uses two 64-bit floating point registers to store the 128-bit value. The IEEE 128-bit floating point format stores the value in a single 128-bit vector-scalar register (vsr). The various floating point values, 32-bit float, 64-bit double, IBM double 128-bit float and IEEE 128-bit floating point numbers are all mapped to the DWARF fpr numbers. The issue is the IEEE 128-bit floating point values are actually stored in a vsr not the fprs. This patch changes the register mapping for the vsrs from the fpr to the vsr registers so the value is properly accessed by GDB. The functions rs6000_linux_register_to_value, rs6000_linux_value_to_register, rs6000_linux_value_from_register check if the value is an IEEE 128-bit floating point value and adjust the register number as needed. The test in function rs6000_convert_register_p is fixed so it is only true for floating point values. This patch fixes three regression tests in gdb.base/store.exp. The patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 LE with no regressions. --- gdb/ppc-linux-tdep.c | 4 +++ gdb/rs6000-tdep.c | 65 +++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 68 insertions(+), 1 deletion(-) diff --git a/gdb/ppc-linux-tdep.c b/gdb/ppc-linux-tdep.c index dc03430e2af..fac56d961cb 100644 --- a/gdb/ppc-linux-tdep.c +++ b/gdb/ppc-linux-tdep.c @@ -63,6 +63,7 @@ #include #include "elf-bfd.h" #include "producer.h" +#include "target-float.h" #include "features/rs6000/powerpc-32l.c" #include "features/rs6000/powerpc-altivec32l.c" @@ -2102,6 +2103,9 @@ rs6000_linux_dwarf2_reg_to_regnum (struct gdbarch *gdbarch, int num) /* FIXME: jimb/2004-05-05: What should we do when the debug info specifies registers the architecture doesn't have? Our callers don't check the value we return. */ + /* Map dwarf register numbers for floating point, double, IBM double and + IEEE 128-bit floating point to the fpr range. Will have to fix the + mapping for the IEEE 128-bit register numbers later. */ return tdep->ppc_fp0_regnum + (num - 32); else if (77 <= num && num < 77 + 32) return tdep->ppc_vr0_regnum + (num - 77); diff --git a/gdb/rs6000-tdep.c b/gdb/rs6000-tdep.c index 23397d037ae..186646673f0 100644 --- a/gdb/rs6000-tdep.c +++ b/gdb/rs6000-tdep.c @@ -2676,7 +2676,25 @@ rs6000_convert_register_p (struct gdbarch *gdbarch, int regnum, && regnum < tdep->ppc_fp0_regnum + ppc_num_fprs && type->code () == TYPE_CODE_FLT && (type->length () - != builtin_type (gdbarch)->builtin_double->length ())); + == builtin_type (gdbarch)->builtin_float->length ())); +} + +static int +ieee_128_float_regnum_adjust (struct gdbarch *gdbarch, struct type *type, + int regnum) +{ + ppc_gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); + + /* If we have the an IEEE 128-bit floating point value, need to map the + register number to the corresponding VSR. */ + if (tdep->ppc_vsr0_regnum != -1 + && regnum >= tdep->ppc_fp0_regnum + && regnum < (tdep->ppc_fp0_regnum + ppc_num_fprs) + && (gdbarch_long_double_format (gdbarch) == floatformats_ieee_quad) + && (type->length() == 16)) + regnum = regnum - tdep->ppc_fp0_regnum + tdep->ppc_vsr0_regnum; + + return regnum; } static int @@ -2691,6 +2709,10 @@ rs6000_register_to_value (frame_info_ptr frame, gdb_assert (type->code () == TYPE_CODE_FLT); + /* We have an IEEE 128-bit float -- need to change regnum mapping from + fpr to vsr. */ + regnum = ieee_128_float_regnum_adjust (gdbarch, type, regnum); + if (!get_frame_register_bytes (frame, regnum, 0, gdb::make_array_view (from, register_size (gdbarch, @@ -2715,11 +2737,51 @@ rs6000_value_to_register (frame_info_ptr frame, gdb_assert (type->code () == TYPE_CODE_FLT); + /* We have an IEEE 128-bit float -- need to change regnum mapping from + fpr to vsr. */ + regnum = ieee_128_float_regnum_adjust (gdbarch, type, regnum); + target_float_convert (from, type, to, builtin_type (gdbarch)->builtin_double); put_frame_register (frame, regnum, to); } +static struct value * +rs6000_value_from_register (struct gdbarch *gdbarch, struct type *type, + int regnum, struct frame_id frame_id) +{ + int len = type->length (); + struct value *value = value::allocate (type); + + /* We have an IEEE 128-bit float -- need to change regnum mapping from + fpr to vsr. */ + regnum = ieee_128_float_regnum_adjust (gdbarch, type, regnum); + + value->set_lval (lval_register); + frame_info_ptr frame = frame_find_by_id (frame_id); + + if (frame == NULL) + frame_id = null_frame_id; + else + frame_id = get_frame_id (get_next_frame_sentinel_okay (frame)); + + VALUE_NEXT_FRAME_ID (value) = frame_id; + VALUE_REGNUM (value) = regnum; + + /* Any structure stored in more than one register will always be + an integral number of registers. Otherwise, you need to do + some fiddling with the last register copied here for little + endian machines. */ + if (type_byte_order (type) == BFD_ENDIAN_BIG + && len < register_size (gdbarch, regnum)) + /* Big-endian, and we want less than full size. */ + value->set_offset (register_size (gdbarch, regnum) - len); + else + value->set_offset (0); + + return value; +} + /* The type of a function that moves the value of REG between CACHE or BUF --- in either direction. */ typedef enum register_status (*move_ev_register_func) (struct regcache *, @@ -8337,6 +8399,7 @@ rs6000_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) set_gdbarch_convert_register_p (gdbarch, rs6000_convert_register_p); set_gdbarch_register_to_value (gdbarch, rs6000_register_to_value); set_gdbarch_value_to_register (gdbarch, rs6000_value_to_register); + set_gdbarch_value_from_register (gdbarch, rs6000_value_from_register); set_gdbarch_stab_reg_to_regnum (gdbarch, rs6000_stab_reg_to_regnum); set_gdbarch_dwarf2_reg_to_regnum (gdbarch, rs6000_dwarf2_reg_to_regnum); -- 2.37.2