From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id E20FF3858C50 for ; Mon, 2 May 2022 15:04:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E20FF3858C50 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 242EoPth017131 for ; Mon, 2 May 2022 15:04:47 GMT Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3fthdjraqa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 02 May 2022 15:04:47 +0000 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 242F2A93004916 for ; Mon, 2 May 2022 15:04:46 GMT Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by ppma01wdc.us.ibm.com with ESMTP id 3frvr960jd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 02 May 2022 15:04:46 +0000 Received: from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com [9.57.199.106]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 242F4jBw24641904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 2 May 2022 15:04:45 GMT Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 91B432805E; Mon, 2 May 2022 15:04:45 +0000 (GMT) Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 100BA2805A; Mon, 2 May 2022 15:04:45 +0000 (GMT) Received: from sig-9-65-246-225.ibm.com (unknown [9.65.246.225]) by b01ledav001.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 2 May 2022 15:04:44 +0000 (GMT) Message-ID: Subject: Re: [PATCH] PowerPC: bp-permanent.exp, kill-after-signal fix From: will schmidt To: Carl Love , gdb-patches@sourceware.org Cc: Ulrich Weigand , Rogerio Alves Date: Mon, 02 May 2022 10:04:44 -0500 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: EzPf9id2YZ1gY36KwHcxxsq9jZPnKuLO X-Proofpoint-GUID: EzPf9id2YZ1gY36KwHcxxsq9jZPnKuLO X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-02_04,2022-05-02_03,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 bulkscore=0 adultscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=975 impostorscore=0 suspectscore=0 malwarescore=0 priorityscore=1501 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205020118 X-Spam-Status: No, score=-12.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2022 15:04:49 -0000 On Thu, 2022-04-28 at 18:06 -0700, Carl Love wrote: > GDB maintainers: > > The gdb.base/bp-permanent.exp and the gdb.base/kill-after-signal tests > fail on Power 10 The tests pass without the patch on Power 9 and > Intel. As stated in the commit log below, the tests have been run on > Power 10 Linux version 5.14.0-70.9.1.el9_0.ppc64le and on a Power 9 > 5.4.0-96-generic kernels. I have examined the code for the > __kernel_start_sigtramp_rt64 function on both systems and the file is > identical. As far as I can tell, the failure is hardware specific. > > The following patch fixes the issue on Power 10 without introducing any > regression failures on Power 9 or Intel. > > Please let me know if the patch is acceptable for mainline gdb. > Thanks. > > Carl Love > > ---------------------------------------------------------------------- > PowerPC: bp-permanent.exp, kill-after-signal fix > > The break point after the stepi on Intel is the entry point of the user > signal handler function test_signal_handler. The code at the break point > looks like: > > 0x : endbr64 > > On Power 10, the address where gdb stops after the stepi is in the kernel. > The code at the breakpoint looks like: > > 0x <__kernel_start_sigtramp_rt64>: bctrl > > Power 10 requires one more stepi to reach the user signal handler. > > The tests run fine on Power 9. The tests have been run on multiple Power 10 > systems. The tests were done with newer and older Linux kernels and gcc > compiler versions from the Power 9 system. The tests fail identically on > the two Power 10 systems but pass on the Power 9 system. > > The two tests were run on the following PowerPC configurations: > > Power 9, Ubuntu 20.04 LE, linux 5.4.0-96-generic, > gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 > > gdb.base/bp-permanent.exp 186 passes, no failures > gdb.base/kill-after-signal.exp 4 passes, no failures > > Power 10, RHEL 9, Linux 5.14.0-70.9.1.el9_0.ppc64le, > gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9) > gdb.base/bp-permanent.exp 182 passes, 4 failures > gdb.base/kill-after-signal.exp 3 passes, 1 failure > > Power 10, SLE 15 SP3 , Linux 5.3.18-150300.59.63-default, > gcc (SUSE Linux) 7.5.0 > gdb.base/bp-permanent.exp 182 passes, 4 failures > gdb.base/kill-after-signal.exp 3 passes, 1 failure > > The following patch fixes the tests on Power 10. The patch does not > introduce regessions on Power 9 or Intel systems. > --- > gdb/testsuite/gdb.base/bp-permanent.exp | 8 ++++++++ > gdb/testsuite/gdb.base/kill-after-signal.exp | 15 ++++++++++++++- > 2 files changed, 22 insertions(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.base/bp-permanent.exp b/gdb/testsuite/gdb.base/bp-permanent.exp > index 8be46e96238..f3f47e675ff 100644 > --- a/gdb/testsuite/gdb.base/bp-permanent.exp > +++ b/gdb/testsuite/gdb.base/bp-permanent.exp > @@ -258,8 +258,16 @@ proc test {always_inserted sw_watchpoint} { > set test "single-step to handler" > gdb_test_multiple "stepi" $test { > -re "Program received signal SIGTRAP.*$gdb_prompt $" { > + # Intel needs one stepi to get to the signal handler. > fail $test > } > + -re ".*signal handler called.*" { > + # PowerPC needs one more stepi to reach the user > + # signal handler. So.. Is this directly related to the amount of kernel code handling the signals? i.e. Would this need to be updated if another instruction is added to the kernel code? I've tentatively expected to see a comment here with some form of "If we are still in the kernel handler, stepi until we reach user ..." Thanks, > + gdb_test "p \$pc" ".*__kernel_start_sigtramp_rt64.*" \ > + "In kernel" > + gdb_test "stepi" "$decimal.*\{" $test > + } > -re "handler .*$gdb_prompt $" { > pass $test > } > diff --git a/gdb/testsuite/gdb.base/kill-after-signal.exp b/gdb/testsuite/gdb.base/kill-after-signal.exp > index 09f5cbc39a6..fc1f82bc70a 100644 > --- a/gdb/testsuite/gdb.base/kill-after-signal.exp > +++ b/gdb/testsuite/gdb.base/kill-after-signal.exp > @@ -36,7 +36,20 @@ if ![runto_main] { > } > > gdb_test "continue" "Program received signal SIGUSR1, .*" > -gdb_test "stepi" "\r\nhandler .*" > + > +set test "handler" > +gdb_test_multiple "stepi" $test { > + -re "\r\nhandler .*" { > + # Intel requires one stepi to get to the signal handler. > + pass $test > + } > + -re ".*signal handler called.*" { > + # PowerPC needs one more stepi to reach the user signal handler. > + gdb_test "p \$pc" ".*__kernel_start_sigtramp_rt64.*" "In kernel" > + gdb_test "stepi" "$decimal.*\{" $test > + } > +} > + > gdb_test_multiple "kill" "kill" { > -re "Kill the program being debugged\\? \\(y or n\\) $" { > gdb_test "y" "\\\[Inferior $decimal \\(.*\\) killed\\\]" "kill"