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 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> 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: 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 List-Id: 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. --- 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) { -- 2.37.2