From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id E19193858401 for ; Mon, 23 Jan 2023 21:13:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E19193858401 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 (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30NK1kSF028162; Mon, 23 Jan 2023 21:13:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : from : to : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding : subject; s=pp1; bh=Bnegnrlgz7PrxLUIWLrTBp+nb04iKcHkw/OQMvakoks=; b=gKrdBKZqLOixV0GE81LmnH72A2rIfvs8vozOVfijxIa1YWNU+zI+VEdjMefBrUNLE4Ch rn5b+M3RnHlTk24ovIRgdP3wRyFVoOz53jxFaKb+LvRvb2TaMEYfc7Eps3pfoMoku67J mo+m+j6OBnMU9v2r+crQrrAW4e1GicI4EMKO5biLOJcQR3FP6IbQE7Erpbv+RxqTqHgK Qk7TvgUgZCU5hictbpdBZAqMiHm8DAb835oLwHz9LveFVK83udOWnMkCbHtXc0DfeZwW OEmrRst2IS4ayO+BmjvdPARpvWy32ru752rOZZNmwRLfsIJWv4A53lMRrWfEIwH7Py+4 bA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3na0wqsn20-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Jan 2023 21:13:14 +0000 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 30NL7BhB026726; Mon, 23 Jan 2023 21:13:14 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3na0wqsn1m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Jan 2023 21:13:14 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 30NL01Qs025665; Mon, 23 Jan 2023 21:13:13 GMT Received: from smtprelay05.wdc07v.mail.ibm.com ([9.208.129.117]) by ppma02dal.us.ibm.com (PPS) with ESMTPS id 3n87p7a425-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Jan 2023 21:13:13 +0000 Received: from smtpav05.dal12v.mail.ibm.com (smtpav05.dal12v.mail.ibm.com [10.241.53.104]) by smtprelay05.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 30NLDBhr6095460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Jan 2023 21:13:12 GMT Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8D0C158069; Mon, 23 Jan 2023 21:13:11 +0000 (GMT) Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 238CA5805D; Mon, 23 Jan 2023 21:13:11 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.163.12.142]) by smtpav05.dal12v.mail.ibm.com (Postfix) with ESMTP; Mon, 23 Jan 2023 21:13:11 +0000 (GMT) Message-ID: <610d5f171d5f4baeb94887217e69d0e6d70e9d66.camel@us.ibm.com> From: Carl Love To: Pedro Alves , Bruno Larsen , Ulrich Weigand , "will_schmidt@vnet.ibm.com" , gdb-patches@sourceware.org Date: Mon, 23 Jan 2023 13:13:10 -0800 In-Reply-To: References: <50474aa92ba82eff05cdc8f49001eae56be29670.camel@us.ibm.com> <89331c26795e3f7743e1e068dce43b3c2dd53008.camel@us.ibm.com> <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> <58cebd1a-7883-fbc6-ac94-c67293f8fc8d@redhat.com> <5e5dc4a49aa8feb370419a1efecf277673b7dfc7.camel@us.ibm.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: 3F_2Gwu0UkVYVwu4EUu4qg5YM5F9mJgv X-Proofpoint-ORIG-GUID: _Pgv2Uf6sdtQkgNgsukbbacz5Gf1jAFx Subject: RE: [PATCH 1/2 version 3] 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-23_12,2023-01-23_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 adultscore=0 spamscore=0 clxscore=1011 mlxlogscore=536 phishscore=0 mlxscore=0 suspectscore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301230200 X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,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: Pedro: On Mon, 2023-01-23 at 19:17 +0000, Pedro Alves wrote: > > Currently on X86, when executing the finish command in reverse, gdb > > does a > > single step from the first instruction in the callee to get back to > > the > > caller. GDB stops on the last instruction in the source code line > > where > > the call was made. When stopped at the last instruction of the > > source code > > line, a reverse next or step command will stop at the first > > instruction > > of the same source code line thus requiring two step/next commands > > to > > reach the previous source code line. It should only require one > > step/next > > command to reach the previous source code line. > > > > By contrast, a reverse next or step command from the first line in > > a > > function stops at the first instruction in the source code line > > where the > > call was made. > > I'd think this was on purpose. Note that next/step/reverse- > {next/step} are line-oriented > stepping commands, they step/next until the previous/next line. > While "finish" is described > as undoing the _function call_. > > The manual says: > > reverse-finish > Just as the finish command takes you to the point where the current > function returns, > reverse-finish takes you to the point where it was called. Instead > of ending up at the end of > the current function invocation, you end up at the beginning. > > Say you have a line with multiple statements involving multiple > function calls. > The simplest would be: > > func1 (); func2 (); > > Say you'd stopped inside 'func2'. If you do finish there, in current > master gdb > stops at the call to 'func2', and you can then decide to reverse step > into 'func1'. I don't think you followed the issue. So, if you are in func2 and do a reverse-finish, without the patch gdb stops on the last instruction for the line that calls func2. Now if you issue a reverse-step, you stop at the first instruction for the call to func2, i.e. you are still on the same source code line. You have not stepped back into func1 like you wanted to. Now you have to issue a second reverse-step to get into func1. With the patch, you issue the reverse-finish from func2 and stop at the first instruction in the line that calls func2. Now when you issue the reverse-step you step back into func1 as expected. > While with your change, reverse-finish in func2 will make gdb stop at > the beginning > of the line, before the call to func1. > > Thus I'm really not convinced (yet) this change is a good one. It > removes > a user choice. You can always do reverse-next/step do get what you > want > reverse-finish do to, already. Carl