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 165553858D37 for ; Wed, 1 Feb 2023 18:41:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 165553858D37 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 (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 311IUfmb021103; Wed, 1 Feb 2023 18:40:55 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 : content-transfer-encoding : mime-version : subject; s=pp1; bh=TGpngCiKS4m/9Q232L/yGFvEZMdfDFWIPvlEk83j9UA=; b=nVMdoZ9OSV9LyGxAxp2IiqeoyC3j5gPshlkQQAK7hbT+gO3Nj4dclBGTsNK3EkpzgYc1 3ZvLRVmiUwS+jmU07z4R91Kxb3OVWJMrKUiKX/cDmZ1xLjoCqlsjLGDGQf89uzj/riA4 sxL3a5WEEY8tG18/G+AN4sz7W2lwjqeVL64U4c/A0TRGs4epBraPyrMcJm82Td6++FYD VrTVID5xPSX7qOxiTzkoKNTup+0xiLyBfWo/6uQZf2ZzgYyxLyB39aDJYxFi+qLaMQCQ V0Xb2NC33jJnerjj8+NJ+FwVSnX9uYcAIryaLD10N6zq7zix/9WVMsCg+3kuzKnjvRZo SA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3nfwe2g9re-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Feb 2023 18:40:55 +0000 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 311Ie9ZN031395; Wed, 1 Feb 2023 18:40:55 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 3nfwe2g9qp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Feb 2023 18:40:55 +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 311HTKhc012318; Wed, 1 Feb 2023 18:40:53 GMT Received: from smtprelay06.dal12v.mail.ibm.com ([9.208.130.100]) by ppma05wdc.us.ibm.com (PPS) with ESMTPS id 3ncvvdq7sk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Feb 2023 18:40:53 +0000 Received: from smtpav03.dal12v.mail.ibm.com (smtpav03.dal12v.mail.ibm.com [10.241.53.102]) by smtprelay06.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 311IerjZ8323768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Feb 2023 18:40:53 GMT Received: from smtpav03.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 04F995805A; Wed, 1 Feb 2023 18:40:53 +0000 (GMT) Received: from smtpav03.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 82C885803F; Wed, 1 Feb 2023 18:40:52 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.163.12.142]) by smtpav03.dal12v.mail.ibm.com (Postfix) with ESMTP; Wed, 1 Feb 2023 18:40:52 +0000 (GMT) Message-ID: From: Carl Love To: Pedro Alves , Bruno Larsen , Tom de Vries , Ulrich Weigand , gdb-patches@sourceware.org Cc: cel@us.ibm.com Date: Wed, 01 Feb 2023 10:40:52 -0800 In-Reply-To: <2f4db108-8c37-8464-1e2d-77b22413ff98@palves.net> References: <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> <610d5f171d5f4baeb94887217e69d0e6d70e9d66.camel@us.ibm.com> <873eb58a-a6ab-08b2-0827-ca6e0c8088ae@palves.net> <6785a1c038d5956d43892f8a7f27106d9001de76.camel@us.ibm.com> <2f4db108-8c37-8464-1e2d-77b22413ff98@palves.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 8g7H83Du-qehf1BP_0Y_pAV7N2LaRofd X-Proofpoint-ORIG-GUID: GRY8h7u3JNrl0M5Qpi3zV3D5FRBKITzE Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 1 URL was un-rewritten MIME-Version: 1.0 Subject: RE: Reverse-next bug test case 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-02-01_04,2023-01-31_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 malwarescore=0 bulkscore=0 phishscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=606 adultscore=0 impostorscore=0 spamscore=0 clxscore=1015 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302010159 X-Spam-Status: No, score=-5.3 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: Pedro: On Wed, 2023-02-01 at 14:37 +0000, Pedro Alves wrote: > On 2023-01-31 12:17 a.m., Carl Love wrote: > > +# The second reverse step should take us call of func2 (). > > +gdb_test "reverse-step" ".*func1 \\(\\); func2 \\(\\);.*" \ > > + "reverse-step to line func1(); func2(), at call for func2 " > > + > > From < > https://sourceware.org/gdb/current/onlinedocs/gdb.html/Reverse-Execution.html > > : > > "Like the step command, reverse-step will only stop at the beginning > of a source line. " > > So when reverse-stepping is ongoing and execution internally stops at > the call to func2, gdb > should realize it is not really at the beginning of a source line, > and continue stepping. > That should take it inside func1, and stop there (at the beginning of > a line), as it will have > reached a different line. > > I would start by looking at making either of these pass: > > $ make check TESTS="*/pedro_test.exp" > RUNTESTFLAGS="CC_FOR_TARGET='gcc -gno-column-info'" OK, when I try the test with no column info, the test on PowerPC fails. The initial Test 2 expected the second reverse-step to stop at func1(); func2() after stepping into func2 (). When the Test 2 is updated to remove the second reverse-step: ... gdb_continue_to_breakpoint \ "stopped at command reverse-step test start location" \ ".*$srcfile:$bp_start_reverse_test\r\n.*" # The first reverse step should take us call of func2 (). gdb_test "reverse-step" ".*}.*" \ "reverse-step into func2 " # The second reverse step should take us call of func2 (). ## ERROR, should not stop here as that is in the middle of the source line #gdb_test "reverse-step" ".*func1 \\(\\); func2 \\(\\);.*" \ # "reverse-step to line func1(); func2(), at call for func2 " # The third reverse step should take us into func1 (). gdb_test "reverse-step" ".*}.*" \ "reverse-step into func1 " # The fourth reverse step should take us call of func1 (). gdb_test "reverse-step" ".*func1 \\(\\); func2 \\(\\);.*" \ "reverse-step to line func1(); func2(), at call for func1 " # The fifth reverse step should take us to b = 2 (). gdb_test "reverse-step" ".*b = 2;.*" \ "reverse-step to line b = 2 " Then the test passes when running with no column info. OK, that helps. Thanks. Carl > > $ make check TESTS="*/pedro_test.exp" > RUNTESTFLAGS="CC_FOR_TARGET=clang" > > ... as the misbehavior happens due to GDB misinterpreting multiple > lines entries for the > same line when column info is emitted by current gcc. If you disable > the column info, then gdb > should not stop in the middle of a line, and that's how gdb should > always behave. (Making use > of column info is certainly interesting to support statement > stepping, but that's orthogonal.)