From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +rLmKIf4zmPB4B8AWB0awg (envelope-from ) for ; Mon, 23 Jan 2023 16:13:43 -0500 Received: by simark.ca (Postfix, from userid 112) id 98C571E128; Mon, 23 Jan 2023 16:13:43 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=PrbVbq1f; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 11A891E0D3 for ; Mon, 23 Jan 2023 16:13:43 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5CF623858414 for ; Mon, 23 Jan 2023 21:13:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5CF623858414 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674508422; bh=Bnegnrlgz7PrxLUIWLrTBp+nb04iKcHkw/OQMvakoks=; h=To:Date:In-Reply-To:References:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=PrbVbq1fJfXHsUZCUfiG0nz2BmDjq/CR1sL+hmAIpINAFD+T0Gh+1hrt3c9Rfvdzy uVcPmS3QUdH/bIqpJbuOOh0+q5gmccXWhRMD3tLxAKxByzHh5gL8VtcFEHXkceobOV fOEpuomEwykw53VtbmudcxepJ0uIwD7wbRGAOIUk= 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 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 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> 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-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: , From: Carl Love via Gdb-patches Reply-To: Carl Love Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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