From patchwork Thu Oct 12 14:58:35 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carl Love X-Patchwork-Id: 77619 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0804C385E019 for ; Thu, 12 Oct 2023 14:58:56 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 568913858404 for ; Thu, 12 Oct 2023 14:58:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 568913858404 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 (m0353728.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39CEvECX008305 for ; Thu, 12 Oct 2023 14:58:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=pp1; bh=ZRLAwki/IFCB5pO0Y4BunYMhgBcrPwaFcTsQm+9Wzws=; b=skU4VT7Z9QEXh92nqByH6oT+p7UpxqWAdcpoygse+gEuJZGgweJ+5AsMBjQTIA7jZ7JX Ka0B8SbRY+t0166arwsHvc7NIgV37MhjkdTIhJL8mA2rYiK5gnK+OSjxGFyU3q8ReuG+ 3lFvpELvJNruhK5mScSfpr7jBf2cfiIIpyNY6tyay6CrAgVWlD9wQwuNnQV4g4h6B54k WZdms6yD5xRp7f2jelKfZhlyeknk/Uk71R/u8UIM5xuJkDwLMQkaelWHD5/8O7NmcAkG uvmlZQ9S9A/Op/MghWj9YrvSOSaq0g3yG4zINeFJ9FITIyH3gfN8ISmQLVAe2jxeT0Ep gg== 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 3tpk10g21a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Oct 2023 14:58:39 +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 39CErKpO028239 for ; Thu, 12 Oct 2023 14:58:38 GMT Received: from smtprelay02.dal12v.mail.ibm.com ([172.16.1.4]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3tkj1ygbkx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Oct 2023 14:58:38 +0000 Received: from smtpav01.dal12v.mail.ibm.com (smtpav01.dal12v.mail.ibm.com [10.241.53.100]) by smtprelay02.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 39CEwb3m50332058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Oct 2023 14:58:37 GMT Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4A84358057; Thu, 12 Oct 2023 14:58:37 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AC72D58059; Thu, 12 Oct 2023 14:58:36 +0000 (GMT) Received: from wecm-9-67-110-146.wecm.ibm.com (unknown [9.67.110.146]) by smtpav01.dal12v.mail.ibm.com (Postfix) with ESMTP; Thu, 12 Oct 2023 14:58:36 +0000 (GMT) Message-ID: <76b8ed7b93608d40ab42b0538319f78eaf7d621c.camel@us.ibm.com> Subject: [Patch 1/2] PowerPC, Fix-test-gdb.base-store.exp From: Carl Love To: gdb-patches@sourceware.org, UlrichWeigand Cc: cel@us.ibm.com Date: Thu, 12 Oct 2023 07:58:35 -0700 In-Reply-To: <6f9c8fa20962129048384d74f6f15d1b37d255ed.camel@us.ibm.com> References: <6f9c8fa20962129048384d74f6f15d1b37d255ed.camel@us.ibm.com> X-Mailer: Evolution 3.28.5 (3.28.5-22.el8) Mime-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: FRiTE45g8ahA_oGiexd0qEa3jM_1D9us X-Proofpoint-ORIG-GUID: FRiTE45g8ahA_oGiexd0qEa3jM_1D9us X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-12_05,2023-10-12_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 spamscore=0 priorityscore=1501 suspectscore=0 mlxlogscore=671 clxscore=1015 mlxscore=0 bulkscore=0 phishscore=0 adultscore=0 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2310120123 X-Spam-Status: No, score=-10.5 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org GDB maintainers: This is the first patch in the series which fixes the DWWARF register mapping and signal handling issues on PowerPC. Carl ----------------------------------------------- rs6000, Fix Linux DWARF register mapping The PowerPC DWARF register mapping is the same for the .eh_frame and .debug_frame on Linux. PowerPC uses different mapping for .eh_frame and .debug_frame on other operating systems. The current GDB support for mapping the DWARF registers in rs6000_linux_dwarf2_reg_to_regnum and rs6000_adjust_frame_regnum file gdb/rs6000-tdep.c is not correct for Linux. The files have some legacy mappings for spe_acc, spefscr, EV which was removed from GCC in 2017. This patch adds a two new functions rs6000_linux_dwarf2_reg_to_regnum, and rs6000_linux_adjust_frame_regnum in file gdb/ppc-linux-tdep.c to handle the DWARF register mappings on Linux. Function rs6000_linux_dwarf2_reg_to_regnum is installed for both gdb_dwarf_to_regnum and gdbarch_stab_reg_to_regnum since the mappings are the same. The ppc_linux_init_abi function in gdb/ppc-linux-tdep.c is updated to call set_gdbarch_dwarf2_reg_to_regnum map the new function rs6000_linux_dwarf2_reg_to_regnum for the architecture. Similarly, dwarf2_frame_set_adjust_regnum is called to map rs6000_linux_adjust_frame_regnum into the architecture. The second issue fixed by this patch is the check for subroutine process_event_stop_test. Need to make sure the frame is not the SIGTRAMP_FRAME. The sequence of events on most platforms is: 1) Some code is running when a signal arrives. 2) The kernel handles the signal and dispatches to the handler. ... However on PowerPC the sequence of events is: 1) Some code is running when a signal arrives. 2) The kernel handles the signal and dispatches to the trampoline. 3) The trampoline performs a normal function call to the handler. ... We want "nexti" to step into, not over, signal handlers invoked by the kernel. This is the case most platforms as the kernel puts a signal trampoline frame onto the stack to handle proper return after the handler. However, on some platforms such as PowerPC, the kernel actually uses a trampoline to handle *invocation* of the handler. The issue is fixed in function process_event_stop_test by adding a check that the frame is not a SIGTRAMP_FRAME to the if statement to stop in a subroutine call. This prevents GDB from erroneously detecting the trampoline invocation as a subroutine call. This patch fixes two regression test failures in gdb.base/store.exp. It also fixes two regression failures in gdb.python/py-thread-exited.exp. Patch has been tested on Power 8 LE/BE, Power 9 LE/BE, Power 10 with no new regressions. Tested-by: Keith Seitz --- gdb/infrun.c | 13 ++++++++++ gdb/ppc-linux-tdep.c | 56 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 69 insertions(+) diff --git a/gdb/infrun.c b/gdb/infrun.c index 4730d290442..922d8a6913d 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -7334,8 +7334,21 @@ process_event_stop_test (struct execution_control_state *ecs) initial outermost frame, before sp was valid, would have code_addr == &_start. See the comment in frame_id::operator== for more. */ + + /* We want "nexti" to step into, not over, signal handlers invoked + by the kernel, therefore this subroutine check should not trigger + for a signal handler invocation. On most platforms, this is already + not the case, as the kernel puts a signal trampoline frame onto the + stack to handle proper return after the handler, and therefore at this + point, the current frame is a grandchild of the step frame, not a + child. However, on some platforms, the kernel actually uses a + trampoline to handle *invocation* of the handler. In that case, + when executing the first instruction of the trampoline, this check + would erroneously detect the trampoline invocation as a subroutine + call. Fix this by checking for SIGTRAMP_FRAME. */ if ((get_stack_frame_id (frame) != ecs->event_thread->control.step_stack_frame_id) + && get_frame_type (frame) != SIGTRAMP_FRAME && ((frame_unwind_caller_id (get_current_frame ()) == ecs->event_thread->control.step_stack_frame_id) && ((ecs->event_thread->control.step_stack_frame_id diff --git a/gdb/ppc-linux-tdep.c b/gdb/ppc-linux-tdep.c index 784dafa59db..7fb90799dff 100644 --- a/gdb/ppc-linux-tdep.c +++ b/gdb/ppc-linux-tdep.c @@ -83,6 +83,7 @@ #include "features/rs6000/powerpc-isa207-vsx64l.c" #include "features/rs6000/powerpc-isa207-htm-vsx64l.c" #include "features/rs6000/powerpc-e500l.c" +#include "dwarf2/frame.h" /* Shared library operations for PowerPC-Linux. */ static struct target_so_ops powerpc_so_ops; @@ -2088,6 +2089,52 @@ ppc_linux_displaced_step_prepare (gdbarch *arch, thread_info *thread, return per_inferior->disp_step_buf->prepare (thread, displaced_pc); } +/* Convert a Dwarf 2 register number to a GDB register number for Linux. */ +static int +rs6000_linux_dwarf2_reg_to_regnum (struct gdbarch *gdbarch, int num) +{ + ppc_gdbarch_tdep *tdep = gdbarch_tdep(gdbarch); + + if (0 <= num && num <= 31) + return tdep->ppc_gp0_regnum + num; + else if (32 <= num && num <= 63) + /* 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. */ + return tdep->ppc_fp0_regnum + (num - 32); + else if (77 <= num && num < 77 + 32) + return tdep->ppc_vr0_regnum + (num - 77); + else + switch (num) + { + case 65: + return tdep->ppc_lr_regnum; + case 66: + return tdep->ppc_ctr_regnum; + case 76: + return tdep->ppc_xer_regnum; + case 109: + return tdep->ppc_vrsave_regnum; + case 110: + return tdep->ppc_vrsave_regnum - 1; /* vscr */ + } + + /* Unknown DWARF register number. */ + return -1; +} + +/* Translate a .eh_frame register to DWARF register, or adjust a + .debug_frame register. */ + + +static int +rs6000_linux_adjust_frame_regnum (struct gdbarch *gdbarch, int num, + int eh_frame_p) +{ + /* Linux uses the same numbering for .debug_frame numbering as .eh_frame. */ + return num; +} + static void ppc_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch) @@ -2135,6 +2182,15 @@ ppc_linux_init_abi (struct gdbarch_info info, set_gdbarch_stap_is_single_operand (gdbarch, ppc_stap_is_single_operand); set_gdbarch_stap_parse_special_token (gdbarch, ppc_stap_parse_special_token); + /* Linux DWARF register mapping is different from the othe OS's. */ + set_gdbarch_dwarf2_reg_to_regnum (gdbarch, + rs6000_linux_dwarf2_reg_to_regnum); + /* Note on Linux the mapping for the DWARF registers and the stab registers + use the same numbers. Install rs6000_linux_dwarf2_reg_to_regnum for the + stab register mappings as well. */ + set_gdbarch_stab_reg_to_regnum (gdbarch, + rs6000_linux_dwarf2_reg_to_regnum); + dwarf2_frame_set_adjust_regnum (gdbarch, rs6000_linux_adjust_frame_regnum); if (tdep->wordsize == 4) { From patchwork Thu Oct 12 15:00:49 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carl Love X-Patchwork-Id: 77620 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0633B3853524 for ; Thu, 12 Oct 2023 15:01:09 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 584713858404 for ; Thu, 12 Oct 2023 15:00:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 584713858404 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 (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39CF0Jbo020133 for ; Thu, 12 Oct 2023 15:00:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=pp1; bh=bhMpu1CM7lf5C7SoK31bSL9PzDKbQhFS2Iyw4BAjp0A=; b=HUxeANLlgf1d5W3eEk58KSLP9/33nMkOM/gwYUcAbUQIhGhl9o6Go6hhbe6tlzfCVvP5 ZVn6Sj6GO5zpBq6uNAVaoaubdkUgMBNpNAIGVF3j2Ww9F6djvUngot6D3CJP5JcWEGD+ fUd5+Vt6wKMyLcwXvMU9nFu7cbs5ynP7mUNC4qZND+o4K1hGOa0vDHF80//oLFNZ3Z2S QC5KSpGO5NPYWXMCaeK1LRKYzhdg+J5zYg3LjDoaUqamcdOpFuDqSIcYzmbHzKmftSWU zfnMxQ5MYd52+5fC/DI+IA0SiGXyeCUOqe4lYkJFzmz0+R7+TccHcsUtDyZkKR8ZxS59 jw== Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3tpk2c01fh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Oct 2023 15:00:53 +0000 Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 39CETaJU024445 for ; Thu, 12 Oct 2023 15:00:52 GMT Received: from smtprelay03.wdc07v.mail.ibm.com ([172.16.1.70]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 3tkhnt0hye-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Oct 2023 15:00:52 +0000 Received: from smtpav02.wdc07v.mail.ibm.com (smtpav02.wdc07v.mail.ibm.com [10.39.53.229]) by smtprelay03.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 39CF0pXi19333666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Oct 2023 15:00:51 GMT Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 05D8658058; Thu, 12 Oct 2023 15:00:51 +0000 (GMT) Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4E00358071; Thu, 12 Oct 2023 15:00:50 +0000 (GMT) Received: from wecm-9-67-110-146.wecm.ibm.com (unknown [9.67.110.146]) by smtpav02.wdc07v.mail.ibm.com (Postfix) with ESMTP; Thu, 12 Oct 2023 15:00:50 +0000 (GMT) Message-ID: <0a1d201b8868269496bcb15fd22811607e93a0c5.camel@us.ibm.com> Subject: [PATCH 2/2] PowerPC, Fix-test-gdb.base-store.exp From: Carl Love To: gdb-patches@sourceware.org, UlrichWeigand Cc: cel@us.ibm.com Date: Thu, 12 Oct 2023 08:00:49 -0700 In-Reply-To: <6f9c8fa20962129048384d74f6f15d1b37d255ed.camel@us.ibm.com> References: <6f9c8fa20962129048384d74f6f15d1b37d255ed.camel@us.ibm.com> X-Mailer: Evolution 3.28.5 (3.28.5-22.el8) Mime-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: GkLpHz924AwvwHioyp_EVkZj7cBn0bfo X-Proofpoint-ORIG-GUID: GkLpHz924AwvwHioyp_EVkZj7cBn0bfo X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-12_05,2023-10-12_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 mlxlogscore=469 malwarescore=0 bulkscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 spamscore=0 priorityscore=1501 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2310120123 X-Spam-Status: No, score=-10.7 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org GDB maintainers: This is the second patch which fixes the 128-bit floating point register mappings. Carl -------------------------------------------------------- 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 to 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. Change to inline function Tested-by: Keith Seitz Reviewed-By: Andrew Burgess --- 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. */ 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 (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,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 + 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 + 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);