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 879663858005 for ; Fri, 13 Oct 2023 21:00:37 +0000 (GMT) ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 879663858005 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=1697230839; cv=none; b=t6yrjDzoJk9bjr09wkSufQ5fnHQdGBNwndbDPUDTrIXAx26S+D1TU0XbnxMTsZ7bZ1pD21YvlsEjmK1OWSYh99tSu8VowH0tZ9YHrcyqQLDV7ZoG9zqKSzYatzPOB69T7wT9VAkk7LAKy0pwkw/Nhq9QgwWuk+pVCTDnOYDO0bo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697230839; c=relaxed/simple; bh=ZOW4FY8gFaBIwvru+WyIoXY44+aBneuhMK7IR1LQbK8=; h=DKIM-Signature:Message-ID:From:To:Date:Mime-Version:Subject; b=e+S4eU7JY2JXpK1D2J4bdp4D3o9XQkpTRSwZus4ST6hu+F3BiRmcAflUDqDehEdeZkTAcQCwZw8Xtmc2D4MsD6+3cCkDtnFo8g9QbAcy2nI94XDoQSYaOYYzo/9KemyyQ3ep9EIQjMXkrl7EpxwPQWOQeZCJG8UCj26rX/XU8Yo= ARC-Authentication-Results: i=1; server2.sourceware.org DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 879663858005 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 (m0353727.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39DKvofK029709 for ; Fri, 13 Oct 2023 21:00:36 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=PZ5fmES6f+9+t/B1rcr7KpZ8YgJJZ7LnuS3z9Pce/uc=; b=cfSEeikU3DFXADj0XSrAw+U59hND0GV2uwy4JZO4SqWfk5IO/lOilPGIowkSH4cOnL+t z6k98inDHl8GAdTqilBTuy2e3jRLNw/b5iFemRCSjNmnE4IaHbCfN13rAYIItusfBCPk qAdD+rXch1XPW3UGczWd5SKufxVq3TU3/E1VI4Rz5nTFV6kE/v4cNDNzB3nZbiBpm0Ya RFvPr+aV2p/x4yW8/skDYDMuRPwHJp+FWn1eG4j7aIKay5VzyCLPfaHfc8hqxazgTK20 74JPtt5XM8I0n8qS++lK89OTqHGn9SkVv+x9UgaQPZR5TbYWk6oi4udIVdf4a5Tcp4TC 6A== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3tqdcsr4fr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 13 Oct 2023 21:00:35 +0000 Received: from m0353727.ppops.net (m0353727.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 39DKwboG032005 for ; Fri, 13 Oct 2023 21:00:34 GMT Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3tqdcsr4dw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Oct 2023 21:00:34 +0000 Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 39DJAsk5016275; Fri, 13 Oct 2023 21:00:33 GMT Received: from smtprelay02.dal12v.mail.ibm.com ([172.16.1.4]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3tpt586ngp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Oct 2023 21:00:33 +0000 Received: from smtpav06.dal12v.mail.ibm.com (smtpav06.dal12v.mail.ibm.com [10.241.53.105]) by smtprelay02.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 39DL0VHp50397672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Oct 2023 21:00:31 GMT Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A5F7C58055; Fri, 13 Oct 2023 21:00:31 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EDBE658043; Fri, 13 Oct 2023 21:00:30 +0000 (GMT) Received: from wecm-9-67-110-146.wecm.ibm.com (unknown [9.67.110.146]) by smtpav06.dal12v.mail.ibm.com (Postfix) with ESMTP; Fri, 13 Oct 2023 21:00:30 +0000 (GMT) Message-ID: <3c0584d39d1077d375712fd67f59e5c451f43ffa.camel@us.ibm.com> From: Carl Love To: Keith Seitz , cel@us.ibm.com Cc: Ulrich.Weigand@de.ibm.com, gdb-patches@sourceware.org Date: Fri, 13 Oct 2023 14:00:30 -0700 In-Reply-To: <20231013203503.1548215-1-keiths@redhat.com> References: <0a1d201b8868269496bcb15fd22811607e93a0c5.camel@us.ibm.com> <20231013203503.1548215-1-keiths@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-GUID: 7MyvN-NkKjnocf9rwAxnrHDNkrA69GgL X-Proofpoint-ORIG-GUID: YIERKSmHjPe_X9lIZ8sdCyYvedm_lRrQ Subject: RE: [PATCH 2/2] PowerPC, Fix-test-gdb.base-store.exp 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-13_12,2023-10-12_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 mlxscore=0 impostorscore=0 adultscore=0 malwarescore=0 suspectscore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 clxscore=1015 mlxlogscore=602 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2310130182 X-Spam-Status: No, score=-11.0 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_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: Keith: Thanks for catching the typos. I have fixed them locally for now as noted below. Carl -------------- On Fri, 2023-10-13 at 13:35 -0700, Keith Seitz wrote: > Carl Love wrote: > > As in your previous patch, I only have some really trivial nits to > point out. > So treat similarly, and thank you for the patch. > > > 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 > > Looks like a tab got inserted above? Yea, Git gui doesn't show tabs in the window. Fixed > > > 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 > > to so it is only true for floating point values. > > "fixed [to] so" > Looks like the "to" didn't get cleanup in the last re-write. Changed "to so it" to "so it". > > 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. > > Indeed! > > Tested-by: Keith Seitz > > > Change to inline function > > Stray line or was there something more to communicate? Stray line, got missed in the last edit. Removed. Thanks. > > Keith > --- > gdb/ppc-linux-tdep.c | 4 +++ > gdb/rs6000-tdep.c | 66 > +++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 69 insertions(+), 1 deletion(-) > > diff --git a/gdb/ppc-linux-tdep.c b/gdb/ppc-linux-tdep.c > index 7fb90799dff..ba646a7230f 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" > @@ -2101,6 +2102,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. */ > > I suggest rewording this last incomplete sentence to something like: > "The mapping > for the IEEE 128-bit register numbers will have to be fixed 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..ada9cea3353 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 we have the an" --> "If we have an". "need to" --> "" > > + 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); > + > > Add "--" before "need". Similarly below in a few spots. Fixed. > > if (!get_frame_register_bytes (frame, regnum, 0, > gdb::make_array_view (from, > register_size > (gdbarch, > @@ -2715,11 +2737,52 @@ 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 Added "--" before "need". > + 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); > + frame_info_ptr frame; > + > + /* We have an IEEE 128-bit float need to > change regnum mapping from Added "--" before "need". > + fpr to vsr. */ > + regnum = ieee_128_float_regnum_adjust (gdbarch, type, regnum); > + > + value->set_lval (lval_register); > + 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 +8400,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);