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 402D83858D33 for ; Fri, 20 Jan 2023 20:04:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 402D83858D33 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 (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30KJT0Yb012572; Fri, 20 Jan 2023 20:04:57 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=fMHzhz6ws2cwAw2Jq4yNYHL8FSpMQU1R/QMk2uHAD/k=; b=Q0YqD8Gej7kT1IoaMpEjZcva+b3IU3NI5V0K+mdoHdnOLhdO5FAiPihWZuMHU+wS9zgP IJYmGKzqz1vx+YWSBjvv/+espTf6KYQ0a+/qOMqtEpFmm8fjZTXM8sb7ehpheKYHhKIS px+nOQcgwJJCNUY1fkPmeOIUi/IiO2Nf88Tv8BFxh8J979vkAE7y3vo1t++3/nnrZmlu dVRuBnw376ub+VLSHpGyuO8J+99tQQioTg8FF5c6UGBvU9KYtSn0zlJB3K08nlPloNne UFa5YDpiO84e9f3I+WVTQf3F0m/OLqZJBWZqp6NMMbJ5klgJX/lCPjj/K+hlL0MVT23m /w== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3n8159rpem-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Jan 2023 20:04:57 +0000 Received: from m0098410.ppops.net (m0098410.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 30KJxuOE021577; Fri, 20 Jan 2023 20:04:56 GMT Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3n8159rpe1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Jan 2023 20:04:56 +0000 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 30KJv6ZS024159; Fri, 20 Jan 2023 20:04:55 GMT Received: from smtprelay04.dal12v.mail.ibm.com ([9.208.130.102]) by ppma05wdc.us.ibm.com (PPS) with ESMTPS id 3n3m1843u8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Jan 2023 20:04:55 +0000 Received: from smtpav04.wdc07v.mail.ibm.com (smtpav04.wdc07v.mail.ibm.com [10.39.53.231]) by smtprelay04.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 30KK4srl8061608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Jan 2023 20:04:54 GMT Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3752458050; Fri, 20 Jan 2023 20:04:54 +0000 (GMT) Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 932C358045; Fri, 20 Jan 2023 20:04:53 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.163.12.142]) by smtpav04.wdc07v.mail.ibm.com (Postfix) with ESMTP; Fri, 20 Jan 2023 20:04:53 +0000 (GMT) Message-ID: <71aa635593df0677811afb85409aa190bcfa4f6a.camel@us.ibm.com> From: Carl Love To: Bruno Larsen , Tom de Vries , Ulrich Weigand , gdb-patches@sourceware.org Cc: cel@us.ibm.com Date: Fri, 20 Jan 2023 12:04:53 -0800 In-Reply-To: References: <071f24ecf9b3a2bbbe8fee7db77492eb55c5f3ff.camel@us.ibm.com> <1d9b21914354bef6a290ac30673741e722e11757.camel@de.ibm.com> <3e3c9c40f07ab01c79fe10915e76ffa187c42ad9.camel@us.ibm.com> <122f5d2d3db9ef1979b0f8da927d005f32bba82c.camel@us.ibm.com> <011768e8-2b76-f8ed-1174-fbaa020b15e7@redhat.com> <78b464a1-e32e-c3da-85e4-7bfc322cc29f@redhat.com> <7848e9858b54e33e399b871774ffc0b5058c1736.camel@us.ibm.com> <65d44121-65f7-a212-79ec-07ce53c15ecb@suse.de> <9fe94c0979cb40979b0dea7693a901c2d9f66164.camel@us.ibm.com> <59417813-eb4a-baf8-4e5d-e225d6732f71@suse.de> <7a494157-494f-6adf-d533-bf373b0f054f@redhat.com> 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-GUID: NQQUfvO3hgAYlLCxa66wazbULoZfRK2Q X-Proofpoint-ORIG-GUID: -nfsqDCJD0l5YhHgGmQVoDD2mMbDDY2g Subject: RE: [PATCH 2/2 version 2] fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-01-20_10,2023-01-20_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 malwarescore=0 mlxscore=0 suspectscore=0 mlxlogscore=999 lowpriorityscore=0 priorityscore=1501 impostorscore=0 phishscore=0 bulkscore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301200190 X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,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: On Thu, 2023-01-19 at 15:57 -0800, Carl Love wrote: > Bruno, Tom: > > > On Thu, 2023-01-19 at 08:56 -0800, Carl Love wrote: > > > Without the patch, when you were in the main program at "answer += 1" > and did a reverse-next, gdb would go back thru the call to function > bar > and thru the call to function foo stopping in main. That doesn't > seem > right to me as you have stepped back thru function foo and bar. > > With the patch the reverse-next only step back thru function bar and > stops in function foo at the call to bar, i.e. doesn't continue to > step > back thru function bar. > > The following is the tailcall source code with comments showing where > the reverse-step and reverse-next stop with and without the X86 patch > applied. Hopefully the code below is a little easier to follow. > Initially, the reverse-step and reverse-next tests are executed from > the line "answer += 1;" in function main. > > > static __attribute__ ((noinline)) int > bar (void) > { > return 42; > } <- reverse-step stops here (with no patch > and with X86 patch) > > static __attribute__ ((noinline)) int > foo (void) > { > return bar (); <- reverse-next stops here (patch X86 applied) > } > > int > main (void) > { > int answer; > > answer = foo (); <- reverse-next tops here (no patch applied, > stepped > back thru both the bar and foo functions) > answer += 1; <- GDB is here, now issue the reverse-step > and reverse-next commands > > return answer; > } > > As a result of the change in the reverse-next instruction, the > expected > test results for the tailcall test need to be updated to reflect the > fact that gdb now stops in function foo not main. > > --- a/gdb/testsuite/gdb.btrace/tailcall.exp > +++ b/gdb/testsuite/gdb.btrace/tailcall.exp > @@ -102,9 +102,9 @@ gdb_test "reverse-step" "\[^\r\n\]*main \\(\\) at > tailcall.c > :37\r\n.*" \ > "reverse-step.2" > gdb_test "next" "\[^\r\n\]*38.*" \ > "next.1" > -gdb_test "reverse-next" "\[^\r\n\]*main \\(\\) at > tailcall.c:37\r\n.*" \ > +gdb_test "reverse-next" "\[^\r\n\]*foo \\(\\) at > tailcall.c:29\r\n.*" \ > "reverse-next.1" > -gdb_test "step" "\[^\r\n\]*foo \\(\\) at tailcall.c:29\r\n.*" \ > +gdb_test "step" "\[^\r\n\]*bar \\(\\) at tailcall.c:24\r\n.*" \ > "step.1" > gdb_test "finish" "\[^\r\n\]*main \\(\\) at tailcall.c:38\r\n.*" \ > "finish.2" > > With this change, the tailcall.exp test now passes on my X86 laptop. > The PowerPC do not change since the test is not supported on PowerPC. > > I will post an updated version of the X86 patch with the fixes to the > tailcall test. It will be version 3. There are no changes to the > PowerPC patch. > > The gdb.btrace/rn-dl-bind.exp test passes with and without my > patches. > I still can not get this test to fail on my system. I have been thinking about this and have decided the above change is not what we should do. Basically if we forward step at answer = foo(); we stop at answer += 1;. Which is the expected behavior for next. So, is we are at answer += 1; and do a reverse step it should take us to answer = foo(). It would be the opposite of the forward next. I think I have identified the single line in the function call set_step_info() which caused the regression in gdb.btrace/tailcall.exp. I have so far run a few experiments and it looks like not doing the statement: tp->control.step_stack_frame_id = get_stack_frame_id (frame); eliminates the regression in tailcall.exp. So far. I need to do some more testing but it looks like there is a couple of regressions on my X86 laptop. It looks like the expected behavior in both of these tests is for the reverse step over a function stops at a function call within the function not stepping all the way back to the call of the function. Basically, the expected behavior of these reverse tests is not consistent across tests. I am not seeing any PowerPC regression failures with the above change. My IBM x86 machine tests are still running. Anyway, just wanted to give people a heads up that I am pursuing another fix and that I now think the above fix is not the best direction to go. Carl