From patchwork Mon Oct 30 17:25:02 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carl Love X-Patchwork-Id: 78789 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 1AFE83858000 for ; Mon, 30 Oct 2023 17:25:26 +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 7C2F63858CDA for ; Mon, 30 Oct 2023 17:25:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7C2F63858CDA 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 7C2F63858CDA 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=1698686710; cv=none; b=Mb20381L/lCnX2MPnHo6oLdKoTU6GRcSJ4lrnVZwse5UW6awceVZ09Q16ZhvZmO58Sm+Q4Cyy6UVByQPECV97WNgq1X8vrpUxbyE0ucTB1LlXfB5j5kJuBJAIPO608Hbabw6ioYet8ZPMh8vJsFvRpqJrNDBSXTOly30U0yZvVE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698686710; c=relaxed/simple; bh=gWs6oCA1bEOSq4mjYpLgBQmLinhv1V8oDG3PJs/Lp6g=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:Mime-Version; b=VEo5Nlw7OdWG+RKWJ9EFWcnGgqXXWjf9OGMx1hwbn12PrNm+kV8t4VJ5eMqZfpNLG4XrRyNDjm483BY7sMtxIIlwdVo9Xc+25vDVi3pW6fVoBoubuP6zKYU5SdqmuigFIARtp+XKtV4uBnM5oRVlX/ICMoZgTAWuSnp0TCaDKRo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39UHKulY006343 for ; Mon, 30 Oct 2023 17:25:07 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=tqpq8ndNpvc4ojDDnlbGxAoGEnf1L+xAqoxIHuyJ/eU=; b=Lg9TkKVX5soYsQ16xisxPt4/lp0KCZ7UNywGIZheAoc2xoLyDQLmPvU8tLOOZQeVQl/t yFm3zOqb2NNdw52f8SQAVUKEvVa++Ij2g+VqqDSsZi79QepZpoeBG3i3dfJeWe7thq3B 1EiAJwCs6cecO8QXxmxtAD2JhFdRv56h3t+mHRWhTGVND6SXwthKfANul4RDCW0VwKzm OCl9KXx/89mi0IwC458MAjpir7EGlhH+t4V/X4ZL6r0tVaJ/8K53wcGv8/OJBvUpxhvJ /x3sydAdN0UZ4WoLvYTCaq/+BRM9ifhK5tvvsA3mCzjcJn91YGjqw6ef8tMphuzdvyCq zA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3u2gf7rpyg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 30 Oct 2023 17:25:07 +0000 Received: from m0353729.ppops.net (m0353729.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 39UHL2iY007404 for ; Mon, 30 Oct 2023 17:25:06 GMT Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3u2gf7rpxu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Oct 2023 17:25:06 +0000 Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 39UG1mcF031452; Mon, 30 Oct 2023 17:25:05 GMT Received: from smtprelay02.dal12v.mail.ibm.com ([172.16.1.4]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 3u1fb1t4m9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Oct 2023 17:25:05 +0000 Received: from smtpav01.wdc07v.mail.ibm.com (smtpav01.wdc07v.mail.ibm.com [10.39.53.228]) by smtprelay02.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 39UHP4wZ51773876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 30 Oct 2023 17:25:04 GMT Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 65FB858067; Mon, 30 Oct 2023 17:25:04 +0000 (GMT) Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0C2785805B; Mon, 30 Oct 2023 17:25:03 +0000 (GMT) Received: from wecm-9-67-110-146.wecm.ibm.com (unknown [9.67.110.146]) by smtpav01.wdc07v.mail.ibm.com (Postfix) with ESMTP; Mon, 30 Oct 2023 17:25:02 +0000 (GMT) Message-ID: <77710bdab4d396d3a4d001bfb2217d00e686c823.camel@linux.ibm.com> Subject: [PATCH 1/2, ver3] PowerPC, Fix-test-gdb.base-store.exp From: Carl Love To: Ulrich Weigand , "gdb-patches@sourceware.org" , Andrew Burgess , Keith Seitz Cc: cel@us.ibm.com Date: Mon, 30 Oct 2023 10:25:02 -0700 In-Reply-To: <62b44b45916ee898484992d57cc7bfa2ca0bc040.camel@de.ibm.com> References: <6f9c8fa20962129048384d74f6f15d1b37d255ed.camel@us.ibm.com> <76b8ed7b93608d40ab42b0538319f78eaf7d621c.camel@us.ibm.com> <87bkcyhc5g.fsf@redhat.com> <8735bded66303c8cdfacfad9bd953c582e8076f2.camel@linux.ibm.com> <87sf602wqt.fsf@redhat.com> <51fbddb2f868c778660c592a91c39677a3763197.camel@de.ibm.com> <87ttq81m09.fsf@redhat.com> <62b44b45916ee898484992d57cc7bfa2ca0bc040.camel@de.ibm.com> X-Mailer: Evolution 3.28.5 (3.28.5-22.el8) Mime-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: G1ZZYPE-BavGi9QEbdxtNBNvOpOdRh_B X-Proofpoint-GUID: M6hdPo2A04R8bd9K3OSCDkpeGJ7tECwT X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-30_11,2023-10-27_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 mlxscore=0 suspectscore=0 mlxlogscore=976 lowpriorityscore=0 phishscore=0 spamscore=0 clxscore=1015 priorityscore=1501 bulkscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2310240000 definitions=main-2310300136 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 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 Andrew, Ulrich: Per the discussions, the commit message has been updated to make it clear that the patch fixes the DWARF register mapping which fixes two of the test failures in step.exp. The fix exposed a dormant issue with the signal handling on PowerPC. The underlying issue which is then exposed causes the signal handling test sigstep.exp to fail. The test sigstep.exp tests stepping into a signal handler. The patch also fixes the underlying signal handler issue. This new verion of the patch only updates the commit log to make it clear the patch is fixing multiple issues. Please let me know if the commit description is clear and acceptable. Thanks. Carl ------------------------------------------------------------ rs6000, Fix Linux DWARF register mapping Overview of issues fixed by the patch. The primary issue this patch fixes is the DWARF register mapping for Linux. The changes in ppc-linux-tdep.c fix the DWARF register mapping issues. The register mapping issue is responsible for two of the five regression bugs seen in gdb.base/store.exp. Once the register mapping is fixed, an underlying issue with the unwinding of the signal trampoline in common-code in ifrun.c was found. This underlying bug is best described by Ulrich in the following description. The unwinder bug shows up on platforms where the kernel uses a trampoline to dispatch "calls to" the signal handler (not just *returns from* the signal handler). Many platforms use a trampoline for signal return, and that is working fine, but the only platform I'm (Ulrich) aware of that uses a trampoline for signal handler calls is (recent kernels for) PowerPC. I believe the rationale for using a trampoline here is to improve performance by avoiding unbalancing of the branch predictor's call/return stack. However, on PowerPC the bug is dormant as well as it is hidden by *another* bug that prevents correct unwinding out of the signal trampoline. This is because the custom CFI for the trampoline uses a register number (VSCR) that is not ever used by compiler-generated CFI, and that particular register is mapped to an invalid number by the current PowerPC DWARF mapper. The underlying unwinder bug is exposed by the "new" regression failures in gdb.base/sigstep.exp. These failures were previously masked by the fact that GDB was not seeing a valid frame when it tried to unwind the frames. The sigstep.exp test is specifically testing stepping into a signal handler. With the correct DWARF register mapping in place, specifically the VSCR mapping, the signal trampoline code now unwinds to a valid frame exposing the pre-existing bug in how the signal handler on PowerPC works. The one line change infrun.c fixes the exiting bug in the common-code for platforms that use a trampoline to dispatch calls to the signal handler by not stopping in the SIGTRAMP_FRAME. Detailed description of the DWARF register mapping fix. 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. Additional detail on the signal handling fix. The specific sequence of events for handling a signal on most architectures is as follows: 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 the "nexti" to step into, not over, signal handlers invoked by the kernel. This is the case for 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. We do not want GDB to stop in the SIGTRAMP_FRAME. 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. The patch then fixes an exposed, dormant, signal handling issue that is exposed in the signal handling test gdb.base/sigstep.exp. The patch has been tested on Power 8 LE/BE, Power 9 LE/BE, Power 10 with no new regressions. Note, only two of the five failures in store.exp are fixed. The remaining three failures are fixed in a following patch. --- gdb/infrun.c | 13 +++++++++++ gdb/ppc-linux-tdep.c | 53 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 66 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..8d975336fe5 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,49 @@ 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) + 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 +2179,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 other OSes. */ + 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) {